Thanks for the reply Abraham! On 2024-02-10 21:10, Abraham S.A.H. wrote:

It's always possible for a package maintainer to act maliciously, in both cases! You can edit the main source code, and upload it anywhere. Calculate its digest. Sign it with your own malicious key and upload your public key to keyservers. Then in your PKGBUILD, you put the address of your own uploaded source code to be fetched, its previously calculated hash to be checked and finally the fingerprint of your own malicious key to be retrieved from keyserver. Or simply include the PGP public key file alongside the PKGBUILD.

Maybe I'm missing something, but with the way makepkg works, it should (in theory) prevent a packager from sneaking in a malicious signature. In the presence of a validpgpkeys() array, makepkg checks the user keyring for the public key and simply errors out. There is no automation for fetching the key. It is on the package builder to manually retrieve the correct key. Proper diligence includes checking with *upstream sources* for published keys. That means not taking the validpgpkeys() value at face value and in that scenario the packager wouldn't be able to use a malicious key. Trusting the validpgpkeys() value in the PKGBUILD and just straight up importing the listed key(s) from the public keyservers seems the same as building with `--skippgpcheck` to me, at least as a downstream consumer of an AUR package. validpgpkeys() is still valid for the packager themselves for verifying that the upstream source hasn't been tempered with (ie. server breach for example). Cheers, Wilhelm

Hello, This thread continues to go on despite there being official ruling on it. [1]

So, I guess, not including PGP key directly alongside PKGBUILD file is somehow more cautious. Right?

PKGBUILDs are always subject to malicious behaviour, however you are speaking as if gpg is a symmetric by default (it can do symmetric encryption), when its not. The public key is used to verify a digital signature, it can not sign sources, its purpose isn't to ensure a PKGBUILD is not malicious, it is to ensure the sources pulled from upstream are signed by the expected developer, if not, the source is potential vulnerable to tampering. You should always check the source array anyways, because anyone can stick a fork of the software with malicious intent. Doesn't matter if you pull it from a repo, some random http endpoint, or a keyserver, the public key can be freely shared anywhere you like without any security issues, so including it alongside the PKGBUILD is not any less insecure, in fact, it is more reliable as keyservers are a pain to deal with. However this is all listed within the RFC. At the end of the day its your package, but like I said in my previous email, its best to stick to the official packaging standards, also makes it easy for package maintainers to pull AUR packages into [extra] if they are already at the required standard. I am clueless of the issues trying to be presented here, sha256sum and gpg signatures are not designed to prevent a packager giving you a malicious PKGBUILD, the packager doesn't need to include the signatures, or checksum they are optional after all (as in makepkg will build with 'SKIP', they SHOULD always be used). Checksums are used to verify the integrity of the download, and ensure you downloaded what was expected, gpg signing ensures the sources were released by the expected developer, and not some third party. But this doesn't ensure the PKGBUILD isn't malicious, you got to read the PKGBUILD yourself and verify the following: - No malicious bash commands - Source comes from upstream, not some random fork or dropbox link for example. - PGP provided is the correct key of the upstream maintainer. I think I repeated the same point over and over again, not too sure but there you go. TL;DR follow official RFCs, they are approved by the staff team for a reason. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev [1] https://rfc.archlinux.page/0011-store-source-signing-keys/

Forgive me if I'm mistaken, but I think the linked RFC applies to the official Arch Linux repositories, not to the AUR. The official repositories, unlike the AUR, are curated by trusted package maintainers who would presumably vet any PGP keys before importing them into VCS. If you trust the official package maintainers, you can by extension trust the PGP keys they pull into VCS. By contrast, AUR packages are explicitly unsupported and left to the user to review before building and installing. The mere presence of a PGP key alongside the PKGBUILD does not necessarily mean you should trust that PGP key to sign the sources - as others have pointed out, you should /always/ check upstream for which key(s) is supposed to be signing the sources. If upstream doesn't state anywhere what keys are used, then it doesn't help if keys are shipped with the PKGBUILD, because there's no way to know if it's the right ones. However I do agree that shipping keys alongside the PKGBUILD can make it easier to import the key once you know which key you need. All you really need from upstream is the expected key fingerprint; once you have that you can import the key from anywhere as long as you verify that the key has the expected fingerprint. Similarly, you /could/ choose to simply review the downloaded sources and, once you're confident that they're not malicious, accept the key as trusted for future package updates. For example, yay [1] makes it easy to review only the diff of new PKGBUILD versions, so as long as the validpgpkeys and signature sources don't change you can be confident that the sources are still from /the same/ developer that you chose to trust. [1]: https://aur.archlinux.org/packages/yay /Emil On 2/13/24 03:57, Abraham S.A.H. wrote:

...

However this is all listed within the RFC. Thanks @Polarian. That RFC didn't occur to me.

