diff options
Diffstat (limited to 'doc/bugs')
8 files changed, 30 insertions, 8 deletions
diff --git a/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn new file mode 100644 index 000000000..2311656ce --- /dev/null +++ b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn @@ -0,0 +1 @@ +Since upgrading from Ikiwiki 2.20 to 2.32.3 (from Debian Lenny), I don't get hyperlinks to items which have a colon in their name anymore. This applies to both the normal and the archive view. Before the update, the links have been created as relative links, so they weren't usable either as the browser tried to take the part before the colon as protocol specification (as in e.g. `http:`). Iirc, this applied to the archive view only, links in the normal view were ok (will check this out again if it's important). Is there a way to quote each colon as %xy in the hyperlinks? Perhaps it's only a problem with my config, and not an actual bug...? diff --git a/doc/bugs/http_proxy_for_openid.mdwn b/doc/bugs/http_proxy_for_openid.mdwn index ec2c3cb27..e8f87f9c4 100644 --- a/doc/bugs/http_proxy_for_openid.mdwn +++ b/doc/bugs/http_proxy_for_openid.mdwn @@ -8,7 +8,7 @@ I have found if I add: to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not configured. -Also, the ability to set HTTPS\_CA\_FILE and HTTPS\_CA\_DIR might benefit some people. Then again, it I can't see any evidence that the SSL certificate of the server is being checked. +Also, the ability to set HTTPS\_CA\_FILE and HTTPS\_CA\_DIR might benefit some people. Then again, it I can't see any evidence that the SSL certificate of the server is being checked. See the [[bug_report|ssl_certificates_not_checked_with_openid]] I filed on this separate issue. Unfortunately, HTTP\_PROXY doesn't work for http requests, it looks like that library is different. diff --git a/doc/bugs/img_plugin_causes_taint_failure.mdwn b/doc/bugs/img_plugin_causes_taint_failure.mdwn index f8def19a0..f012a87a0 100644 --- a/doc/bugs/img_plugin_causes_taint_failure.mdwn +++ b/doc/bugs/img_plugin_causes_taint_failure.mdwn @@ -13,3 +13,5 @@ Seen with ikiwiki 2.30 > Also, the debian build of ikiwiki has taint checking disabled to avoid > this perl bug. Did you build your own? Set NOTAINT=1 when building.. > --[[Joey]] + +>> perl-5.8.8, I've created a package for openSUSE. Will file perl bug there as well then. diff --git a/doc/bugs/img_plugin_renders___60__img__62___tag_without_src_attribute_post-2.20.mdwn b/doc/bugs/img_plugin_renders___60__img__62___tag_without_src_attribute_post-2.20.mdwn new file mode 100644 index 000000000..cad9ebbc2 --- /dev/null +++ b/doc/bugs/img_plugin_renders___60__img__62___tag_without_src_attribute_post-2.20.mdwn @@ -0,0 +1 @@ +I upgraded from 2.18 to 2.32.3 and my \[[img]] links became `<img>` tags without `src` attributes. Reverting to 2.18 fixes the problem again. I assume this is 2.20, which is the only revision between 2.19 and 2.32.3 to mention img in the changelog. diff --git a/doc/bugs/links_from_sidebars.mdwn b/doc/bugs/links_from_sidebars.mdwn new file mode 100644 index 000000000..c3a201cf8 --- /dev/null +++ b/doc/bugs/links_from_sidebars.mdwn @@ -0,0 +1,9 @@ +If you use sidebars for navigation the Links section of a page ends up looking like: + +Links: blog/posts blog/sidebar sidebar + +instead of what I would expect: + +Links: blog/posts blog index + +I'm not sure what the bug actually is, or if there even is one, this just seems odd. diff --git a/doc/bugs/links_from_sidebars/discussion.mdwn b/doc/bugs/links_from_sidebars/discussion.mdwn new file mode 100644 index 000000000..9cb84328a --- /dev/null +++ b/doc/bugs/links_from_sidebars/discussion.mdwn @@ -0,0 +1,5 @@ +In the meantime I have configured nginx to redirect any requests for .../sidebar/ up to the parent page. + + rewrite ^(.*/)sidebar/$ $1 redirect; + +This appears to work well. diff --git a/doc/bugs/relative_links.mdwn b/doc/bugs/relative_links.mdwn index df203c651..824632ed0 100644 --- a/doc/bugs/relative_links.mdwn +++ b/doc/bugs/relative_links.mdwn @@ -12,10 +12,5 @@ It would be good if relative paths could be used instead, so the transport metho > "../../", and "../". The only absolute links are to CGIs and the w3c DTD. > --[[Joey]] ->> Something weird going on here, most of the links *are* relative. Maybe I was just too rushed. However there are still problems: - ->> Links at the top of the edit page; they are absolute (understandably). e.g. at the top of this page there is the header "ikiwiki/ editing bugs/relative links" where ikiwiki is an absolute link to the top of the page. - ->> If I push cancel on the edit page, I end up at http://..., although I am not sure how this occurs. - ->> -- Brian May +>> The problem is within the CGI script. The links within the HTML page are all absolute, including links to the css file. +>> Having a http links within a HTML page retrieved using https upset most browsers (I think). Also if I push cancel on the edit page in https, I end up at at http page. -- Brian May diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn new file mode 100644 index 000000000..802ab16a7 --- /dev/null +++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn @@ -0,0 +1,9 @@ +As far as I can tell, ikiwiki is not checking the SSL certificate of the remote host when using openid authentication. If so, this would allow for man-in-the-middle type attacks. Alternatively, maybe I am getting myself confused. + +Test #1: Enter URL as openid server that cannot be verified (either because the certificate is self signed or signed by an unknown CA). I get no SSL errors. + +Test #2: Download net\_ssl\_test from dodgy source (it uses the same SSL perl library, and test again. It seems to complain (on same site ikiwiki worked with) when it can't verify the signature. Although there is other breakage with the version I managed to download (eg. argument parsing is broken; also if I try to connect to a proxy server, it instructs the proxy server to connect to itself for some weird reason). + +For now, I want to try and resolve the issues with net\_ssl\_test, and run more tests. However, in the meantime, I thought I would document the issue here. + +-- Brian May |