Date: Mon, 17 Dec 2018 06:47:47 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, Warner Losh <imp@bsdimp.com> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org>, George Neville-Neil <gnn@neville-neil.com> Subject: RE: A proposal for code removal prior to FreeBSD 13 Message-ID: <20181217144746.D9D354793@spqr.komquats.com>
next in thread | raw e-mail | index | archive | help
A couple of points: Yes, I don't recall amd(8) or timed(8) ever having CVEs against them -- we = cannot predict the future though. Ntp is another matter. Hardly a year goes= by when we receive yet another update due to a CVE, sometimes more. (Sadly= ntp is maintained only for security patches, all other development has cea= sed.) --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert <Cy.Schubert@cschubert.com> or <cy@freebsd.org> The need of the many outweighs the greed of the few. --- -----Original Message----- From: Rodney W. Grimes Sent: 16/12/2018 23:23 To: Warner Losh Cc: freebsd-arch@freebsd.org; George Neville-Neil Subject: Re: A proposal for code removal prior to FreeBSD 13 > On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil <gnn@neville-neil.com > wrote: >=20 > > > > > > On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: > > > > >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > > >> <gnn@neville-neil.com> > > >> wrote: > > >> > > >>> Howdy, > > >>> > > >>> A few of us are working on a list of programs and other code that > > >>> we'd > > >>> like to remove before FreeBSD 13. If others with to collaborate on > > >>> this > > >>> removal, or discuss it, please do so here. > > >>> > > >>> The list is being maintained on the project WIki: > > >>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 > > >> > > >> > > >> I'm in the process of writing some of the criteria I've been using t= o > > >> drive > > >> discussions. I've promised a formal policy for a long time, but > > >> that's > > >> turning out to be harder than I thought to write and have just > > >> documented > > >> the criteria I look at to do the cost / benefit analysis for things. > > >> It's > > >> skewed a bit towards old drivers and old architectures (or platforms > > >> within > > >> those architectures), but it's likely a useful snowman to work > > >> towards > > >> something better. https://wiki.freebsd.org/ObsoleteCriteria > > > > > > THANK YOU!!! > > > > > >> This doesn't get into the process at all of who to have the > > >> conversation > > >> with, what steps you go through to ensure that there's a transition > > >> plan > > >> for current users (if there's enough to warrant it), etc. It's just = a > > >> set > > >> of things I've found useful to think about and that I think the > > >> project > > >> should adopt (with refinement) as a standard template to use when > > >> making > > >> these calls. > > > > > > Can you also draft a short proposal on the "process" of deprecation? > > > Based I guess on our current model, with the addition of some of the > > > macros and other stuff you and Brooks worked on, the gone_in stuff > > > is what I am thinking. How to do the head commit with the deprecatio= n > > > notices, merge that back if applicable, then do the remove when > > > appropriate. Basically a more complete flushed out version of: > > > > > https://www.freebsd.org/doc/en/articles/committers-guide/article.html#r= ules > > > @ 17.4. We should also IMHO do some work smithing and rearrangement > > > to > > > make this read much more as steps, some of the steps as listed have > > > substeps that appear to be overlooked often. > > > > > > Something like this: > > > 17.4. Deprecating Features > > > > > > When it is necessary to remove functionality from software in > > > the base system, follow these guidelines whenever possible: > > > > > > 1. Use of the deprecated feature generates a warning. > > > 2. Mention is made in the manual page and the release > > > notes that the option, utility, or interface is deprecated. > > > (I removed the word possible here, we should always > > > mention deprecation of features in the release notes) > > > 3. The option, utility, or interface is preserved until > > > the next major (point zero) release. > > > > Given the age of some of the things in our tree, of which timed was a > > classic example, I hardly think that this rule will work in our favor. > > Removing old code reduces our attack surface, and keeping something > > that's been dead for years, for another 2 years, seems problematic at > > the very least. Some of the software now on the proposed removal list > > should have been gone by 11 or 12. Not giving the users proper and adaquate notification is asking for problems as well. In the case of amd(8) at least the man page has had a obsolete notice in it with a pointer to autofs for some time (my 11.1 systems have such notice, not sure how far back that goes.) And again, age is not the correct metric, BSD is near 40 years old, I think the word you want is obsolete, which is more correct. Also timed appears to be in use, so what might be dead to you=20 is useful to someone else. I would also argue that the attack surface of timed is much smaller than the attack surface of ntpd, shall we remove ntpd to reduce our attack surface? I can not recall any cve against timed, I can recall many against ntpd. > > >=20 > If it's old, we should remove it. The one major release thing is nice to > have in the steady state where you are caught up and retire things just i= n > time. For the backlog we have, though, it will just get in the way. But i= n > this case all we need to do is a direct commit to fix the man page in 12 = to > say it is gone in 13.... Yes, we can short circuit the process, but we should not just skip the process. Need to fix both the man page and the binary to output a message when it is invoked, and that needs to be commited to both stable/11 and stable/12. The prefered method would of been to do the notification stuff in head, then merge that back to stable/11 and /12, then do the remove in head. --=20 Rod Grimes rgrimes@freebsd.= org _______________________________________________ freebsd-arch@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181217144746.D9D354793>