On Fri, 2019-02-01 at 22:09 +0100, Marc Haber wrote: > Generally I think it's good that the tool is gone,… updating code > > should *always* be the task of the respective package management > > system, cause otherwise it's not just easy that code-downloader- > > I violently disagree. We only release every two years. SSDs develop > quickly. We should not ship a two year old file.
If it's only that .h file that changes… it shouldn't be very difficult to keep things up2date, or is it? > > Having code downloaded/updated by downloader-programs also means > > that > > this basically circumvents Debian security support. > > If the downloader script replaces the file from the package, it will > be > overridden with the next package upgrade, allowing security support > to > continue seamlessly. Things like debsums will break, and often (though I haven't checked the one from smartmontools) these downloaders have security flaws… e.g. allowing for a downgrade attack, by only checking for a valid signature, not for a validity time. Also by circumventing package-management, one effectively circumvents tools like check_apt. > > or at > > least (perhaps even non-executable) in the examples dir. > > That's a dirty workaround. But possibly the safest one for many users? > In debian stable? That would basically mean to have this package in > each > and every point release. There's e.g. stable-updates which could be perfectly used for this... > I would like to remind that we used to have daily build of the clamav > anti-virus database distributed as .deb via debian-volatile, which > was > quickly killed off after volatile was taken over by ftpmaster, > refering > users to use freshclam, a downloader program, instead. So we have a > very > much more prominent case of having a downloader program for volatile > data here. I think to remember at least 2-3 CVEs in freshclam… > In this case, we're not executing the download on our own Which OTOH makes it also worse, as people not manually executing it won't get updates. > If we continue sacrificing functionality for security, we can start > shipping empty packages. Those are surely the most secure. Sorry, but this is just polemic. There is no need to sacrifice functionality for security, just use the means that are already there, e.g. stable-updates (i.e. the debian- volatile successor)... I'd be surprised if the ftp-masters refuse to that if there's good reasoning... and if they do, stable-updates could probably just tossed. There is no need to sacrifice security, if things can be done just right :-) Cheers, Chris.
