Re: Pondering security update time frames

On Wed, Nov 2, 2016 at 10:41 AM, Christian Stadelmann wrote: > 1. and 2.: Yes, it often takes at least 3 days for security critical updates > in important packages (e.g. kernel update to 4.8.3) to land. > > I think the real challenge here is to continue shipping

Re: Pondering security update time frames

1. and 2.: Yes, it often takes at least 3 days for security critical updates in important packages (e.g. kernel update to 4.8.3) to land. I think the real challenge here is to continue shipping quality software while reducing time to ship. Scratch builds and release-monitoring.org (Anitya) have

Re: Pondering security update time frames

On Monday, October 31, 2016 9:54:37 AM CET Kevin Fenzi wrote: > > 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

Re: Pondering security update time frames

On 10/31/2016 02:12 PM, Florian Weimer wrote: On 10/31/2016 02:01 PM, Pavel Raiskup wrote: On Monday, October 31, 2016 1:45:22 PM CET Florian Weimer wrote: On 10/26/2016 02:45 PM, Pavel Raiskup wrote: On Wednesday, October 26, 2016 1:33:34 PM CEST Florian Weimer wrote: Debian does not build

Re: Pondering security update time frames

On Mon, 31 Oct 2016 14:12:24 +0100 Florian Weimer wrote: > On 10/31/2016 02:01 PM, Pavel Raiskup wrote: > > On Monday, October 31, 2016 1:45:22 PM CET Florian Weimer wrote: > >> On 10/26/2016 02:45 PM, Pavel Raiskup wrote: > >>> On Wednesday, October 26, 2016 1:33:34 PM

Re: Pondering security update time frames

On Wed, 26 Oct 2016 12:23:58 +0200 Pavel Raiskup 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

Re: Pondering security update time frames

On Monday, October 31, 2016 1:42:12 PM CET Florian Weimer wrote: > On 10/26/2016 02:31 PM, Pavel Raiskup wrote: > > On Wednesday, October 26, 2016 2:03:20 PM CEST Florian Weimer wrote: > >>> However, extending Koji to support "hidden builds" is certainly a good > >>> idea. > >> > >> Trust me, it's

Re: Pondering security update time frames

On 10/31/2016 02:01 PM, Pavel Raiskup wrote: On Monday, October 31, 2016 1:45:22 PM CET Florian Weimer wrote: On 10/26/2016 02:45 PM, Pavel Raiskup wrote: On Wednesday, October 26, 2016 1:33:34 PM CEST Florian Weimer wrote: Debian does not build from SCM, but directly from maintainer-uploaded

Re: Pondering security update time frames

On Monday, October 31, 2016 1:45:22 PM CET Florian Weimer wrote: > On 10/26/2016 02:45 PM, Pavel Raiskup wrote: > > On Wednesday, October 26, 2016 1:33:34 PM CEST Florian Weimer wrote: > >> Debian does not build from SCM, but directly from maintainer-uploaded > >> source packages, so there is no

Re: Pondering security update time frames

On 10/26/2016 02:31 PM, Pavel Raiskup wrote: On Wednesday, October 26, 2016 2:03:20 PM CEST Florian Weimer wrote: However, extending Koji to support "hidden builds" is certainly a good idea. Trust me, it's not. Embargoes are against the spirit of Fedora, and a general hassle for everyone

Re: Pondering security update time frames

On 10/26/2016 02:45 PM, Pavel Raiskup wrote: On Wednesday, October 26, 2016 1:33:34 PM CEST Florian Weimer wrote: Debian does not build from SCM, but directly from maintainer-uploaded source packages, so there is no need to have a private SCM. Do we have a good marketing for the fact that we

Re: Pondering security update time frames

On Thu, Oct 27, 2016 at 07:37:48AM +0100, Peter Robinson wrote: > > simpel problem. It'd be nice if we could reduce that turn-around time > > to hours, if not minutes. > If it takes several goes to get right it's clearly not a simple > problem! I don't think that's so clear -- there's lots of

Re: Pondering security update time frames

On Wed, Oct 26, 2016 at 4:25 PM, Matthew Miller wrote: > On Tue, Oct 25, 2016 at 07:37:32PM -0600, Kevin Fenzi wrote: >> Nope. We have talked about having some kind of fast track, but IMHO, we >> should just get the normal process faster. > > Getting the normal process

Re: Pondering security update time frames

There are some good thoughts in this thread. A few people have suggested that getting the update process to go faster would really help with these problems, and I agree. Patrick Uiterwijk has recently made quite a few contributions to Bodhi that a) make it more reliable, and b) allow it to gate

Re: Pondering security update time frames

https://bugzilla.redhat.com/show_bug.cgi?id=1370061#c7 -- Bojan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

I guess I must have misread this as all kernels built in koji, not just scratch builds. Ouch. -- Bojan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

On Tue, Oct 25, 2016 at 07:37:32PM -0600, Kevin Fenzi wrote: > Nope. We have talked about having some kind of fast track, but IMHO, we > should just get the normal process faster. Getting the normal process faster would help in a large number of other areas. Right now, when we have issues in a

Re: Pondering security update time frames

On Tue, Oct 25, 2016 at 05:59:24PM -0700, Andrew Lutomirski wrote: > 1. Updates, even critical security updates, are very slow. Getting an > update out involves creating a build and an update (which is > reasonably fast for most packages), pushing the update to There are two open tickets on

Re: Pondering security update time frames

