You are not logged in.

#1 2019-01-28 09:21:21

Aanok
Member
Registered: 2018-06-11
Posts: 8

[SOLVED] Upstream switching from primary PGP key to subkey

Hello! I'm maintaining the AUR package for an application that distributes a PGP-signed binary .AppImage file, together with the corresponding .asc. The PKGBUILD is setup to verify the signature and contains the corresponding fingerprint in validpgpkeys.

Until now, the signature was generated by the developer using his primary key. He has told me he intends to switch to signing with a subkey.

Now, the manual page for PKGBUILD states:

validpgpkeys (array)
           An array of PGP fingerprints. If this array is non-empty, makepkg will only accept signatures from the keys listed here and will ignore the trust values from
           the keyring. If the source file was signed with a subkey, makepkg will still use the primary key for comparison.

Please bear with me as I am not too familiar with PGP but, if I am reading it correctly, that means I should not need to change the fingerprint in the PKGBUILD. Is this right?

Furthermore, will users who already have trusted the old signature (generated by primary key) need to once again trust the new one (generated by subkey)? If so, is there anything I could do to ease the passage? I am not sure if having trusted the primary key already means all subkeys will be automatically trusted or not.

Many thanks.

Last edited by Aanok (2019-01-29 18:33:55)

Offline

#2 2019-01-28 09:32:49

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,461

Re: [SOLVED] Upstream switching from primary PGP key to subkey

Users don't have to trust anything, makepkg will trust anything in validpgpkeys. AFAIK, nothing should need to be done, except that it sounds like the package itself doesn't make sense. Why would you package an appimage?

Offline

#3 2019-01-28 09:38:50

Aanok
Member
Registered: 2018-06-11
Posts: 8

Re: [SOLVED] Upstream switching from primary PGP key to subkey

Apologies, I may be using wrong nomenclature. By "trusting" I mean importing into your local keyring. If you don't do that, makepkg fails like so:

FAILED (unknown public key xxx)
==> ERROR: One or more PGP signatures could not be verified!

As per packaging an AppImage, the reason is mostly consistency and convenience. While there are helpers like appimaged or AppimageLauncher that install and track updates for you, the package is for those who'd rather avoid them and use AUR helpers. Visibility is also a bonus for the developer.

Last edited by Aanok (2019-01-28 09:39:50)

Offline

#4 2019-01-29 02:39:23

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: [SOLVED] Upstream switching from primary PGP key to subkey

Aanok wrote:

Apologies, I may be using wrong nomenclature. By "trusting" I mean importing into your local keyring. If you don't do that, makepkg fails like so:

FAILED (unknown public key xxx)
==> ERROR: One or more PGP signatures could not be verified!

That's some pretty bad nomenclature, because in GnuPG parlance importing a key into your keyring is *VERY EXPLICITLY* not going to trust the key.

Importing the key means looking someone up in the phonebook. Trusting the key means posting a notarized document on the front door of City Hall saying "yo, I know this guy, and he's a super trustworthy fellow".

As per packaging an AppImage, the reason is mostly consistency and convenience. While there are helpers like appimaged or AppimageLauncher that install and track updates for you, the package is for those who'd rather avoid them and use AUR helpers. Visibility is also a bonus for the developer.

This logic is automatically invalid.

I've looked up your account name in the AUR and you maintain three packages, one of which is https://aur.archlinux.org/packages/ripcord/, a proprietary, closed-source application that is distributed as a precompiled binary. Your PKGBUILD installs the program so that it properly integrates with the system. This is a much more valid reason, please use that logic next time. wink

Although it is customary for PKGBUILDs which simply repackage upstream's precompiled binaries (whether those are distributed as a tarball or an appimage makes no difference) to be named e.g. "ripcord-bin", this is less certain ground when the software in question is proprietary and will never be able to build from source. IMO you're free to leave it that way, with the caveat that if it were ever open-sourced the package would be expected to migrate to building from that source...

Aside: your PKGBUILD deletes the sources from $SRCDEST and $srcdir, which you must not do. It's not up to you to decide on behalf of users whether they wish to clean up old sources -- they are perfectly capable of building in /tmp, or rm -rf'ing the entire cloned PKGBUILD directory, at their own discretion.

