Learn more about these different git repos.
Other Git URLs
This is a difficult feature, because koji has for so long assumed transparency. However, it is something that folks have requested, and it is certainly a valid need.
How best to accomplish this is an open question.
It's also worth pointing out that for most instances, Koji is just one piece of the puzzle. For example, it's not that useful to have koji hide a build if the changes are publicly visible in source control.
For now this is a placeholder for discussion. If you have ideas about this, please discuss them first before investing any significant effort.
Are some of these other parts already done, so we can see how they affect koji? Typically distgit?
I am unaware of work on other parts.
With git, you can't really limit read access to part of a repo, so the answer is probably to have a separate cloned repo with limited read access, possibly on a separate server entirely. With dist-git, you also have the lookaside to worry about. A similar approach might be needed there.
In such a case with git, you'd need a tool to merge into the main repo when the embargo lifts. Easy enough with the git part, but the lookaside would require a little work. Probably this could be mostly automated in pyrpkg.
Even with a parallel embargo dist-git system, you still have access questions on the parallel server. How fine grained does it need to get? Is it sufficient to have a single group that has embargo access (can see all embargoed work), or do you need to do it per package, or something even more complicated?
One possible approach with Koji is to do something similar to what I've described above for dist-git. Set up a parallel instance for the embargoed builds with limited access and move them over once the embargo is lifted.
You can technically do this with Koji as-is, but it would be a lot of work and not very satisfactory.
Could we invent/extend the permission of tag to mark the access of builds/packages? Can I assume that, embargoed = cannot do anything with the build? How could we control the download permission via apache dynamically? I'm not familiar with apache httpd, so not sure it would work? 1. user-request: Create a tag with some privilege assigned to some user/group koji will store this information in DB. koji will create a dictionary with limited read access by user/group - not sure how to do here, by a generated .htaccess with user/group files or with wsgi-script? 2. user-request: tagBuild buildA to this tag koji will move the resources to this dictionary.
Could we invent/extend the permission of tag to mark the access of builds/packages?
Depending on how find grained we need to get, perhaps permissions could be part of it, but at present permissions do not control all the access we could need to limit.
Can I assume that, embargoed = cannot do anything with the build?
Correct. Not even read access. Not even detecting its existence.
How could we control the download permission via apache dynamically?
You have latched onto one of the trickier parts. There are a couple possibilities here. One, we could have koji serve up the files itself, so that is can apply access checks. Two, we could have embargoed builds use a different storage volume that is not included by the public facing file server. As a distant third, I guess we could do something dynamic with .htaccess files, but there are a lot of issues there.
Like I said, hard problem.
Login to comment on this ticket.