Date: Fri, 30 Nov 2018 11:31:46 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-questions@freebsd.org Subject: Re: Timed releases for the new FreeBSD support model Message-ID: <2177b51e-dc7e-7c3e-b9e6-42fa5e1aaa47@FreeBSD.org> In-Reply-To: <CANtgGBqPj0owzZxzMvfAY_KgFuyNki9L20OtPUdFcdCusDWaQQ@mail.gmail.com> References: <CANtgGBqPj0owzZxzMvfAY_KgFuyNki9L20OtPUdFcdCusDWaQQ@mail.gmail.com>
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. Cheers, Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2177b51e-dc7e-7c3e-b9e6-42fa5e1aaa47>