Also, you do not package the license in /usr/share/licenses/$pkgname/ which you are required to do, see https://wiki.archlinux.org/index.php/PKGBUILD#license for more details.

Also I would advise you to reuse $_file in the source=() array, and to use $pkgver inside the definition of $_file, since this prevents having to update the version in four locations every time the pkgver changes.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2019-01-29 09:09:33

Aanok
Member
Registered: 2018-06-11
Posts: 8

Re: [SOLVED] Upstream switching from primary PGP key to subkey

eschwartz wrote:

That's some pretty bad nomenclature, because in GnuPG parlance importing a key into your keyring is *VERY EXPLICITLY* not going to trust the key.

Importing the key means looking someone up in the phonebook. Trusting the key means posting a notarized document on the front door of City Hall saying "yo, I know this guy, and he's a super trustworthy fellow".

My bad, sorry. I thought you would still consider it a form of "trust", just limited to the local machine; something similar to installing self-signed SSL certificates. Thanks for the clarification.

This logic is automatically invalid.

I've looked up your account name in the AUR and you maintain three packages, one of which is https://aur.archlinux.org/packages/ripcord/, a proprietary, closed-source application that is distributed as a precompiled binary. Your PKGBUILD installs the program so that it properly integrates with the system. This is a much more valid reason, please use that logic next time. wink

Truth be told, before I found out there are AppImage helpers that will forcefully register on a MIME type and even bin_fmt, I was quite simply dropping the file in /opt/ripcord. The only reason I'm extracting it is to bypass them. In fact, there is very little integration to be had in any case (just a symlink and .desktop file, really), since the executable is still loading the libraries it came with and not the local ones as it has specific dependencies (e.g. Qt 5.9 while Arch packages are up to date on 5.12). In that regard, I am first of all unwilling to manually track upstream's dependencies and then unaware of any better way to satisfy them short of offering specific packages, which I would quite honestly despise.
I do think being able to track updates and the installation from the AUR offers an advantage over doing so by hand or through the use of a further package manager.
(as a matter of fact, researching about the license as of your following remarks I came upon this snippet on the wiki, which seems to agree)

Although it is customary for PKGBUILDs which simply repackage upstream's precompiled binaries (whether those are distributed as a tarball or an appimage makes no difference) to be named e.g. "ripcord-bin", this is less certain ground when the software in question is proprietary and will never be able to build from source. IMO you're free to leave it that way, with the caveat that if it were ever open-sourced the package would be expected to migrate to building from that source...

Those were my thoughts as well. Also, do note I took over the package after it had already been submitted by somebody else... we will cross that bridge when we get there, I suppose.

Aside: your PKGBUILD deletes the sources from $SRCDEST and $srcdir, which you must not do. It's not up to you to decide on behalf of users whether they wish to clean up old sources -- they are perfectly capable of building in /tmp, or rm -rf'ing the entire cloned PKGBUILD directory, at their own discretion.

I'll correct that, thanks.

Also, you do not package the license in /usr/share/licenses/$pkgname/ which you are required to do, see https://wiki.archlinux.org/index.php/PKGBUILD#license for more details.

I will have to ask, because it is indeed proprietary software but I could not find even a copyright notice, never mind a license file.

Also I would advise you to reuse $_file in the source=() array, and to use $pkgver inside the definition of $_file, since this prevents having to update the version in four locations every time the pkgver changes.

I have a crontab'd script that checks updates and automatically amends the PKGBUILD (I then review it by hand, of course). It actually fetches the download link from a JSON endpoint and computes $_file and $pkgver out of that.


Thanks a lot for the review! I didn't link the package because I didn't intend on asking for one but it's very welcome smile

I could still use some advice on the OP's question, though. In the meantime, I have tested things out and indeed a new import will be required (with the same fingerprint. The subkey has been published to keyservers and is propagating). Is there anything I could do to make this easier on the users? Perhaps print a message? A way to hook into the failed PGP verification would be ideal in that regard, I think.

Last edited by Aanok (2019-01-29 10:29:31)

Offline

#6 2019-01-29 17:24:41

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: [SOLVED] Upstream switching from primary PGP key to subkey

Aanok wrote:

