Custom Query (1239 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (10 - 12 of 1239)

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Ticket Resolution Summary Owner Reporter
#1278 fixed update-smart-drivedb: Older releases return *** BAD signature *** Christian Franke Stanislav Brabec
Description

When calling update-smart-drivedb from smartmontools-6.6, it always fails: /usr/sbin/update-smart-drivedb: /usr/share/smartmontools/drivedb.h.error.raw: * BAD signature *

Digging deeper into this problem by sh -x, I see: ++ gpg --quiet --no-secmem-warnin --batch --no-tty --homedir=/usr/share/smartmontools/.gnupg.12981.tmp --verify /usr/share/smartmontools/drivedb.h.new.raw.asc /usr/share/smartmontools/drivedb.h.new.raw + out='gpg: Signature made Sat Dec 28 22:44:15 2019 CET gpg: using RSA key EA74AB25721042C5 gpg: Can'\t check signature: No public key' + rc=1

There is a problem:

smartmontools-6.6 hardcodes requirement of "Smartmontools Signing Key (through 2018)". But drivedb.h.raw.asc in the branch RELEASE_6_6_DRIVEDB is signed by "Smartmontools Signing Key (through 2020)". This cannot work.

drivedb.h.raw.asc in the branch RELEASE_6_6_DRIVEDB has to use "Smartmontools Signing Key (through 2018)" forever. You have to extend validity period of this signing key, and then use that key for signing of this branch.

Similarly, once RELEASE_7_0_DRIVEDB will be created, it has to be signed by "Smartmontools Signing Key (through 2020)" forever. And if it will not be created, you will go into unfixable problems in 2021 (version 7.0 will require a different signature than a future 7.3).

In general, replacement of signing key every two years is not smart. It does not increase security, but paradoxically it decreases the security. New signing key has no trusted developer signatures, no trusted ring, so there are no way to verify that the key was created by legitimate developers.

That is why I recommend to stop creating new keys every two years. Please create a well established trusted key, and when it will be required (e. g. signature considered as weak), add a signature to it. Developers should sign this key by their private keys, so people who have them in the trust ring could immediately trust this key.

To decrease problems with future compatibility (e. g. extended key validity period, added signature), the script should update the key from the GPG network: gpg --recv-keys {key_id}

This will also ensure security, as the possibly revoked key will be refused.

#1279 duplicate update-smart-drivedb: Older releases return *** BAD signature *** Stanislav Brabec
Description

When calling update-smart-drivedb from smartmontools-6.6, it always fails: /usr/sbin/update-smart-drivedb: /usr/share/smartmontools/drivedb.h.error.raw: * BAD signature *

It currently affectects version 6.6, but starting with year 2021, it will affect 7.0 and 7.1 as well.

Digging deeper into this problem by sh -x, I see: ++ gpg --quiet --no-secmem-warnin --batch --no-tty --homedir=/usr/share/smartmontools/.gnupg.12981.tmp --verify /usr/share/smartmontools/drivedb.h.new.raw.asc /usr/share/smartmontools/drivedb.h.new.raw + out='gpg: Signature made Sat Dec 28 22:44:15 2019 CET gpg: using RSA key EA74AB25721042C5 gpg: Can'\t check signature: No public key' + rc=1

There is a problem:

smartmontools-6.6 hardcodes requirement of "Smartmontools Signing Key (through 2018)". But drivedb.h.raw.asc in the branch RELEASE_6_6_DRIVEDB is signed by "Smartmontools Signing Key (through 2020)". This cannot work.

drivedb.h.raw.asc in the branch RELEASE_6_6_DRIVEDB has to use "Smartmontools Signing Key (through 2018)" forever. You have to extend validity period of this signing key, and then use that key for signing of this branch.

Similarly, once RELEASE_7_0_DRIVEDB will be created, it has to be signed by "Smartmontools Signing Key (through 2020)" forever. And if it will not be created, you will go into unfixable problems in 2021 (version 7.0 will require a different signature than a future 7.3).

In general, replacement of signing key every two years is not smart. It does not increase security, but paradoxically it decreases the security. New signing key has no trusted developer signatures, no trusted ring, so there are no way to verify that the key was created by legitimate developers.

That is why I recommend to stop creating new keys every two years. Please create a well established trusted key, and when it will be required (e. g. signature considered as weak), add a signature to it. Developers should sign this key by their private keys, so people who have them in the trust ring could immediately trust this key.

To decrease problems with future compatibility (e. g. extended key validity period, added signature), the script should update the key from the GPG network: gpg --recv-keys {key_id}

This will also ensure security, as the possibly revoked key will be refused.

#1426 fixed update-smart-drivedb: Allow update from other URLs or local files Christian Franke Paul Wise
Description

I think it would be nice if the Debian package maintainer did not have to re-implement the checks implemented by update-smart-drivedb (including the ones suggested in #1424) in the Debian postinstall script, so I suggest that a --local-dir option for update-smart-drivedb could be used to make it look at a local directory for the drivedb.h copy installed by the Debian package, perform the necessary checks and then update the canonical drivedb.h in /var. Then the Debian postinstall script could just run update-smart-drivedb --local-dir, passing the directory in the package where the necessary files are installed.

I have CCed onlyjob, the Debian package maintainer.

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Note: See TracQuery for help on using queries.