search

2m / arch-pkgbuild-builder

Arch Linux PKGBUILD GitHub builder action
https://github.com/marketplace/actions/arch-linux-pkgbuild-builder-action
35 stars 24 forks source link

ERROR: One or more PGP signatures could not be verified! #50

Open Marcool04 opened 10 months ago

Marcool04 commented 10 months ago

Hi there!

I am trying to use this github action to build a custom linux kernel in the github CI, but I can't seem to figure out how to add the signing PGP key to the keychain...

I have this very simple workflow:

name: build_archlinux_package

on: ['push','pull_request']

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: 2m/arch-pkgbuild-builder@v1.16
      with:
        target: 'srcinfo'
        pkgname: '.'
    - uses: 2m/arch-pkgbuild-builder@v1.16
      with:
        target: 'pkgbuild'
        pkgname: '.'

And github actions give me this output at the end of the Run 2m/arch-pkgbuild-builder@v1.16 stage:

==> Verifying source file signatures with gpg...
    linux-6.5.9.tar ... FAILED (unknown public key 38DBBDC86092693E)
    linux-v6.5.9-arch2.patch.zst ... FAILED (unknown public key 3B94A80E50A477C7)
==> ERROR: One or more PGP signatures could not be verified!

I have searched the documentation and looked at the other examples of projects using this workflow but can't seem to find how to handle PGP keys. Any help would be much appreciated.

Regards, Mark.

2m commented 10 months ago

Thank you for reporting. Did not know that makepkg also is doing source validation using gpg. :) I found some more helpful information about this here: http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/

51 should fix it. With this change, you package now fails to build with the following error:

==> Verifying source file signatures with gpg...
    linux-6.5.9.tar ... Passed
    linux-v6.5.9-arch2.patch.zst ... FAILED (unknown public key 3B94A80E50A477C7)
==> ERROR: One or more PGP signatures could not be verified!

But that is expected since 3B94A80E50A477C7 is not defined in the PKGBUILD.

2m commented 10 months ago

Released v1.21 with the fix.

Marcool04 commented 10 months ago

Hi and thanks for the quick reaction!

Unfortunately, v1.21 doesn't seem to work... As you mentioned, it fails with "unknown public key 3B94A80E50A477C7", which IS the short fingerprint of key A2FF3A36AAA56654109064AB19802F8B0D70FC30 that was used by Jan Alexander Steffens to sign this arch patch to the linux kernel.

$ gpg --list-packets linux-v6.5.9-arch2.patch.zst.sig | rg keyid
:signature packet: algo 22, keyid 3B94A80E50A477C7
$ gpg --list-key 3B94A80E50A477C7
pub   ed25519 2020-05-11 [SC]
      A2FF3A36AAA56654109064AB19802F8B0D70FC30
uid           [ unknown] Jan Alexander Steffens (heftig) <heftig@archlinux.org>
sub   ed25519 2020-05-11 [A]
sub   ed25519 2020-05-11 [S]
sub   cv25519 2020-05-11 [E]
$ source PKGBUILD; echo "${validpgpkeys[*]}"
ABAF11C65A2970B130ABE3C479BE3E4300411886 647F28654894E3BD457199BE38DBBDC86092693E A2FF3A36AAA56654109064AB19802F8B0D70FC30
$ makepkg --verifysource -f
[clip]
==> Verifying source file signatures with gpg...
    linux-6.5.9.tar ... Passed
    linux-v6.5.9-arch2.patch.zst ... Passed

Maybe the problem is with the awk line? Could it be pulling only Torvald's key, the first line in validpgpkeys array?

Marcool04 commented 10 months ago

Having said that...

Now that I look closer at the output of the action, I have:

 gpg: key 19802F8B0D70FC30: public key "Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>" imported
gpg: key 38DBBDC86092693E: 1 duplicate signature removed
gpg: key 38DBBDC86092693E: public key "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" imported

So where does this leave the problem...?

2m commented 10 months ago

Yea, as of right now I am also a bit confused what is the problem here. It seems that the patch is signed with a subkey (3B94A80E50A477C7) and PKGBUILD defines the parent key (A2FF3A36AAA56654109064AB19802F8B0D70FC30) in validpgpkeys, but that should not be a problem.

Also found the following in the Archlinux wiki: https://wiki.archlinux.org/title/PKGBUILD#validpgpkeys

If the source file was signed with a subkey, makepkg will still use the primary key for comparison.

But I guess that is fine as well.

2m commented 10 months ago

There seems to be something funky going on regarding this key and ubuntu key server: https://bbs.archlinux.org/viewtopic.php?id=268750

