Hi PyPA committers,
I'd like to open a vote on transferring pypi-publish to the PyPA
GitLab org (*not* GitHub):
https://gitlab.com/trailofbits/pypi-publish
For a bit of context: pypi-publish is a GitLab "component", which is
roughly analogous to a GitHub Action. Trail of Bits has created this
component as a way to streamline GitLab usage of Trusted Publishing
and attestations, similar to how pypa/gh-action-pypi-publish has
streamlined usage of both on GitHub.
If accepted, I would be a primary maintainer on pypi-publish, along
with my co-maintainer and colleague Facundo Tuesca (@facutuesca on
both GitHub and GitLab).
Separately, the astute observer will note that PyPA doesn't have an
official GitLab org yet. Ee is currently working on having
gitlab.com/pypa released to the PyPA, but in the meantime there's a
"holding pattern" organization with a subgroup for PyPA here:
https://gitlab.com/python-software-foundationhttps://gitlab.com/python-software-foundation/pypa
Best,
William Woodruff
Hi PyPA Committers,
This is an idea I've been discussing with Seth Larson (PSF SDIR, but
who is also a PyPA member and therefore should be on this list).
The TL;DR is this: I did an org-wide scan of PyPA using zizmor[1] a
few days ago, and there are a couple of thousands of CI/CD findings
that would ideally be addressed. Most of these aren't critical (in the
sense that they don't pose an immediate risk to the ecosystem), but
many are the kinds of latent risks/code injection weaknesses that make
campaigns like the one we're currently seeing in npm land easier (with
"Shai-Hulud"[2]).
Basically, what I would like to do is dedicate some time (and snipe
some of Seth's time) for fixing as many of these findings as possible
in the month of December. Seth and I would basically do this in the
clear: we'd work together and submit public PRs, which other PyPA
members (respective owners of projects) would then review and merge.
I'm starting this as a thread because this is a nontrivial
undertaking, and it's going to involve a lot of public activity/review
cycles. So, before I did it, I wanted to gather feedback, namely:
1. Does anybody think we should generally *not* do this?
2. Does anybody prefer we do *not* attempt CI/CD patches on their
specific project(s)? If so, we're happy to avoid those projects; we
don't want to add additional noise or maintenance burden to anybody
who would find it stressful (especially given that it's the holiday
season).
3. Finally, would anybody else like to help?
I'm interested to hear peoples' thoughts, including frank opinions
about whether this kind of mass initiative makes sense -- my approach
over the last year has been to send fixes to projects on a one-off
basis, but I think a "Bug-o-Rama" session could be really productive
for clearing things out in bulk.
As a last note, I've started this on-thread because it has a
security-sensitive nature -- not one so critical that it needs an
embargo or anything like that, but I figured it made sense to solicit
thoughts/consensus here first rather than on DPO. However, I'm happy
to move to DPO if there's consensus that that's a better venue, given
that the work itself will be public as it happens anyways.
Best,
William
(P.S. This is entirely an independent idea -- I'm not representing my
employer or any interests other than my own desire to improve the
security of the PyPA's projects.)
[1]: https://docs.zizmor.sh/
[2]: https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack
