On Wed, 2019-02-13 at 09:44 +0100, Marc Haber wrote: > That's a classic case of volatile data that should either be in a > dedicated package that can be built automatically and release much > more > often You mean splitting out just the .h file? Well sounds ok to me, but ultimately all up to the maintainer :-)
> or we could finally get in motion to trust upstream's > distribution mechanism like we do for, for example, clamav. Well as I've outlaid several times now before, even it that distribution mechanism could be trusted (and last time - but again: it was no thorough check - I didn't see any means to avoid downgrade attacks),... there's still the inherent point that it circumvents the package management system and anything depending on it (automatic update tools, Nagios checks, etc.) will thus not work. > jftr, clamav used to have an automatically built clamav-data package > that contained daily updates, but that was killed off by the archive > maintainers, refering people to the mechanisms offered by the package > upstream. Well the may have had their technical reasons, but conceptually and security wise it think it's not the best decisions... If every package brings their own updating system, all of them flawed (like freshclam had been several times), we'd have quite a mess. So please let's avoid to go in a Windows-world direction, where everything brings it's own questionable updater with it. Cheers, Chris.
