Project

General

Profile

Bug #2931

[parabola-hackers]: keys are "unknown trust" after expiry/renewal

bill-auger - 15 days ago - . Updated 7 days ago.

Status:
in progress
Priority:
bug
Assignee:
-
% Done:

0%


Description

this is a recurring problem which happens whenever a signing key is expired and renewed; such that pacman rejects packages signed by that key - the files are unmodified since being published; and the report indicates successful verification

the problem persists after the signing key is renewed, and the keyring package is rebuilt - it is not obvious why, nor which software/interactions are involved, eg: the keyring package or its build process, the packaging metadata, or some interaction between pacman/gpg

we have tried removing the expired key from the keyring (the normal way, per hackers.git), then re-adding it; but that did not help - the next step down that path is to delete the entire hackers.git YAML file - IIRC the previous experiment, only the key entry was deleted

most of the experiments have been focussed on the keyring package build process - lately, i am looking toward other explanations

the current solution is to rebuild all afected packages from source - some experiments to try:
- simply replace the signatures with new ones
- run librerelease on the packages again
- rebuild the keyring with the signing key specified in hackers.git, instead of, or in addition to, the master key

my current theory, is that perhaps this is all expected behavior, and pacman-key is doing the thing right, but doing the wrong thing, by considering (intentionally or not) valid signatures from a presently expired key to be unacceptable - that is presumably due to the gpg exit status, although the program reports that it is a "good signature" - however that still would not explain why the warning /rejection persists after the key is renewed then the keyring package is rebuilt

pacman-key should consider the "good signature" per gpg to be of greater significance than the expiry date, and sufficient for package signature verification, unless the key was revoked - the expiry notice is a less significant than a warning, indicating no problem with the primary functionality in question: verifying the integrity/authenticity of a file/signature pair - if it were an invalid signature, or any error condition at all, i would expect: "Note:", would be rather like "Warning:", "Important!:", "Error:", etc

worse though, pacman indicates to the user, that the key has "unknown trust", which is misleading - it has exactly the same trust as before the expiry date, because nothing has changed - gpg is not reporting any error, and is not indicating any fault with the package verification - it is entirely a web-of-trust concern

it is a friendly reminder to the user, to contact this person, asking for that signature to be renewed, if the file in question is still valuable - if that person does not respond, nor extend the expiry, only then would it have a potential to become problematic - again, purely a web-of-trust or team management problem though - the package will always be faithfully verifiable just as the day it was published


Related issues

Related to Packages - Bug #2146: [systemd]: error: signature from bill-auger is unknown trustfixed

Actions
Related to Packages - Bug #2390: [bbswitch] pgp fail - blocks linux-libre upgradefixed

Actions
Related to Packages - Bug #2572: [musescore] the current package has been signed by an invalid PGP signaturenot-a-bug

Actions
Related to Packages - Bug #2834: [cups-filters][tokyocabinet]: Signature is unkown trustfixed

Actions
Related to Packages - Housekeeping #2925: signature from bill-auger is unknown trustfixed

Actions
Related to Packages - Bug #2933: [icedove] bill-auger signature is possibly outdatedfixed

Actions
Related to Packages - Bug #2936: librestage not working with pacman-mirrorlistconfirmed

Actions

History

#1

Updated by bill-auger 14 days ago

  • Related to Bug #2146: [systemd]: error: signature from bill-auger is unknown trust added
#2

Updated by bill-auger 14 days ago

  • Related to Bug #2390: [bbswitch] pgp fail - blocks linux-libre upgrade added
#3

Updated by bill-auger 14 days ago

  • Related to Bug #2572: [musescore] the current package has been signed by an invalid PGP signature added
#4

Updated by bill-auger 14 days ago

  • Related to Bug #2834: [cups-filters][tokyocabinet]: Signature is unkown trust added
#5

Updated by bill-auger 14 days ago

#6

Updated by bill-auger 14 days ago

  • Description updated (diff)
#7

Updated by bill-auger 13 days ago

  • Description updated (diff)
  • Subject changed from [parabola-hackers]: keys are "unknown trust" after expiry/renweal to [parabola-hackers]: keys are "unknown trust" after expiry/renewal
#8

Updated by bill-auger 9 days ago

#9

Updated by bill-auger 9 days ago

specifying the signing sub-key in hackers.git, instead of the master key, has fixed the problem, at least temporarily - my signing key is set to expire again today, so we should know soon if that is a permanent solution

#10

Updated by bill-auger 9 days ago

#11

Updated by bill-auger 9 days ago

  • Related to Bug #2933: [icedove] bill-auger signature is possibly outdated added
#12

Updated by GNUtoo 7 days ago

  • Related to Bug #2936: librestage not working with pacman-mirrorlist added
#13

Updated by GNUtoo 7 days ago

the current solution is to rebuild all affected packages from source [...]

I've been trying to do that but I'm stuck due to bug #2936

AFAIK we don't have many packages to rebuild to enable the creation of a librechroot:
  • filesystem -> done for x86_64
  • pacman-mirrorlist -> fails
  • linux-libre-api-headers -> done for x86_64

Then it might unbreak the ability to rebuild more and more packages as needed without workarounds (which are more time consuming if you don't want any nasty side effects).

#14

Updated by bill-auger 7 days ago

the problem appears to be fixed now - i deduce that the root of the problem is in the pacman install hook on the local machine, when pacman assigns "trust-level' to the keys - though the way pacman handles this could be improved, i think we can chalk this one up to user error, and strictly-speaking: not a bug

apparently, the master key can be trusted, while any of the subkeys are not necessarily trusted; and pacman only trusts the one specified key, ignoring subkeys if the master key was specified, and ignoring the master key if a subkey was specified - so the solution appears to be: to specify the signing key in hackers.git - if that is a subkey, it forces pacman to explicitly trust the subkey

then again, i did not ever have the same problem as oaken-source's key; and i dont know if oaken-source signs packages with a subkey - we should verify that any of oaken-source's packages which may still be in the system are installable now, and/or if oaken-source can publish packages now

the pacman eerror mesage "unknown trust" is extremely misleading in this case; because the key specified in hackers.git is trusted during install - ideally, an error would be thrown during the install of the keyring package, (or better yet, during the package build), rather than the current behavior of defering the error condition until pacman attempts to verify some other package - unfortunately, pacman can not know if the key being signed (or any of it's subkeys) will actually be used to sign packages - in theory, it could detect if any of the subkeys of that key have been used in the past to sign packages already in the system, and insist on verifying and assigning a trust-level to those also; but that could be an expensive operation

Also available in: Atom PDF