On Wed, 26 Oct 2016 12:23:58 +0200
Pavel Raiskup <praiskup(a)redhat.com> wrote:
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.
Well, I don't think I would be the one to provide an estimate, it would
be the authors of all the tools we use that are affected.
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.
So whats the lag here there? they announce and it's an hour or two
until you have finished builds and submitted updates? Is an hour or two
really worth all this... complexity?
kevin