On 26 October 2016 at 07:33, Florian Weimer wrote: > For Fedora, I would suggest to replicate the separate security archive with > its push mirrors. The way the Fedora updates repository is updated seems to > cause far more delays than what is lost due to build delays (the

Re: Pondering security update time frames

On Wednesday, October 26, 2016 1:33:34 PM CEST Florian Weimer wrote: > Debian does not build from SCM, but directly from maintainer-uploaded > source packages, so there is no need to have a private SCM. Do we have a good marketing for the fact that we are that "superior" compared to Debian then?

Re: Pondering security update time frames

On Wednesday, October 26, 2016 2:03:20 PM CEST Florian Weimer wrote: > > However, extending Koji to support "hidden builds" is certainly a good > > idea. > > Trust me, it's not. Embargoes are against the spirit of Fedora, and a > general hassle for everyone involved. Vague argument, sorry.

Re: Pondering security update time frames

On Wed, Oct 26, 2016 at 12:23 PM, Pavel Raiskup 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 >> >

Re: Pondering security update time frames

On 10/26/2016 01:45 PM, Neal Gompa wrote: For Fedora, I would suggest to replicate the separate security archive with its push mirrors. The way the Fedora updates repository is updated seems to cause far more delays than what is lost due to build delays (the only part the embargoed builders

Re: Pondering security update time frames

On Wed, Oct 26, 2016 at 7:45 AM, Neal Gompa wrote: > On Wed, Oct 26, 2016 at 7:33 AM, Florian Weimer wrote: >> >> >> Debian has a completely separate installation of its equivalent to Koji (the >> dak part, the builders are separate from archive

Re: Pondering security update time frames

On Wed, Oct 26, 2016 at 7:33 AM, Florian Weimer wrote: > > > Debian has a completely separate installation of its equivalent to Koji (the > dak part, the builders are separate from archive management). Nowadays, it's > source code is mostly up-to-date to what the main archive

Re: Pondering security update time frames

On 10/26/2016 12:23 PM, Pavel Raiskup 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

Re: Pondering security update time frames

On Tue, Oct 25, 2016 at 10:00 PM, Bojan Smojver wrote: > If there existed updates-urgent and updates-urgent-testing repositories > for packages like kernel (example: Dirty COW patch-to-testing wait time > was rather long; note that some people cannot install unsigned kernel >

Re: Pondering security update time frames

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

Re: Pondering security update time frames

On 10/26/2016 04:28 AM, Kevin Fenzi wrote: On Wed, 26 Oct 2016 13:00:07 +1100 Bojan Smojver wrote: If there existed updates-urgent and updates-urgent-testing repositories for packages like kernel (example: Dirty COW patch-to-testing wait time was rather long; note that

Re: Pondering security update time frames

On 10/26/2016 02:59 AM, Andrew Lutomirski wrote: 3. AFAIK Fedora has no means by which it can participate in embargoed updates. Is this really relevant? For how many updates a year would it make a difference? I get that participating in embargoes is important to some people, but in the

Re: Pondering security update time frames

Dnf would need to be taught to do these things, of course The "on the fly" repositories could be defined like any other, using repo files. They could be signed by the same keys updates/updates- testing repos use. Not sure why master mirrors would be required. Wouldn't regular mirrors work, minus

Re: Pondering security update time frames

On Wed, 26 Oct 2016 13:50:11 +1100 Bojan Smojver wrote: > I'm thinking, why not just have these as dump repositories (i.e. just > signed packages) and then have dnf on each system stitch up a repo > from them using createrepo locally. Then you don't need to teach bodhi >

Re: Pondering security update time frames

I'm thinking, why not just have these as dump repositories (i.e. just signed packages) and then have dnf on each system stitch up a repo from them using createrepo locally. Then you don't need to teach bodhi anything. And the number of such urgent packages would always be very low. Essentially an

Re: Pondering security update time frames

On Wed, 26 Oct 2016 13:00:07 +1100 Bojan Smojver wrote: > If there existed updates-urgent and updates-urgent-testing > repositories for packages like kernel (example: Dirty COW > patch-to-testing wait time was rather long; note that some people > cannot install unsigned

Re: Pondering security update time frames

Wouldn't package maintainers get the CVE bug notification from Bugzilla about FF that I pointed to? Given that, the assumption that maintainers are away seems reasonable. Ergo, I sent an e-mail to the list. PS. I also checked FF package git repo, which had no recent commits. -- Bojan

Re: Pondering security update time frames

If there existed updates-urgent and updates-urgent-testing repositories for packages like kernel (example: Dirty COW patch-to-testing wait time was rather long; note that some people cannot install unsigned kernel packages from koji due to grub2 bugs), FF etc., maybe these large (and possibly

Re: Pondering security update time frames

On Tue, 25 Oct 2016 17:59:24 -0700 Andrew Lutomirski wrote: > It seems to me that Fedora has three severe distribution wide issues > relating to security updates: > > 1. Updates, even critical security updates, are very slow. Getting an > update out involves creating a build and

Re: Pondering security update time frames

On Tue, Oct 25, 2016 at 6:03 PM, Adam Williamson wrote: > On Tue, 2016-10-25 at 17:59 -0700, Andrew Lutomirski wrote: >> 2. There doesn't appear to be a working process to get updates out >> quickly. As a current and pressing example, there is no build for >> Firefox

Re: Pondering security update time frames

On Tue, 2016-10-25 at 17:59 -0700, Andrew Lutomirski wrote: > 2. There doesn't appear to be a working process to get updates out > quickly.  As a current and pressing example, there is no build for > Firefox 49.0.2. There isn't really a single 'security update process', no. Releasing security

Pondering security update time frames

It seems to me that Fedora has three severe distribution wide issues relating to security updates: 1. Updates, even critical security updates, are very slow. Getting an update out involves creating a build and an update (which is reasonably fast for most packages), pushing the update to