Problems with trust path when packaging

[dvzrv]

Hi! 👋

I'm currently looking into upgrading this package on Arch Linux.
Due to the debacle with the removal of signed sdists on PyPI, we have decided to switch to upstream provided, auto-generated source tarballs or (signed) git tags/commit (https://rfc.archlinux.page/0020-sources-for-python-packaging/).

I saw that in 75548f2 you have decided to remove the OpenPGP signing for the PyPI sources (as there really is no other option...). Unfortunately, in that commit you have also removed the signing of tags.
This leaves us with a missing trust path going forward, as we are checking specifically against your OpenPGP fingerprint (29BCBADB4ECAAAC2382699388AFAFCD242818A52) when verifying signatures:
https://gitlab.archlinux.org/archlinux/packaging/packages/python-argcomplete/-/blob/20f889a098774ee099092e154375464203d7244d/PKGBUILD#L18

The last signed tag appears to be the one for 3.1.1.
Would it be possible going forward to rely on tags signed using 29BCBADB4ECAAAC2382699388AFAFCD242818A52?
You appear to be the only person doing releases for your project. In case this ever changes, would you be able to ensure a trust path to any new person being allowed to create releases (by certifying their User ID - aka. "signing their key")?

Many thanks! 🙏

cc @anthraxx

[kislyuk]

Hi! Thanks for your interest in argcomplete and for your efforts to help package and distribute it.

While I agree with the overall design of the web of trust and with the goals of OpenPGP-based software distribution infrastructure, the only implementation that is available to me in my development environments is GnuPG, which has major usability issues that make me disinclined to continue its use. I welcome suggestions of other OpenPGP implementations that have better UX standards compared to GnuPG.

I plan to continue to manage releases for this project for the foreseeable future. If that ever changes, you can expect it to be reflected by the state of this project on a trusted platform like GitHub: the repository will either be transferred to a new organization or a new maintainer, with committer access updated correspondingly.

[dvzrv]

the only implementation that is available to me in my development environments is GnuPG, which has major usability issues that make me disinclined to continue its use.

A common theme 🥲

I welcome suggestions of other OpenPGP implementations that have better UX standards compared to GnuPG.

Do you use a smartcard to work with your OpenPGP private key? If so, there may be something to beta test soon 😉

I plan to continue to manage releases for this project for the foreseeable future.

Just to clarify: Currently, this means you will not be signing tags going forward?

[kislyuk]

I don't have a smartcard, but I have a bunch of yubikeys. Would those work?

Currently, this means you will not be signing tags going forward?

Not with gnupg. It has interrupted too many of my releases with ridiculous bugs and otherwise stolen too much of my time.

It looks like git and github now support signing with SSH keys. If I sign my tags with SSH keys and post my SSH public key in my various online profiles, would that work for you?

[dvzrv]

I don't have a smartcard, but I have a bunch of yubikeys. Would those work?

Yes. (I should have specified what I'm referring to as smartcard is an OpenPGP card - those come in all forms, not just the classic oldschool "smartcard").
I can provide you with more information here, once the tooling is ready! :)

If I sign my tags with SSH keys and post my SSH public key in my various online profiles, would that work for you?

On Arch Linux we have only now started to look into how to do OpenSSH based signature verification sensibly.
If you are going that route, please consider a trust path from your current OpenPGP key 29BCBADB4ECAAAC2382699388AFAFCD242818A52 to the new tooling (e.g. by introducing the new way of signing in a signed commit).

[wiktor-k]

I can provide you with more information here, once the tooling is ready! :)

I heard it's really tasty! 🥯

If you are going that route, please consider a trust path from your current OpenPGP key 29BCBADB4ECAAAC2382699388AFAFCD242818A52 to the new tooling (e.g. by introducing the new way of signing in a signed commit).

Just for the record, this is how the openssh project does that. They do have an "allowed signers" file with all SSH keys: https://github.com/openssh/openssh-portable/blob/master/.git_allowed_signers and the "trust path" is provided by an OpenPGP signature over that file: https://github.com/openssh/openssh-portable/blob/master/.git_allowed_signers.asc

HTH 👋

[dvzrv]

@kislyuk the projects that may be of interest to you are https://codeberg.org/openpgp-card/ssh-agent/, https://codeberg.org/openpgp-card/openpgp-card-tools/, https://codeberg.org/openpgp-card/oct-git and https://codeberg.org/heiko/rsop

With those you can basically maintain an OpenPGP card based workflow for signing and decryption without having to use GnuPG at all.