However when I tried using hkps://keys.openpgp.org then the other keys can not be imported because:

gpg: key 38DBBDC86092693E: no user ID
gpg: key 79BE3E4300411886: no user ID

Looks like this key server can strip user IDs from keys if desired by the key holder, and that is not supported by gpg.

Marcool04 commented 10 months ago

I think the problem is with this key:

$ gpg --list-keys --fingerprint --with-subkey-fingerprints A2FF3A36AAA56654109064AB19802F8B0D70FC30
pub   ed25519 2020-05-11 [SC]
      A2FF 3A36 AAA5 6654 1090  64AB 1980 2F8B 0D70 FC30
uid           [ unknown] Jan Alexander Steffens (heftig) <heftig@archlinux.org>
sub   ed25519 2020-05-11 [A]
      A3B1 C763 D7D5 6FEB 42FB  729C 76CF 819A 8AE1 A606
sub   ed25519 2020-05-11 [S]
      0668 7A1D 9D4F AB08 B50F  D92B 3B94 A80E 50A4 77C7
sub   cv25519 2020-05-11 [E]
      EB74 CB57 09BC F8A0 BB9A  8720 B936 6059 0553 8A6A

It actually has two signing keys: the primary public key A2FF3A36AAA56654109064AB19802F8B0D70FC30 and the sub key 0668 7A1D 9D4F AB08 B50F D92B 3B94 A80E 50A4 77C7. And here is the problem: the detached signature was made with the sub key:

$ gpg --list-packets linux-v6.5.9-arch2.patch.zst.sig 
# off=0 ctb=88 tag=2 hlen=2 plen=117
:signature packet: algo 22, keyid 3B94A80E50A477C7
    version 4, created 1698281294, md5len 0, sigclass 0x00
    digest algo 8, begin of digest 4b 97
    hashed subpkt 33 len 21 (issuer fpr v4 06687A1D9D4FAB08B50FD92B3B94A80E50A477C7)
    hashed subpkt 2 len 4 (sig created 2023-10-26)
    subpkt 16 len 8 (issuer key ID 3B94A80E50A477C7)
    data: [255 bits]
    data: [254 bits]

but in validpgpkeys we have the public key:

$ source PKGBUILD; echo "${validpgpkeys[*]}"
ABAF11C65A2970B130ABE3C479BE3E4300411886
647F28654894E3BD457199BE38DBBDC86092693E
A2FF3A36AAA56654109064AB19802F8B0D70FC30

This is also noted here by gpg:

$ gpg --verify linux-v6.5.9-arch2.patch.zst{.sig,}
gpg: Signature made Thu 26 Oct 2023 02:48:14 AM CEST
gpg:                using EDDSA key 06687A1D9D4FAB08B50FD92B3B94A80E50A477C7
gpg: Good signature from "Jan Alexander Steffens (heftig) <heftig@archlinux.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: A2FF 3A36 AAA5 6654 1090  64AB 1980 2F8B 0D70 FC30
     Subkey fingerprint: 0668 7A1D 9D4F AB08 B50F  D92B 3B94 A80E 50A4 77C7

