update-smart-drivedb: Older releases return *** BAD signature ***

[Stanislav Brabec]

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.

[Christian Franke]

Thanks for detailed suggestions. A longer term solution should be found until next release.

... 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.

This was and is the case for ​all smartmontools keys. A change here is not very likely due to very few active developers and lack of developer keys signed by third parties. And BTW, additional signatures of a public key would not increase the probability that the private key is kept reasonably secret (by me in this case).

To decrease problems with future compatibility (e. g. extended key validity period, added signature), the script should update the key from the GPG network: ...

Doing this unconditionally on every script run may result in some controversy, at least due to last year's ​keyserver incidents.

The default keyring should not be touched at all unless enabled by user (see ...which is ... unacceptable at ​Debian Bug 804299).

I possibly will add an option to select the key origin, something like:

  -k builtin   Use key built in the script [default]
  -k default   Use default keyring of current user
  -k update    Update key from key servers

[Christian Franke]

Ticket #1197 has been marked as a duplicate of this ticket.

[Stanislav Brabec]

I see no short-term solution for smartmontools-6.6, except:

• Using "Smartmontools Signing Key (through 2018)" forever and ante-date the signatures.
• Or release version 6.6.1 using the new key or verification method.

I see no short-term solution for smartmontools-7.0 and 7.1, except:

• Using "Smartmontools Signing Key (through 2020)" forever and ante-date the signatures starting with 2021-01-01.
• Or release version 7.0.1 and 7.1.1 using the new key or verification method.

Regarding the future:

• Stop replacing the signing key every two years.
• Create keys with a long (or unlimited) validity period. (We can suppose that if the signing algorithm will be compromised in future, than gpg itself will refuse such signatures.)
• Embed a keyring with unlimited validity period into update-smart-drivedb. (Or at least validity longer than expected branch support lifetime. You can also use short validity period for keyserver and long/unlimited for update-smart-drivedb embedding.)
• Optionally check online for new (stronger) signing sub-keys or revocation.

If the key is not kept secret, then there is no help and there is no trusted way to deliver the new key. The best you can do then is a revocation. But the revocation will also revocate the whole update-smart-drivedb secure drivedb.h update feature.

Rationale:

Yes, smartmontools signing key can be spammed by signatures. But spammed key safety will not be affected by that. (And your safety is affected only if you violate rules and sign a key to an unknown spammer (add the spammer will appear in your trusted key database).)

update-smart-drivedb safety does not depend on signatures at all. It is derived from the embedded keyring. This is:

• good, as the smartmontools signing key does not need to be in the trust database of the verifying person.
• problematic, as new signing keys cannot be added (but sub-keys can be added online)
• problematic, as the embedded key has a strictly limited lifetime, and cannot be used later (you need to set the lifetime long enough, or you have to ante-date the signatures of the drivedb.h)
• problematic, as the key is probably not checked for revocation (I did not test it; but its easy to implement)

To fight with the potential problem of signature spammming, you can extract minimal keys without signatures:

gpg --keyserver-options=auto-key-retrieve --armor --export-options no-export-attributes,export-clean,export-minimal --export $KEY_ID >$KEY_ID.key

You can make bundles of such keys:

gpg --no-default-keyring --keyring smartmontools.keyring --import <$KEY_ID.key

Actually, openSUSE use such keyrings for verification of version update tarballs:
​https://build.opensuse.org/package/view_file/Base:System/smartmontools/smartmontools.keyring?expand=1

In case of smartmontools, it does not add an additional level of security, as the keyring is updated every 2 or 3 releases. (Other project use signing keys for many years.)

I wrote this tool for such keyring manipulation: ​https://build.opensuse.org/package/show/openSUSE:13.2/gpg-offline

[Christian Franke]

I see no short-term solution for smartmontools-6.6, except:

• Using "Smartmontools Signing Key (through 2018)" forever and ante-date the signatures.

Some tests (gpg 1.4.23, 2.1.18, 2.2.19) show that an actual ante-date hack is not needed as gpg --verify apparently does not refuse verification if signature_timestamp > key_expiry_time. For me as a gpg non-expert this is unexpected.

Therefore it would be sufficient to extend the validity of my local through 2018 key and re-start to sign new files on (and only on) the RELEASE_6_6 branch with this key. Then the 6.6 update-smart-drivedb script would work without changes. The only difference would be the message gpg: Note: This key has expired! if run with -v. The pubkey with extended validity should be published for reference.

Same could later be done with through 2020 key for 7.0 and 7.1.

One drawback for smartmontools-6.6 only is that this would break update scripts which were already updated to through 2020 key. I didn't find any package where this is the case.

Thanks for the info about minimal key export. This will be useful in future script updates.

[Stanislav Brabec]

Replying to Christian Franke:

I see no short-term solution for smartmontools-6.6, except:

• Using "Smartmontools Signing Key (through 2018)" forever and ante-date the signatures.

Some tests (gpg 1.4.23, 2.1.18, 2.2.19) show that an actual ante-date hack is not needed as gpg --verify apparently does not refuse verification if signature_timestamp > key_expiry_time. For me as a gpg non-expert this is unexpected.

It is unexpected for me as well.

But please extend the validity period of "Smartmontools Signing Key (through 2018)" on key servers. It does not affect update-smart-drivedb in any way, but it helps humans to understand what is happening. (Yes, it is an old key, but it is still in active use.

One drawback for smartmontools-6.6 only is that this would break update scripts which were already updated to through 2020 key. I didn't find any package where this is the case.

At least SUSE did not that. And Fedora did not do it as well. Here in openSUSE we got a report just now, so I contacted the upstream, as everybody is affected, and only the upstream can change signing key.

If you will switch to the "Smartmontools Signing Key (through 2018)" in the RELEASE_6_6_DRIVEDB, I will not submit the key change update.

[Christian Franke]

But please extend the validity period of "Smartmontools Signing Key (through 2018)" on key servers.

Of course. I will keep the through 2018 uid and add a second one to show the new expire year. This will possibly be 2024 for the 6.6 key and 2025 (my year of retirement :-) for the 7.0/7.1 key. Should be enough for most LTS distributions.

If you will switch to the "Smartmontools Signing Key (through 2018)" in the RELEASE_6_6_DRIVEDB, I will not submit the key change update.

If no unexpected problems occur during further tests, I will switch the key within the next two weeks.

[Christian Franke]

Signing key of 5.41-6.6 branches reverted to DFD22559 in r5030. Key with extended lifetime through 2024 uploaded to ​key servers.

Leaving ticket open until lifetime of current key ​721042C5 is extended accordingly.

[Christian Franke]

r5030 (5.41-6.6), r5140 (7.0-...).

Keys with extended lifetime uploaded to key servers: ​DFD22559 (5.41-6.6), ​721042C5 (7.0-...).