From owner-svn-src-head@freebsd.org Thu Jun 21 18:33:41 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EBC31025EC0 for ; Thu, 21 Jun 2018 18:33:41 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F3F889971 for ; Thu, 21 Jun 2018 18:33:40 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 96b42ecd-7581-11e8-aa1a-954dbaed88ca X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 96b42ecd-7581-11e8-aa1a-954dbaed88ca; Thu, 21 Jun 2018 18:33:28 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w5LIXQ32085389; Thu, 21 Jun 2018 12:33:27 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1529606006.24573.30.camel@freebsd.org> Subject: Re: svn commit: r335402 - head/sbin/veriexecctl From: Ian Lepore To: cem@freebsd.org, Stephen Kiernan Cc: Eitan Adler , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Thu, 21 Jun 2018 12:33:26 -0600 In-Reply-To: References: <201806200108.w5K18sIR050132@repo.freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 18:33:41 -0000 On Thu, 2018-06-21 at 11:13 -0700, Conrad Meyer wrote: > On Thu, Jun 21, 2018 at 9:51 AM, Stephen Kiernan om> wrote: > > > > On Wed, Jun 20, 2018 at 10:36 PM, Eitan Adler > > wrote: > > > > > > > > > On 19 June 2018 at 20:08, Eitan Adler > > > wrote: > > > > > > > > On 19 June 2018 at 18:08, Stephen J. Kiernan > > > g> wrote: > > > > > > > > > > Added: head/sbin/veriexecctl/Makefile > > > > > > > > > > ============================================================= > > > > > ================= > > > > > --- /dev/null   00:00:00 1970   (empty, because file is newly > > > > > added) > > > > > +++ head/sbin/veriexecctl/Makefile      Wed Jun 20 01:08:54 > > > > > 2018 > > > > > (r335402) > > > > > @@ -0,0 +1,11 @@ > > > > > +# $FreeBSD$ > > > > > + > > > > > +PROG=  veriexecctl > > > > > +MAN=   veriexecctl.8 > > > > > +SRCS=  veriexecctl_parse.y veriexecctl_conf.l veriexecctl.c > > > > > + > > > > > +WARNS?=        3 > > > > Why are we introducing new code with lower-than-6 warnings ? > > > In all the commotion about the more important issues this fell > > > through.  Also its argument parsing appears to not be using > > > getopt[_long] ? > > > > I replied to this 2 days ago with: > > "veriexecctl came from NetBSD originally and that is what they had, > > but I believe it should be able to be bumped up." > > > > However, there has been some discussion about just not putting in > > veriexecctl for now and wait for some work that Simon Gerraty has > > been > > doing, using some of the work for the verified loader, instead. > > However, it > > would also mean that in the meantime, there would be nothing > > available > > to be able to people to try out veriexec to provide some feedback > > until > > that utility was completed and committed. > Hi, > > While the code is out of HEAD, it can be posted to a github branch > (or > a projects/ branch if you prefer SVN) for people to try. > > Best regards, > Conrad > Yeah, put it on a branch where it'll get ignored for another two years. If this code had been committed long ago, as it probably should have been, then people would have been playing with it, and by time I needed it a few months ago there would have been all kinds of useful info in mailing lists and blogs about how to set it up and what was good and bad about it and so on.  Iterative refinement would have been underway. Instead what I found was a bunch of patches and a big steep learning curve with no existing information about using it in the real world. With that info available, I/we ($work) would have been in a position to quickly adopt it and begin contributing to the ongoing refinement. Instead I had to conclude that product deadlines just didn't allow us to even try to get it working from a standing start as first-adopters, so we had to move in a different direction. Even though this is a better solution than what we did, business practicalities will likely prevent us from circling back and changing everything over to this scheme in the future, so now we'll end up never contributing much to this work. So, IMO, all this calling for things to be reverted isn't just inappropriate, it's actively harmful. This is -current where development happens and imperfection is expected. Hiding work in patchsets and reviews and alternate branches and other shadowy places because it's not perfect is just a way of ensuring it never gets any better. -- Ian