Package: devscripts Version: 2.25.15 Severity: normal X-Debbugs-Cc: [email protected];[email protected]
Hi,While working on adding editor support for the new watch file format, I ran into the `hrefdecode` field.
Its description states that it will perform a URL decode and implies it is used for "obfuscated" web sites. I do not remember any modern use of URL encoding as being an obfuscation. If anything, I was surprised that `uscan` would not do proper URL decoding if needed.
So I checked codesearch.d.n to see if the option was used at all. Turns out we have a *single* instance of it being used in lighthttpd. The lighthttpd upstream uses `~` in their pre-release (such as 1.4.56~rc5.tar.xz) of their versions and only the `~` character appears to be URL encoded (the page appears to be an auto-generated web server directory index - https://download.lighttpd.net/lighttpd/releases-1.4.x/). That is, it is not an obfuscation at all.
So at this point, it feels more like this option is only to have `uscan` follow standard HTML/URL semantics rather than anything else. I would recommend that we remove the field and instead unconditionally URL decode when needed.
I would see version=4 being the last version to support this as an option with the field never appearing in Version: 5. In my view, it would save us the mental burden for everyone (consumers and devscripts maintainers) and we simplify the code path. Whether version=4 should retroactively apply `hrefdecode`, I am personally in favor of doing so since no valid version or filename will contain & anyway. But I am open to the conservative approach as in my understanding only `lighthttpd` would be affected in practice and it already has the option.
Best regards, NielsPS: If we decide to keep the `hrefdecode` option for some reason, the documentation for it is currently botched (using `version=4` syntax rather than `Version: 5` syntax in debian-watch.5).
OpenPGP_signature.asc
Description: OpenPGP digital signature
