We did something similar at Log4j to publish releases (I did not do that set up but I do help on the project) so that a release manager can use GitHub to publish releases instead of doing it on hardware they control.
Gary On Thu, Jun 20, 2024 at 8:10 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > Unless I hear otherwise, I **assume** there are no big reasons against > this. My plan is that I will add a Github Action (manually triggered, > limited to release managers only) which will NOT build the packages, but it > will download them from `downloads.apache.org` (or dist.apache.org for RC > packages) and publish them to PyPI. This should be really "safe" and will > remove the needs for us to keep local pypi keys to upload the packages. > > This will require repo reconfiguration, so I will have to - likely - open a > JIRA ticket to INFRA - once I do it, I will be happy to describe the steps > for all other projects that upload packages to PyPI and use GitHub. > > Does that make sense? > > J. > > > On Fri, Jun 14, 2024 at 12:14 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > >> My only question is what do the users see in terms of the verified > >> identity that performed the release. Does it still appear to have come > >> from the individual maintainer? The ASF? Somewhere else? I'd only be > >> concerned if the answer was "somewhere else". > >> > > > > Currently users do not see anything. There was a discussion on Python's > > discord about exposing Trusted Published information in PyPI > > https://discuss.python.org/t/pre-pep-exposing-trusted-publisher-provenance-on-pypi/42337 > > as a "pre-PEP discussion". This resulted in Draft PEP 740 - > > https://discuss.python.org/t/pep-740-index-support-for-digital-attestations/44498 > > - where you will be able to upload multiple attestations when you publish > > your packages. So the thinking is that you can have multiple attestations > > of provenance of your package when you upload it to PyPI and a trusted > > publisher will be just one of them. So in our case we could also add our > > own signatures when we publish., This is still draft and we will have a > > chance of influencing the direction, I am sure. Generally Michael and the > > whole security team are on the spree of onboarding more and more projects > > to use trusted publishers and they are planning to discuss and implemented > > more security/provenance features when they reach critical mass (from the > > discussions I had - I believe they are doing very well there - and having a > > stories where prominent projects are on-board is going to help with that as > > well. > > > > J. > > > > > > > > > >> Mark > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > >> For additional commands, e-mail: > >> security-discuss-h...@community.apache.org > >> > >>
