Open Stack

I'm going to be honest, I'm a little frustrated that this isn't being
treated as a severe security issue; because it is. Regardless of what
people anecdotally say, there are a large number of operators who are
installing and running openstack from pypi. Even larger still are
developers -- like you and I -- installing openstack packages as our user
anytime we run tox tests.

I'm not personally worried too much about the cases where an existing core
or PTL is listed. I'm happy to have a policy argument in that context.
That's not what's happening in the vast majority of these cases. For
Ironic, of the 18 pypi artifacts we have; 14 have maintainers who are not
currently core reviewers or openstack contributors on them -- and a handful
of them have maintainers who I personally have never even heard of (we even
have a `login.launchpad.net_154` as a maintainer on IPA). At any point in
time, one of these people could[1] upload a malicious version of the
package up to pypi and compromise any one of us who are unlucky enough to
run `tox -r` locally before it's caught and rolled back.

I don't think packages that are managed by the OpenStack governance process
should ever have a backdoor open to humans of any kind; but that's not the
case we're arguing here. Right now, we have a large group of untrusted
people with the ability to compromise our developers and users if they are
not securing their pypi accounts well. This is especially true in an open
source climate that is becoming more and more focused on supply chain
risks. That is where my focus lies, and voting to remove those erroneous
maintainers hastily is exactly the sort of decision I'd expect to be made
by the Technical Committee -- even before I was elected to it (and if you
disagree; I'm happy to only serve one term). We have to protect our users
and our contributors.

Our focus must remain on closing this security hole. It does raise policy
questions, but right now I'd rather us put out the fire rather than arguing
about fire prevention tactics.

Thanks,
Jay Faulkner
TC Member
Ironic PTL

Footnote:
1 - Arguably this has already happened once, in the case of
xstatic-font-awesome -- we were just lucky that it was a good-faith release
and not an actual compromised.


On Wed, Jan 25, 2023 at 7:12 PM Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2023-01-25 16:46:03 -0800 (-0800), Clark Boylan wrote:
> > On Mon, Jan 23, 2023, at 5:18 PM, Michael Johnson wrote:
> [...]
> > > I think we should also discuss the following improvements:
> > >
> > > 1. We PGP sign these releases with an OpenStack key, but we don't
> > > upload the .asc file with the packages to PyPi. Why don't we do this
> > > to help folks have an easy way to validate that the package came from
> > > the OpenStack releases process?
> > >
> > > 2. With these signatures, we can automate tools to validate that
> > > releases were signed by the OpenStack release process and raise an
> > > alert if they are invalid.
> >
> > My main concern with doing this is that it requires users to opt
> > into checking it because pip itself is never going to check the
> > gpg signatures. It is better than nothing, but the vast majority
> > of people running a pip install and pulling in random libraries
> > from openstack as dependencies will never validate the signatures.
> [...]
>
> I read this suggestion as having automation or some periodic task
> performed by the release managers or similar group, whereby our
> community checks new releases against available signatures rather
> than at install time.
>
> Worth noting, the release team already periodically runs a script
> which audits all project tags to make sure we have all intended
> packages and signatures in the expected locations. It would
> theoretically be possible to just double check that there aren't any
> extra packages/releases on PyPI that don't correspond to release
> tags in our repositories or are otherwise anomalous (extra platform
> wheels, post versions, et cetera) or which differ from the ones on
> our tarballs site in some way. That should be sufficient to catch
> most possibilities without needing to actually retrieve every
> package so that the signatures for them can be validated directly.
> --
> Jeremy Stanley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230126/add613d2/attachment.htm>