Open Stack

I agree with Jay's summary below wholeheartedly.

It is good that this issue has also highlighted other issues with the
current maintainers&owners lists. The bottom line anyways is that the
current state of affairs *must* change and a policy be created and
kept in check going forward.

Radek
-yoctozepto

On Thu, 26 Jan 2023 at 18:53, Jay Faulkner <jay at gr-oss.io> wrote:
>
>
>
> 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.