-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 23 May 2014 16:21:43 +0200 Tomas Mraz <tmraz@xxxxxxxxxx> wrote: > On Pá, 2014-05-23 at 10:01 -0400, Eric H. Christensen wrote: > > On Thu, May 22, 2014 at 11:26:07AM -0400, Matthew Miller wrote: > > > See <https://fedorahosted.org/rel-eng/ticket/5886>. In short, the > > > time to do an updates compose and push (plus sync times to > > > mirrors) severely limits our ability to put out critical updates > > > quickly. Would anyone be interested in filling out a plan for an > > > alternate repository which would use a special expedited process > > > to make ultra-critical updates available more quickly? > > > > I dislike the idea of a separate repo for ultra-critical updates. > > Once a fix is available for a vulnerability it should, IMO, be > > shipped as soon as possible. I know this doesn't fit into the > > Microsoft model or our model of community testing but really as > > soon as you go public with a fix you've also just notified all the > > "bad guys" out there to the vulnerability and exactly how to > > exploit it. It's a race condition at that point. > > Except the severity of various vulnerabilities is very different. And > the number of the updates that fix serious vulnerabilities is much > lower than the number of the remaining updates (including > non-security ones). Really we have only needed this once in 10 years. Doesn't mean we should not try to fix the issues. > > I'd much prefer to have a mechanism in place that allows these fixes > > to be pushed to the repos almost immediately (once they've been > > properly tested). I'm not exactly sure how this can work but > > perhaps having QE tested patches packaged and ready for the embargo > > time would meet Release Engineering's criteria for testing? > > You have to understand that the repoclosure process takes some time > and the metadata on the updates repository is much larger. This > affects work of release engineers and it basically prevents the > mirrors to sync such large repository too often. I am not trying to be rude here but your statement clearly shows you have no idea how the push process works. There is no use of repoclosure in the push process. how it works is as follows: * we tell bodhi we want to push, it gives us a list of builds and says do you want to . to which we say no. * We sign all updates in the push process. * we tell bodhi we want to push, but say yes do it. * Resign the updates to make sure we catch newer updates. * bodhi updates each update adding comments that update is being pushed * bodhi tags the packages in koji as needed. * bodhi mashes the tags for updates and updates-testing for each release - mashing takes the longest period of time. creating deltarpms is one of the most resource intensive tasks. * bodhi updates the updateinfo.xml files * bodhi updates some symlinks so that the script that syncs the updates to the master mirror can sync * once bodhi detects that the updates have hit the master mirror it then updates bugzilla for each update Matt's idea was to have a repo enabled by default that we can tag builds into a special tag, mash and sync out so that we could get an update like the openssl one out in a matter of minutes to the mirrors rather than hours. we had a netapp upgrade that has sped up the updates process but its still time consuming and quite fragile. Things frequently go wrong on the bag end of bodhi Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTgKOPAAoJEH7ltONmPFDRBboQANDpZogDz2EsZ/3gRw4F0dEY yMuFzy08kf3qOQYw6DZ+iDAg93XGneBClm2W6fOCvI5Ms8xaKo8qyinYc6fPrn+x m3VEFCBIekJAEmM0qHpODnGI79BQ/gAjtckymTk6CjoRu9755ZaFxEHdML9fEUJL 7kDnrobRUU3v1Pz0WZc/2rafyrHQohinpL7YqnoSwpFyoNjWYEKaGnIxg2cWopUg nKsplBh/dchNiMkDsct891K15Yfu48uMuuWGAi9TY7qiW/bDjFpwQm3ilX6LoaMo oZzz8M8PeVPJ5EBiIEQYwUGXbK5FYSW43R2622vXkbS26nPCI6TZpDeaPQwtMM2e JzpMd2vsoGD/GQMuv4Ax4tzsyKS1B4wT4v0bT10K8O6ZAmSK/hZBKmjvqrkAinmf 1QRpsn8PTLXOFoNEZyvJHPoHJtK4Yeo+8CAzPnEgJ0+opjHndrAn8p9KvnMP18yn 93KXWE28JdXcFc7DCoB0X+Sy3bJ6XQurIpC+eVrJgPuXKLdzHyjjyqBIBUWmFGjV etcGw8oVx8STQ8D9i8DLSd9Yer8Yzns+w1c/VH6+6FVx+UuZ0KQ6UkVC/JOg10Cj hjeN5huTYaB7D4buufD7oIrsKZ6GkXYTitIsPtoTn/7IAlcXw+d85dia7VgBPDVy v1G5If4A8Rl/Snd57aG1 =O5eS -----END PGP SIGNATURE----- -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
