Timed releases for the new FreeBSD support model
Matthew Seaman
matthew at FreeBSD.org
Fri Nov 30 11:31:51 UTC 2018
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 at ...
> 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.
Cheers,
Matthew
More information about the freebsd-questions
mailing list