diff options
author | smcv <smcv@web> | 2018-12-01 08:13:39 -0400 |
---|---|---|
committer | admin <admin@branchable.com> | 2018-12-01 08:13:39 -0400 |
commit | 4fc19e39bc5e4199aa9bf33f011d46ca86e6bb09 (patch) | |
tree | 2bf2bfdc9d6a83fff7aeb61d1258c684676a99c2 /doc/plugins | |
parent | 6ae58c733c40859fc918359bda550c9cac2d22b6 (diff) | |
download | ikiwiki-4fc19e39bc5e4199aa9bf33f011d46ca86e6bb09.tar ikiwiki-4fc19e39bc5e4199aa9bf33f011d46ca86e6bb09.tar.gz |
comments (no review yet)
Diffstat (limited to 'doc/plugins')
-rw-r--r-- | doc/plugins/osm/discussion.mdwn | 25 |
1 files changed, 25 insertions, 0 deletions
diff --git a/doc/plugins/osm/discussion.mdwn b/doc/plugins/osm/discussion.mdwn index 957ff3f9a..ff3cb8d36 100644 --- a/doc/plugins/osm/discussion.mdwn +++ b/doc/plugins/osm/discussion.mdwn @@ -71,6 +71,31 @@ rather not have to carry around a local copy of his work to get a map with waypoints on my HTTPS site. [[smcv]], can you spare some round tuits to give us your thoughts? --[[schmonz]] +> I've never used the osm plugin, so I don't know how well it works at the moment. +> I think the lack of test coverage has been a significant factor in it not actually +> working. Even if we don't have test-driven development, the next best thing is +> bug-driven testing: every time something regresses, we should have a test that +> asserts it doesn't fail like that again. +> +> If the current osm plugin is at all usable, then we'd need to look at the specific +> ways in which the new one is incompatible, but if the current osm plugin doesn't +> actually work anyway, then the new one can't break working sites... +> +> Determining whether there's HTML injection is certainly an important thing to +> review. We need to be able to say what's trusted, what's attacker-controlled, and +> what was originally attacker-controlled but has been sanitized or escaped and +> hence has reached a trusted state. +> +> As an upstream developer, I would say that my preferred approach to Leaflet would +> be to vendor it and use the vendored copy by default, but have a configuration +> parameter to load it from a CDN instead. In the Debian package, to avoid the +> situation we've got into with jQuery where we have a vendored copy that we +> don't dare to update to a new version because we don't know what it will break, +> I think there should be a dependency on libjs-leaflet and a dpkg trigger to +> copy its files into our underlay (ideally we'd symlink it, but ikiwiki doesn't +> follow symlinks, and I don't think an approach to symlinks in underlays that +> isn't a security flaw is going to happen any time soon). --[[smcv]] + ---- Just stumbled onto this. |