On Tuesday, October 25, 2016 7:37:32 PM CEST Kevin Fenzi wrote:
> > 3. AFAIK Fedora has no means by which it can participate in embargoed
> > updates. For this to work, I think there ought to be private git
> > branches, a way to get Koji to make a private build from a private git
> > branch, and a way to get private karma on a private update. Then,
> > when an embargo is lifted, the packager could merge the private branch
> > in, the various infrastructure bits could notice that the very same
> > git commit is now public and permit all of the private builds,
> > updates, and karma to become public and allow an immediate push to
> > updates.
>
> Yep. Thats a gigantic pile of work there for sure.
That's too vague statement, really. Can you make a better estimation? As
far as I understand, there are processes in Debian which allow them
preparing CVE builds so they are able to provide "testing" builds to users
immediately after the public announcement.
Seems like we need to:
[x] have another git repository, say prepared-rpms/PACKAGE
- that's clone of rpms/PACKAGE
- permission bits inherited from rpms/PACKAGE, but not publicly
available for cloning, + security guys
[x] Making sure that only one repo is writeable:
- if prepared-rpms/PKG exists, rpms/PKG is read only
- the info "why" it is read-only shouldn't be public information
[x] Support for "private" builds in koji. Maintainer should be able to re-tag
security/prepared build into public tag once thing is publicly announced.
[x] Nothing changes in bodhi, if we consder 'testing' to be enough for
security purpose. But yeah, there could be 'testing-security' optionally
available for users...
Note that this is not security-only. That's the reason for
'prepared-rpms' prefix, e.g. if we had something like that in Fedora, we
could test/use this feature several times a year as we are informed by
PostgreSQL upstream about upcoming releases, we have tarball in advance
... but now it is shame we are not able to announce updates immediately
with upstream. We are not allowed to share the tarballs with upstream before
announcement, of course.
Pavel
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
