Christoph Anton Mitterer wrote:
Even if it would be properly secured with some key that upstream has,
it would allow them to selectively inject code into Debian systems.
Then anything we could do upstream (e.g. provide a drivedb.h.asc file,
check it in update-smart-drivedb) won't help.
Some volunteer maintainer might provide drivedb.h (below /usr, not /var)
as a separate arch independent package and update it more frequently
than smartmontools. Such a package only needs a "suggests" dependency
because the built-in database is used if the external file is missing.
In the short term it should probably be disabled or at least prompt the
user to manually verify a checksum or something.
./configure --without-drivedbdir
This keeps the built-in database and optional /etc/smartd_drivedb.h intact.
If done, please add a dummy update-smart-drivedb script which explains
why this functionality was removed.
Possible risks from a bogus drivedb.h:
- The typical worst case: A hidden bug in the parser allows to run
arbitrary code as root.
(BTW: Thanks for any review of the parser in knowndrives.cpp)
- Removing "-F nologdir" option from Intel 320/710 SSD entries may
result in drive a firmware crash if Log Directory is read.
- Setting a bogus USB "-d TYPE" option may result in disconnected USB
devices or more serious problems.
- More ? (IMO no).
Thanks,
Christian
smartmontools.org