which lists the subkey fingerprint (something it doesn't do with a signature generated with the primary public key).

Marcool04 commented 10 months ago

But that doesn't (quite) answer the question: why does makepkg get it right locally on my machine, but not in the docker machine from your workflow? 🤔

Marcool04 commented 10 months ago

Ah... yes it could well be the import that is the problem. Maybe the docker machine is not importing the subkey because of the keyserver it is using? My local machine is pulling keys from:

$ rg 'keyserver ' ~/.gnupg/gpg.conf | rg -v '^#'
keyserver hkps://keyserver.ubuntu.com

But I definitely have the subkey as shown by gpg --list-keys above

2m commented 10 months ago

Yea, I tried building your package with the change from here: https://github.com/2m/arch-pkgbuild-builder/commit/a1acfadfe27bdc9b4ff6871e9835f9346a556844 which uses the same key server, and it successfully imports the keys:

gpg: directory '/home/build/.gnupg' created
gpg: keybox '/home/build/.gnupg/pubring.kbx' created
gpg: key 19802F8B0D70FC30: 6 duplicate signatures removed
gpg: key 19802F8B0D70FC30: 1 bad signature
gpg: key 19802F8B0D70FC30: 6 signatures reordered
gpg: /home/build/.gnupg/trustdb.gpg: trustdb created
gpg: key 19802F8B0D70FC30: public key "Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>" imported
gpg: key 38DBBDC86092693E: 1 duplicate signature removed
gpg: key 38DBBDC86092693E: public key "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" imported
gpg: Total number processed: 2
gpg:               imported: 2

And fails with the same error message:

==> Verifying source file signatures with gpg...
    linux-6.5.9.tar ... Passed
    linux-v6.5.9-arch2.patch.zst ... FAILED (unknown public key 3B94A80E50A477C7)
==> ERROR: One or more PGP signatures could not be verified!
Marcool04 commented 10 months ago

Yeah we're definitely hitting some gpg key(server?) import / verification weirdness here... 🤷‍♂️

Marcool04 commented 10 months ago

So I did a bit more digging. I tracked down where makepkg does its verifying. It's here: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/scripts/libmakepkg/integrity/verify_signature.sh.in#L164 which puts output into a file, $statusfile which then gets unpacked here: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/scripts/libmakepkg/integrity/verify_signature.sh.in#L201

I went and modified my local makepkg library so it wouldn't delete the tempfile $statusfile after checking, so I could see what that contains:

# diff -u /usr/share/makepkg/integrity/verify_signature.sh.bak /usr/share/makepkg/integrity/verify_signature.sh
--- /usr/share/makepkg/integrity/verify_signature.sh.bak    2023-11-05 11:09:26.315301185 +0100
+++ /usr/share/makepkg/integrity/verify_signature.sh    2023-11-05 11:09:55.645494221 +0100
@@ -36,6 +36,7 @@
    local warnings=0
    local errors=0
    local statusfile=$(mktemp)
+   echo "Status file: $statusfile"
    local all_sources

    case $1 in
@@ -103,7 +104,7 @@
        printf '\n' >&2
    done

-   rm -f "$statusfile"
+   #rm -f "$statusfile"

    if (( errors )); then
        error "$(gettext "One or more PGP signatures could not be verified!")"

And then I ran this:

$ makepkg --verifysource -f
[clip]
==> Verifying source file signatures with gpg...
Status file: /tmp/tmp.KNNoC4Q7Xp
    linux-6.6.tar ... Passed
    linux-v6.6-arch1.patch.zst ... Passed

with the following result in the status file:

$ \cat /tmp/tmp.KNNoC4Q7Xp
[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED A2FF3A36AAA56654109064AB19802F8B0D70FC30 0
[GNUPG:] SIG_ID B8KyBlv5i6VUVXVQfBhKQ+zei/4 2023-10-30 1698684843
[GNUPG:] KEY_CONSIDERED A2FF3A36AAA56654109064AB19802F8B0D70FC30 0
[GNUPG:] GOODSIG 3B94A80E50A477C7 Jan Alexander Steffens (heftig) <heftig@archlinux.org>
[GNUPG:] VALIDSIG 06687A1D9D4FAB08B50FD92B3B94A80E50A477C7 2023-10-30 1698684843 0 4 0 22 8 00 A2FF3A36AAA56654109064AB19802F8B0D70FC30
[GNUPG:] KEY_CONSIDERED A2FF3A36AAA56654109064AB19802F8B0D70FC30 0
[GNUPG:] KEY_CONSIDERED A2FF3A36AAA56654109064AB19802F8B0D70FC30 0
[GNUPG:] TRUST_UNDEFINED 0 pgp

What is the trust level of that key then? $ gpg --export-ownertrust | rg A2FF3A36AAA56654109064AB19802F8B0D70FC30 gives no output, so it's indeed, "UNDEFINED".

$ gpg --verify linux-v6.6-arch1.patch.zst.sig linux-v6.6-arch1.patch.zst
gpg: Signature made Mon 30 Oct 2023 05:54:03 PM CET
gpg:                using EDDSA key 06687A1D9D4FAB08B50FD92B3B94A80E50A477C7
gpg: Good signature from "Jan Alexander Steffens (heftig) <heftig@archlinux.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: A2FF 3A36 AAA5 6654 1090  64AB 1980 2F8B 0D70 FC30
     Subkey fingerprint: 0668 7A1D 9D4F AB08 B50F  D92B 3B94 A80E 50A4 77C7

Maybe we could try modifying the source of the makepkg library in your docker image to get more output, but I'll admit I'm not very used to working with docker at all.

Still a mystery here... Regards, Mark.

PS: There is this (still open I think) discussion on pacman-dev mailing list: https://lists.archlinux.org/archives/list/pacman-dev@lists.archlinux.org/thread/6ZHUM234BF6LCAXBEBQ6EY6WZMRF62NM/ which may also be related, if it is a subkey issue as you suspect?

Edit: removed a section on (un)compressed file verification, where I had misread the makepkg code.