On Thu, Jan 10, 2019 at 03:47:24PM +0100, Christoph Anton Mitterer wrote: > OpenPGP would be in principle ok. > However, I haven't really checked the implementation of it (i.e. how > the code downloading, verification is done... on a first glance, I'd > say it allows at least for replay attacks. > Plus it automatically imports the shipped public key into the keyring > of the executing user… which is IMO also unacceptable.
Agreed, the script should use its own keyring. > 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. > 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. > I think it security-wise it would be best not to ship it at all, IMO unacceptable. > or at > least (perhaps even non-executable) in the examples dir. That's a dirty workaround. > If there is such a big demand in having that extremely up-to-date by > many people it would be better if they could perhaps help somehow to > keep the package better up-to-date. :-) In debian stable? That would basically mean to have this package in each and every point release. 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. In this case, we're not executing the download on our own, so we could even put the load of verifying the file on to the local user executing the script. We could think abuot shipping the PCI/USB ID databases together with the smartmontools database in a volatile-hwdata package that can be part of every point release, but that would need a coordinated effort, while I'd really love to have an acceptable solution for this NOW to provide an acceptable method of having smartmontools giving reasonable output even for newer hardware during the buster cycle. If we continue sacrificing functionality for security, we can start shipping empty packages. Those are surely the most secure. Greetings Marc
