On Wed, 26 Oct 2016 12:23:58 +0200 Pavel Raiskup <praiskup@xxxxxxxxxx> 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
Attachment:
pgpQZGTymZpGa.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
