Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Nov 2018 11:31:46 +0000
From:      Matthew Seaman <>
Subject:   Re: Timed releases for the new FreeBSD support model
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 29/11/2018 16:53, D. Ebdrup wrote:
> In lieu of any suggestions for where discussion can take place in the
> announcement email, I figured it'd be best to start this here. So with
> that said, and since FreeBSDs support model is changing, I've been
> wondering whether its possible for FreeBSD to have timed releases - so
> here's something to get a conversation started on that:

Core is handling the discussons and will be meeting with FreeBSD 
developers and corporate users during various events, developer summits 
and conferences.  There isn't really a public conversation about this at 
the moment, but it's unlikely to happen on freebsd-questions@...

> Can FreeBSD do timed releases?
> They have advantages and disadvantages, of course - but I'm wondering
> if the advantages outweighs the disadvantages.

Yes, FreeBSD can, and will, do timed releases.  In principle it already 
does, although the schedule seems pretty elastic.

The main points of contention are about how frequently updates should 
happen, how long those are supported for and how many concurrent 
branches should be available under support.  There seems to be two 
different groups of users, one of whom needs a stable API and KBI for 
long term (eg. 5 years), and the other which needs to be updating pretty 
rapidly and always staying within sight of the bleeding edge.

> Does anything stop timed releases from being possible with the way
> FreeBSD currently does releases?
> E.g. picking features from a stable branch, instead of shoveling
> everything in the repository into a release to get it out on time
> (which I don't think anyone wants?).
> Assuming there are other issues, can these be fixed?

There is a question about what changes can be allowed within a 'stable' 
branch -- so that eg. 3rd party kernel modules should continue to work 
across the lifetime of the branch, there should not be major changes to 
APIs and ABIs, so for instance the update to openssl-1.1.1 currently 
happening for 12.0-RELEASE.  These considerations already exist but the 
details will need to be codified and laid down for whatever upgrade 
scheme we come up with.

> In a similar vein, I think there's some questions FreeBSD needs to
> answer before making the decision on whether it should have timed
> releases, if it's possible. Here's some:
> Is a timed release delayed if someone emails so@ with patch for an
> exploit that's in a release while it's being built?
> Personally, I think I'd prefer a release be delayed slightly as
> day0/day1 binary updates seems irresponsible to me (read: distributing
> releases with known security exploits, that is).

We've always worked on the principle that releases are released only 
when they are ready, so, yes, security advisories and last minute 
regressions can delay a release.

> What happens in case a PoC appears after being withheld until a
> release has been built?
> Presumably the only way to fix that is with a binary update.

It's not the existence of a proof of concept that matters; it's whether 
there is public knowledge that a particular vulnerability exists.  If 
you where there's a vulnerability, then generating an exploit is 
relatively easy.

Usually this is handled under a process of 'responsible disclosure' -- 
people that discover a vulnerability will contact software providers 
privately and give them a reasonable time to generate fixes.  Then at 
some pre-agreed time, all of the providers publish their fixes pretty 
much simultaneously and the original discoverers publish their work.

If this process were to span the time when a new FreeBSD release was in 
progress, then the correct response would be to carry on with the 
release and publish a security advisory and patches post-release once 
the embargo period was over.

> And finally: Can pkg'd base change any of the answers - to me, it
> seems like an obvious candidate for making timed releases easier, but
> I might be missing something obvious.

Correct.  pkg base is going to help with the way releases are handled. 
Once pkg base has had the bugs ironed out and is fit for purpose, which 
is slowly being worked on.



Want to link to this message? Use this URL: <>