This ticket is summary of my discussion with @puiterwijk about a possibility to grant modularity-wg permissions to submit ODCS compose requests of module source_type.
module
There is no tool (way) for module developers to test the module they just built in Koji. Since module is an RPM repository with additional metadata, they would have to download all packages from Koji tag, generate the metadata themselves and create repository.
This is problematic from following reasons: There is no tool to generate these metadata - this is normally done by Pungi during the compose. They would need to download all the packages, even if they don't need it in the end, to be able to generate the metadata and correct repository. * There is no guarantee that module repository will match the one generated by official compose of a module, because tooling is simply different.
By allowing modularity-wg group creating module composes using ODCS, they don't need to write any additional tools to generate the compose, they can download locally only packages they want and the compose is quite close to the one generated in the release time, because ODCS uses pungi.
They will be able to:
module-*
They specially won't be able to:
platform:f28
There is currently no code in Pungi which could be used to generate compose with platform module included, so it is not even clear right now how to disable generation of such compose. Once the Pungi gets such feature, we will adjust ODCS to fulfil this requirement.
platform
We need an agreement on this plan. During the initial audit done by @puiterwijk, we did not mention ODCS could be used by wide list of Fedora contributors - we simply didn't know it will be useful for them for this use-case. This may open new attacking vectors, because for now we only allowed other services submit ODCS compose requests, but now we want to open it to real people, :). although limited to certain FAS groups.
Metadata Update from @ralph: - Issue tagged with: authentication, odcs, security
Is there any progress on this? It would be really helpful to use ODCS for devel-testing modules before distributing them to wide audience as bodhi updates.
Metadata Update from @kevin: - Issue assigned to puiterwijk - Issue priority set to: Waiting on Asignee
+1
It's rather risky not to have this capability.
It's rather unfortunate that one has no way of testing a just built module without releasing it first.
I was hoping that we could get to use the new layered pungi run system for this, so the attack surface would decrease significantly. Is the intention still to do that, and if yes, would it be possible to wait for that to go live to proceed and open this functionality up to other people?
@puiterwijk: If you mean running pungi in runroot as Koji task, then this is not currently the way how we can deploy the ODCS. The reasons for that is that OSBS needs ODCS to build any container and spawning extra runroot tasks for that slows the container build a lot. That's main reason why we keep running pungi on our own machine.
ODCS can still run pungi in runroot, but for simple cases like "generate repository from koji tag including these packages", it is too heavy solution.
What are the issues you see with current aproach? The /mnt/redhat is mounted read-only, odcs is running as unprivileged user, the code generating the compose is completely different process on a system, ODCS does not need to have admin koji rights. I think there is no way to attack anything beyond the ODCS machine itself and its shared storage, which does not hold any important data.
I will try to find you on Flock to discuss that while we are both here.
If we can keep /mnt/koji mounted read-only, my concerns are alleviated, and you get a +1 to move this forward. Thanks for making that clear.
Metadata Update from @puiterwijk: - Issue untagged with: security
Metadata Update from @puiterwijk: - Issue priority set to: Waiting on Reporter (was: Waiting on Assignee)
@jkaluza It looks like there is an agreement. Can we finally get this finally implemented?
Bump, any progress here?
I will take care of configuring this.
Metadata Update from @mizdebsk: - Issue assigned to mizdebsk (was: puiterwijk) - Issue priority set to: Waiting on Assignee (was: Waiting on Reporter)
Done.
Metadata Update from @mizdebsk: - Issue close_status updated to: Fixed - Issue priority set to: None (was: Waiting on Assignee) - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.