Truth be told, before I found out there are AppImage helpers that will forcefully register on a MIME type and even bin_fmt, I was quite simply dropping the file in /opt/ripcord. The only reason I'm extracting it is to bypass them. In fact, there is very little integration to be had in any case (just a symlink and .desktop file, really), since the executable is still loading the libraries it came with and not the local ones as it has specific dependencies (e.g. Qt 5.9 while Arch packages are up to date on 5.12). In that regard, I am first of all unwilling to manually track upstream's dependencies and then unaware of any better way to satisfy them short of offering specific packages, which I would quite honestly despise.

Nothing wrong with leaving the internal Qt as-is.

Of course, it makes a lot more sense once packaging it in the first place, to do more of the work in advance and set up proper PKGBUILD-style integration rather than having the software dynamically extract itself as temporary files on every single application start.

Also, you do not package the license in /usr/share/licenses/$pkgname/ which you are required to do, see https://wiki.archlinux.org/index.php/PKGBUILD#license for more details.

I will have to ask, because it is indeed proprietary software but I could not find even a copyright notice, never mind a license file.

That's... wow. I'd definitely consult with upstream about announcing what the terms of use are.
There does seem to be license info about additional thirdparty libraries it uses: https://cancel.fm/ripcord/static/app_mi … mation.txt

Also I would advise you to reuse $_file in the source=() array, and to use $pkgver inside the definition of $_file, since this prevents having to update the version in four locations every time the pkgver changes.

I have a crontab'd script that checks updates and automatically amends the PKGBUILD (I then review it by hand, of course). It actually fetches the download link from a JSON endpoint and computes $_file and $pkgver out of that.

Reusing $_file and $pkgver also means it is easier for users to see what changed, as it reduces the file difference when using git log to view the PKGBUILD history.

I could still use some advice on the OP's question, though. In the meantime, I have tested things out and indeed a new import will be required (with the same fingerprint. The subkey has been published to keyservers and is propagating). Is there anything I could do to make this easier on the users? Perhaps print a message? A way to hook into the failed PGP verification would be ideal in that regard, I think.

Oh, if this is about a newly added subkey then having the original key will not do anything as GnuPG won't realize the primary key is the same as the subkey. It's the same as when the user needed to originally import the key, and also, using "auto-key-retrieve" in gpg.conf should make this happen automatically.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#7 2019-01-29 17:36:52

Aanok
Member
Registered: 2018-06-11
Posts: 8

Re: [SOLVED] Upstream switching from primary PGP key to subkey

eschwartz wrote:

That's... wow. I'd definitely consult with upstream about announcing what the terms of use are.
There does seem to be license info about additional thirdparty libraries it uses: https://cancel.fm/ripcord/static/app_mi … mation.txt

Indeed. I have been given a small copyright notice that I'm now prepending to the .txt and installing as LICENSE. Eventually, a proper EULA will be written down by upstream.

Reusing $_file and $pkgver also means it is easier for users to see what changed, as it reduces the file difference when using git log to view the PKGBUILD history.

That is a good point I had overlooked. I'll correct for that too smile

Oh, if this is about a newly added subkey then having the original key will not do anything as GnuPG won't realize the primary key is the same as the subkey. It's the same as when the user needed to originally import the key, and also, using "auto-key-retrieve" in gpg.conf should make this happen automatically.

Ideally, I was hoping for a way to make the transition transparent for existing users (it is the same identity, after all) but I suppose that's not the case. I guess best practice here would be to pin a message on the AUR's webpage for the package, suggesting a --refresh-keys? I couldn't find a clean way to echo a message during build either before PGP verification or on its failure.

Last edited by Aanok (2019-01-29 17:44:13)

Offline

#8 2019-01-29 18:27:11

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: [SOLVED] Upstream switching from primary PGP key to subkey

I'd recommend the pinned comment, yes.

A simple `gpg --refresh-keys` would ensure that all PGP keys which the user has in their keyring are updated to include the latest signatures, expiration date, and subkeys, and should probably be considered good GnuPG hygiene to do on a regular basis no matter what (in addition to solving this case).

Last edited by eschwartz (2019-01-29 18:27:30)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#9 2019-01-29 18:33:33

Aanok
Member
Registered: 2018-06-11
Posts: 8

Re: [SOLVED] Upstream switching from primary PGP key to subkey

Alright, I will do that then. Thank you very much for your help all around! smile

Offline

Board footer

Powered by FluxBB