On Thu, 2019-01-10 at 14:34 +0100, Michael Prokop wrote: > * Christoph Anton Mitterer [Tue Jan 08, 2019 at 03:09:16PM +0100]: > > Maybe one could put it (non-executable) into /u/s/d/…/examples? > > I'd appreciate this, if providing it within $PATH isn't considered > an option within Debian.
Well it's not upon me to decide it, but to the maintainer. I've just hat a quick glance at current upstream: https://svn.code.sf.net/p/smartmontools/code/trunk/smartmontools/update-smart-drivedb.in It seems it now contains some code verification, both X.509 CA based and/or OpenPGP based. I think the X.509 CA / TLS based one can be just tossed (because X.509 PKI is inherently flawed and insecure - just take the ~150 CAs Mozilla ships, many of them already completely untrustworthy, with even more sub-CAs (that are even more untrustworthy). 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. 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- programs do it wrong (e.g. allowing for replay attacks, etc. pp. [0]) but it also allows for certain types of attacks (e.g. code distributed by the package management system guarantees more or less that all users would need to get a hacked version,... while if it's distributed by a (possibly hacked?) upstream, single users could be targeted selectively, making it likely much harder to notice an attack). Having code downloaded/updated by downloader-programs also means that this basically circumvents Debian security support. People will only get updates if they invoke the necessary update-* program... and things like e.g. Icinga checks (check_apt), won't see that any action needs to be taken. I think it security-wise it would be best not to ship it at all, or at least (perhaps even non-executable) in the examples dir. 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. :-) Cheers, Chris. [0] Some years ago there were still many of such downloader packages in Debian which did a very bad job in terms of security.
