A bit of background:

packit team came to infrastructure asking for a was to reduce privs that they have: https://pagure.io/fedora-infrastructure/issue/10763

ie, they wanted to not have commit on any of the packages (maintainers would ack PR's), but then they could not submit bodhi updates, so they wanted a way to just do that.

If FESCo thinks this is not desired, we can of course adjust it. It seemed to me to be a win to reduce some privs packit bot used to have, but it's of course a tradeoff.

CC: @mmassari @ttomecek

Thank you @kevin for bringing this ticket to our attention. You explained it perfectly. Our aim was to reduce privileges, not increase them.

I'd like to understand what is actually the point of having production koji builds with no bodhi updates. When I do an official build of my package, it's always my intention to get it to stable repos. This is the use case we are trying to solve: reduce this one manual step and make it easier for maintainers to have new bodhi updates created for them.

We're happy to be part of this discussion and reach a consensus that everyone will be okay with. We never wanted to bypass Fesco, the guidance we received was to just open infra tickets.

Side note: I recently also filed a ticket about koji having zero access controls (basically anybody can submit a build of any git commit for any package for any release). If that's ever fixed, packit will be affected by that as well.

Maybe a small note to add.

Ideally, we would like to have explicit per-package approval and have it just for the single action we actually do (Koji build or Bodhi update), but sadly that wasn't technically easy to do on the infra side.

For the record, I think that it should always be a human who decides what builds end up grouped in what updates and what karma limits and other settings the updates should have. But if the humans who are responsible for those decisions want a bot to decide those for them (for example because they always do single-package updates and leave the default settings anyway), I don't think we can stop them from doing this.

It seems there are 2 (currently possible) options to allow a bot to make an update of a package:

• explicitly give the bot commit permissions to the specific package which means the bot can now commit directly or merge PRs
• let the bot create updates from existing builds for all Fedora packages

I think the possible damage of a rogue bot merging/pushing a bad change to dist-git is worse than the possible damage of a bot creating arbitrary updates from builds already pushed/reviewed by humans. Hence, I think I can live with this solution and I don't think FESCo necessarily needed to be involved.

The intention might have been to reduce privileges, that's not what appears to have happened though? Instead of having slightly too many privileges for packages where the maintainers have explicitly opted in and agreed to using the bot, the bot can now create (and presumably modify / obsolete / etc.) bodhi updates for all packages, whether the maintainers opted in or not.

A bit of background:

packit team came to infrastructure asking for a was to reduce privs that they have:

More precisely, the packit team asked for a mechanism to replace commit privileges, which were per-package and explicitly given, with a narrower privilege that would only allow creation of package updates. This was hard to implement because of technical limitations, so they got a wider privilege to bypass all bodhi ACLs (via membership in the admin_packager_groups).

I think it would have been nice if FESCo was involved in this decision, and a public announcement was made to all packagers, instead of a quiet decision being made in a infra ticket.

That said, I agree with Miro:

I think the possible damage of a rogue bot merging/pushing a bad change to dist-git is worse than the possible damage of a bot creating arbitrary updates from builds already pushed/reviewed by humans.

I'd like to understand what is actually the point of having production koji builds with no bodhi updates. When I do an official build of my package, it's always my intention to get it to stable repos.

This topic has come up before, and actually it is not allowed to do koji builds for other purposes than official updates. People were using rawhide as a kind of CI and were explicitly told not do do that. I think this was clarified in our docs somewhere, but I don't have a reference at hand, though I recall @adamwill was involved.

I think that it should always be a human who decides what builds end up grouped in what updates and what karma limits and other settings the updates should have.

Hmm, this isn't directly related to the question of permissions, but, assuming that by "decide" you mean the current explicit interaction with bodhi, I would disagree. We currently do automatic updates for rawhide, and it works fairly well. I would like to allow packagers to use the same mechanism to submit updates for branched and stable releases. For many packages, updates are single-package updates, and the packagers doesn't do anything except copy or reword the latest changelog entry into a bodhi update description and accept other defaults. In particular, bodhi is able to connect rawhide updates to bugzilla bugs using the changelog, and it could the same for all updates. Update creation could be automated to remove one manual step that doesn't provide any benefit to the users. Of course this should be opt-in, to allow more complicated cases to be handled manually.

(In other words, the packager should be able to decide to do no grouping and use default karma limits before starting the koji build and walk away after the build has started with the knowledge that an update with a proper description and links to bugs will be automatically created.)

I think this should be one of the next steps in the process of automation of packaging.

The discussion has stalled. @decathorpe, do you maybe have some proposal for a solution, either immediate or aspirational, so that we can derive some positive action from this?

We currently do automatic updates for rawhide, and it works fairly well.

We only use Bodhi for Rawhide because it's currently the only way to trigger automated testing. When we first did it, nobody actually wanted it (I still kind of don't). It's a poor example because it exists as an implementation detail for the sole purpose of being able to automated checks on package builds.

We could trigger the testing other ways, as I recall the reason it's hooked into bodhi is because we need a way to display results and a way to let people submit waivers and otherwise interact with tests.

The discussion has stalled. @decathorpe, do you maybe have some proposal for a solution, either immediate or aspirational, so that we can derive some positive action from this?

Not really. I don't think making packit privileges "narrower" but non-opt-out-able instead of being opt-in on a per-package basis is fine. But if other FESCo members don't see a problem with that, then I will shut up.

This was discussed during today's meeting. While people have various opinions, the general consensus is that the situation is acceptable, considering technical limitations and we won't take any action now.

@zbyszek Thank you very much for taking the time to discuss that!

We are not changing anything then on Packit side, but are prepared for a revisit if/when needed.