diff options
Diffstat (limited to 'doc/bugs')
3 files changed, 62 insertions, 1 deletions
diff --git a/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn b/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn new file mode 100644 index 000000000..b010a02b3 --- /dev/null +++ b/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn @@ -0,0 +1,30 @@ +From the source of [[usage]]: + + <a href="mailto:joey@ikiwiki.info">joey@ikiwiki.info</a> + +Text::Markdown obfuscates email addresses in the href= attribute and in the text. +Apparently this can't be configured. + +HTML::Scrubber doesn't set `attr_encoded` for its HTML::Parser, so the href= attribtute is decoded. +Currently it seems it doesn't set `attr_encoded` for good reason: so attributes can be sanitized easily, +e.g. as in htmlscrubber with `$safe_url_regexp`. +This apparently can't be configured either. + +So I can't see an obvious solution to this. +Perhaps improvements to Text::Markdown or HTML::Scrubber can allow a fix. + +One question is: how useful is email obfuscation? +Don't spammers use HTML parsers? + +> I now see this was noted in the formatting [[/ikiwiki/formatting/discussion]], and won't/can't be fixed. +> So I guess this is [[done]]. --Gabriel + +I've [[patch]]ed mdwn.pm to prevent Text::Markdown from obfuscating the emails. +The relevant commits are on the master branch of [my "fork" of ikiwiki on Github] [github]: + +- 7d0970adbcf0b63e7e5532c239156f6967d10158 +- 52c241e723ced4d7c6a702dd08cda37feee75531 + +--Gabriel. + +[github]: http://github.com/gmcmanus/ikiwiki/ diff --git a/doc/bugs/page_is_not_rebuilt_if_it_changes_extension.mdwn b/doc/bugs/page_is_not_rebuilt_if_it_changes_extension.mdwn new file mode 100644 index 000000000..d5719744e --- /dev/null +++ b/doc/bugs/page_is_not_rebuilt_if_it_changes_extension.mdwn @@ -0,0 +1,20 @@ +Suppose a wiki has a source page a.mdwn, which is then moved to a.wiki. +(Suppose both the mdwn and wikitext plugins are enabled, so this changes how "a" is rendered.) +Currently, when the wiki is refreshed, ikiwiki doesn't notice the change +and the page is not rebuilt. + +I have a [[patch]] that fixes this. +The relevant commit on [my Github fork of ikiwiki](http://github.com/gmcmanus/ikiwiki/) is: + + b6a3b8a683fed7a7f6d77a5b3f2dfbd14c849843 + +The patch (ab)uses`%forcerebuild`, which is meant for use by plugins. +If, for some reason, a plugin deletes the page's entry in `%forcerebuild`, it won't be rebuilt. + +This patch uncovers another problem. +Suppose a wiki has a source page "a" (no extension) +which is then moved to "a.mdwn" (or vice versa). +ikiwiki fails when trying to create a directory "a" where there is a file "a" +(or vice versa). + +The same problem occurs if both "a" and "a.mdwn" exist in the wiki. diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn index 171874951..cb4c706f0 100644 --- a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn +++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn @@ -22,4 +22,15 @@ For now, I want to try and resolve the issues with net\_ssl\_test, and run more > is good. > --[[Joey]] -[[!tag done]] +>> Ok, so I guess the worst that could happen when ikiwiki talks to the http +>> address is that it gets intercepted, and ikiwiki gets the wrong address. +>> ikiwiki will then redirect the browser to the wrong address. An attacker could +>> trick ikiwiki to redirect to their site which always validates the user +>> and then redirects back to ikiwiki. The legitimate user may not even notice. +>> That doesn't so seem secure to me... + +>> All the attacker needs is access to the network somewhere between ikiwiki +>> and http://joey.kitenet.net/ or the ability to inject false DNS host names +>> for use by ikiwiki and the rest is simple. + +>> -- Brian May |