-- Best Regards, Abraham Sent with Tutanota;https://tuta.com

On 2/10/24 14:10, Abraham S.A.H. wrote:

Sign it with your own malicious key and upload your public key to keyservers.

This is kind of the whole breakdown in gpg signing. In 2018, the keyservers were hit with a type of malware that effectively served as global DDOS on the keyservers (many of which were unmaintained and had simply been running for years unattended). After the attack much of the keyserver system was simply never restarted leading to difficulties in getting public keys to verify signatures. They are hit-of-miss at best now. As long as the AUR package makes the needed public keys available, then all is fine, but if users are left to "get the key from a keyserver" - the specific keyserver holding the key needs to be identified, as there is little or no sync of keys anymore. (this is just a side note for the general discussion) The Arch keyring takes key of providing keys for Arch, but I'm unsure how AUR does this) -- David C. Rankin, J.D.,P.E.

On 2/20/24 03:34, David Runge wrote:

Closing I would like to add that with*any* sort of signature and authenticity claim it is on the consumer to verify, validate and trust this claim. The PKGBUILDs (and any verification scheme that may come along with it) offered in the AUR are "unsupported" for a reason.

Best, David

You are AWESOME, Yes the Certificate spamming is what I was referring to. However going from memory, "malware" was what I came up with to describe what the miscreants were doing to the keyservers. Thank you for your detailed solutions -- that is exactly what information is needed. -- David C. Rankin, J.D.,P.E.

Re: Is including GPG keys in an AUR package for verifying sources a good idea? – Hello,

Good reasoning and decision regarding not removing signatures checking.

As for attaching keys, my opinion on that is: you may. My thinking here is as follows.

Signatures establish a secure channel between the software authors and the builder/user. If one puts complete trust in a random AUR account, we can just use SHA512 and stop with the security theater. The user is expected to acquire and verify the key through a separate route: either directly from the authors or by using enough witnesses to build trust.

Unavoidably that brings the question: where the user is supposed to get the key at? Keyservers should be the answer, but have fun playing hide-and-seek to tell, which server to use. Keys being published whenever possible is a good option then. That would include AUR.

That leaves one question open: where? I believe the proper place is the git repository, alongside the PKGBUILD. Keys aren’t expected to change often, so updates wouldn’t be frequent.

There is little risk in an AUR account offering a malicious key. Public keys are not expected to be distributed through secure means. Only the key ID (or the entire fingerprint) has to be confirmed. After all this is how keyservers work and they are even less trusted than AUR.

What if the victim doesn’t verify the key ID? The worst a malicious actor could do is publishing an AUR entry with both fake key and its corresponding key ID. But this gives them power to convey malicious source, what one can do by simply not offering signatures. There is a minor threat of the key ending up in their keyring, which can be later used to e.g. send encrypted email the attacker can read (tamper-evident on recipient’s end: they can’t decrypt it). But the same can be done with a keyserver.

Cheers

A malicious

Hi, On 2024-02-11 01:35, mpan wrote:

Hello,

Good reasoning and decision regarding not removing signatures checking.

As for attaching keys, my opinion on that is: you may. My thinking here is as follows.

Signatures establish a secure channel between the software authors and the builder/user. If one puts complete trust in a random AUR account, we can just use SHA512 and stop with the security theater. The user is expected to acquire and verify the key through a separate route: either directly from the authors or by using enough witnesses to build trust.

Unavoidably that brings the question: where the user is supposed to get the key at? Keyservers should be the answer, but have fun playing hide-and-seek to tell, which server to use. Keys being published whenever possible is a good option then. That would include AUR.

That leaves one question open: where? I believe the proper place is the git repository, alongside the PKGBUILD. Keys aren’t expected to change often, so updates wouldn’t be frequent.

There is little risk in an AUR account offering a malicious key. Public keys are not expected to be distributed through secure means. Only the key ID (or the entire fingerprint) has to be confirmed. After all this is how keyservers work and they are even less trusted than AUR.

What if the victim doesn’t verify the key ID? The worst a malicious actor could do is publishing an AUR entry with both fake key and its corresponding key ID. But this gives them power to convey malicious source, what one can do by simply not offering signatures. There is a minor threat of the key ending up in their keyring, which can be later used to e.g. send encrypted email the attacker can read (tamper-evident on recipient’s end: they can’t decrypt it). But the same can be done with a keyserver.

Cheers

Thanks for the great reply, I agree on all points pretty much. Yeah, the package consumer still has to verify the key (signature) with upstream, but including the key file with the package can help in situation where the public keyservers are flakey (certainly a situation I've had to deal with in the past). One point I just realized is that the AUR might prevent me from uploading the key(s) as they wouldn't be listed in the sources() array in the PKGBUILD. However, it turns out, the AUR has special handling for a key dir [0]. [0]: https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests/722 Cheers, Wilhelm.