From 2e51d5c74da6f4dda8a1f96781811d0b4c6c83c5 Mon Sep 17 00:00:00 2001 From: "http://gmcmanus.myopenid.com/" Date: Mon, 21 Jul 2008 23:25:17 -0400 Subject: email obfuscation by Text::Markdown undone by HTML::Scrubber --- ...bber_undoes_email_obfuscation_by_Text::Markdown.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn (limited to 'doc/bugs') 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..17836abfe --- /dev/null +++ b/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn @@ -0,0 +1,17 @@ +From the source of [[usage]]: + + joey@ikiwiki.info + +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? -- cgit v1.2.3 From 88ff7480e6b2f639aa62af53dbb9e63cc3632571 Mon Sep 17 00:00:00 2001 From: "http://gmcmanus.myopenid.com/" Date: Tue, 22 Jul 2008 01:22:14 -0400 Subject: bug already noted, so mark as done --- doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/bugs') diff --git a/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn b/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn index 17836abfe..bac8e4acd 100644 --- a/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn +++ b/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn @@ -15,3 +15,6 @@ 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 -- cgit v1.2.3 From 4515726bfebb4a4bec78daf2cdc986cc1cad3392 Mon Sep 17 00:00:00 2001 From: "http://brian.may.myopenid.com/" Date: Tue, 22 Jul 2008 01:28:20 -0400 Subject: response to response --- doc/bugs/ssl_certificates_not_checked_with_openid.mdwn | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'doc/bugs') 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 -- cgit v1.2.3 From 602ad172d0cb5b07de0de2c7cc6eedb1ede74383 Mon Sep 17 00:00:00 2001 From: "http://gmcmanus.myopenid.com/" Date: Tue, 22 Jul 2008 05:10:46 -0400 Subject: patch to prevent email obfuscation --- ...tmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'doc/bugs') diff --git a/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn b/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn index bac8e4acd..b010a02b3 100644 --- a/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn +++ b/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn @@ -18,3 +18,13 @@ 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/ -- cgit v1.2.3 From b2917c76cb63daac80b69678113fd220cb07bd72 Mon Sep 17 00:00:00 2001 From: "http://gmcmanus.myopenid.com/" Date: Tue, 22 Jul 2008 05:33:24 -0400 Subject: bug when pages changing extension; new patch --- .../page_is_not_rebuilt_if_it_changes_extension.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 doc/bugs/page_is_not_rebuilt_if_it_changes_extension.mdwn (limited to 'doc/bugs') 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. -- cgit v1.2.3