The libevent issue (Was: Re: checking in)

[Mark Atwood]

Ive reached out to contacts of contacts at "Red Hat Consulting for the Public Sector” about how they deal with libevent2’s absence in RHEL6 on DOD systems.  Unfortunately, its now past 6pm in Raleigh and in DC on the US Thanksgiving Holiday.

Mayhap I get some suggestions back next week.

..m


On November 25, 2015 at 1:23:02 PM, Eric S. Raymond (esr at thyrsus.com) wrote:
> Joel Sherrill :
> > I have been attempting to build on CentOS/RHEL 6 and 7. I filed tickets
> > based on experiences on each
> >
> > CentOS 6 does not have an RPM for libevent2. Thus without special work by
> > each person building NTPsec, it won't build. AFAIK this distribution is the
> > latest RHEL approved for use on DoD networks. I could not find a STIG for
> > RHEL 7 so any organization which requires the DISA STIG to be applied is
> > stuck at 6.
>  
> This is a little bad, but not unrecoverable. Only ntpdig requires libevent2;
> ntpd, in particular, builds without it. If we have to document that as a
> limitation I don't think we're going to lose customers over it.
>  
> I have changed the ticket to have the 'build' label and asked Amar to change the
> build so it fails gracefully in the absence of libevent2, making everything
> but ntpdig.
>  
> > My CentOS 7 was missing a package and the build didn't disable the
> > reference clocks that depended on it. Ticket filed.
>  
> This can be fixed with a relatively minor build system tweak. I have added
> that request to the ticket.
>  
> > The CentOS 6 issue raises some questions. Did we intend to support this OS?
> > Long term, it highlights the problem of assuming a newer external support
> > library is going to be part of a LTS OS distribution. I don't know if this
> > was on the master list of supported OSes and checked when libevent2 as a
> > dependency was discussed. I don't recall having a checklist OSes to ensure
> > we checked all.
>  
> I guess now is a good time for me to come clean about one of the
> assumptions behind my original technical planning.
>  
> I never pushed having a checklist of OSes to support for the same
> reason I advocated coding to a strict POSIX.1-2001/C99 baseline.
> (Joel, this discussion took place well before you were on board.)
>  
> Experience with GPSD had persuaded me that the traditional Unix
> strategy of keeping a lot of porting code around just in case led to
> carrying a lot of historical baggage that had outlasted its time. I
> believed having a large a-priori set of Unix variants to support would
> pull in that direction as well, and it was not the direction I thought
> we should go. I believed our overwhelming priority should be reducing
> attack surface by discarding code.
>  
> See the project motto: "Perfection is achieved, not when there is
> nothing more to add, but when there is nothing left to take away."
> This choice was not just me being cute - I viewed it as a direct
> implication of our security focus.
>  
> In accordance, I deliberately went to the opposite extreme - to be as
> aggressive and strict in platform requirements as I thought I could
> get away with, in order to throw away as much code as possible,
> and then patch around the resulting porting issues.
>  
> So far this strategy has had exactly two real downsides:
>  
> 1. We've had to simulate POSIX clock_gettime() for MAC OS X using a native call.
>  
> 2. The libevent2 dependency blocks ntpdig on CentOS 6 and older NetBSDs as well.
>  
> If these are the worst problems we have as a result - and that looks likely
> at this point - I'm going to claim a strategic victory. We are, as far as I
> know, good on all *current* LTSes.
>  
> Now here's the controversial part:
>  
> In truth, I was anticipating something like the libevent problem
> (failure to insta-port to older releases) with an attitude almost like
> hope. That is, if we hadn't run into *anything* like it, I'd consider
> that I hadn't pushed quite hard enough towards "nothing left to take
> away". While I would have lived with that outcome, I would have
> considered it suboptimal.
>  
> In effect, I was hoping for a sort of optimal pain level, enough to signal
> strong success at the clean-up-and-pare-down without seriously messing
> up functionality. I think we have that.
>  
> I'll admit to having been a little quiet and sneaky about that
> success criterion; I didn't want the arguments I'd get if I made it
> explicit.
>  
> Finally, I will observe that if this let-it-break-a-little stance seems
> like a dicy or over-bold choice to have made, some reflection on why
> Classic NTP stagnated may be in order. Fear of breaking anything can
> be a trap; among other reasons you want a system architect around is to
> exercise judgment about when it's time to bust out, judgment that takes
> into account the whole-life-cycle perspective. Including considerations
> like reducing downstream maintainance costs, attack surface and
> defect rates.
> --
> Eric S. Raymond
>