Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate (and eventually remove) PGP/GPG support? #1009

Open
woodruffw opened this issue Aug 27, 2023 · 3 comments
Open

Deprecate (and eventually remove) PGP/GPG support? #1009

woodruffw opened this issue Aug 27, 2023 · 3 comments

Comments

@woodruffw
Copy link
Member

woodruffw commented Aug 27, 2023

First of all, thank you for twine! I'm a daily user both professionally and personally, and it's been a joy to use.

This is intended to be an RFC/proposal issue for a feature removal, so I've elided some sections below where I believed them to be irrelevant. Please let me know if I re-add them.

The Issue

PyPI removed PGP support in May 2023: since then, pre-existing PGP signatures have continued to be hosted, but new signatures are silently ignored when uploaded alongside a new distribution version.

twine still has a handful of flags and options that reflect PyPI's previous support for PGP, namely --sign, --sign-with, and --identity. These flags still take effect and perform local actions, but ultimately have no effect on the state of the package index. This in turn is a potential source of user confusion: while the index's behavior has been publicly documented, the presence of "supported" PGP/GPG flags on the uploading client side might lead them to believe that some form of PGP signature uploading is still supported or effective.

The Proposal

I propose a deprecation and removal period for these flags, as well as their corresponding parts of the twine codebase. In particular, I propose two discrete phases: a deprecation period during which time these flags cause DeprecationWarnings (or similar), followed by a hard removal period during which the twine CLI no longer recognizes them and exits with a failure code.

The use of a deprecation period here is arguably a little funky, since the underlying behavior has already been removed on the index side. On the other hand there is probably a decent amount of CI/CD automation out there currently using these flags (effectively as no-ops), so giving them a deprecation period before making a breaking change on the twine CLI side will help them perform a graceful migration.

Other considerations

This is intended to be a non-exhaustive list:

  • Other indices? twine supports uploading to an arbitrary index; are there popular third-party indices that still support PGP signatures?
  • Alignment with other uploading clients? I don't think Poetry ever supported PGP signatures; I'm not sure about others.

Please let me know what you think! If this proposal seems interesting and valuable, then I'd be more than happy to do the work here.

@sigmavirus24
Copy link
Member

Other indices? twine supports uploading to an arbitrary index; are there popular third-party indices that still support PGP signatures?

I don't know and that's the big question I have. Are other folks using other indices signing things due to some misguided understanding of what signing does for them?

Alignment with other uploading clients? I don't think Poetry ever supported PGP signatures; I'm not sure about others.

Poetry was developed long after PyPI started to elide signatures from the UI. Twine has been around longer and was a replacement for setup.py upload which had similar functionality which needed to have essentially the same functionality to get people to migrate.


Overall I'm supportive of this because every few years someone wants support for some other binary name, so I'd love to get rid of that altogether.

That said, I still don't know what we don't know (is anyone using this for anything other than PyPI) and for the people that are using it for PyPI , do they actually understand that PyPI isn't storing those signatures? I guess the first step is for twine to add a deprecation warning when that flag is used or an armor file is detected and being uploaded to PyPI.org and maybe issue a different warning for folks using a different index.

@woodruffw
Copy link
Member Author

Are other folks using other indices signing things due to some misguided understanding of what signing does for them?

Maybe @dstufft would have some knowledge here? ISTR him being aware of other bespoke indices 🙂

I guess the first step is for twine to add a deprecation warning when that flag is used or an armor file is detected and being uploaded to PyPI.org and maybe issue a different warning for folks using a different index.

Makes sense to me -- I can open a PR to do that tonight or tomorrow.

@woodruffw
Copy link
Member Author

Answering my own question: it looks like pypiserver explicitly advertises PGP support on uploads. There seem to be a lot of tutorials out there explaining how to deploy it on various cloud services, so it's not inconceivable that someone is relying on that behavior.

(That being said, it looks like it supports plenty of other upload mechanisms, including SCP. So twine dropping support wouldn't preclude someone from uploading PGP signatures another way.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants