From owner-svn-src-head@freebsd.org Wed Jun 20 18:58:50 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 9DE4A100464B; Wed, 20 Jun 2018 18:58:50 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49F316D729; Wed, 20 Jun 2018 18:58:50 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from [134.153.27.124] (jacob.engr.mun.ca [134.153.27.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jonathan/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 97E1827C4F; Wed, 20 Jun 2018 18:58:49 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) From: "Jonathan Anderson" To: "Jonathan T. Looney" Cc: hackagadget@gmail.com, "Conrad Meyer" , "Ian Lepore" , "Simon J. Gerraty" , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers Subject: Re: svn commit: r335402 - head/sbin/veriexecctl Date: Wed, 20 Jun 2018 16:28:46 -0230 X-Mailer: MailMate (1.11.2r5479) Message-ID: In-Reply-To: References: <201806200108.w5K18sIR050132@repo.freebsd.org> <96021.1529475664@kaos.jnpr.net> <17033.1529508519@kaos.jnpr.net> <1529510299.24573.5.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed 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: Wed, 20 Jun 2018 18:58:50 -0000 On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote: > On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan > > wrote: >> And I was working on those sets of changes, when work and family >> didn't >> steal away time. I was told that some discussion happened at BSDCan >> this >> year in such that veriexec should go in as-is so it would be there, >> which > is why >> the commit happened (given the review was approved to land back in > January.) > > I will readily admit that I was probably the source of this. My > reasoning > was fairly simple: when a review has been open for over a year with no > action, it seems like the submitter should be able to commit it > without > waiting for more review, if they are confident in their change. I > stand by > that (and, in fact, would substitute something shorter for "over a > year"). > > ([...] I wasn't intending to push Steve to commit > this before he was ready.) I suspect I was part of that push, and while it's provoked some discussion I still think it was the right course of action. Simon and I chatted about these changes at BSDCan (starting with my apologies for not doing the asked-for review two years ago!) and I suggested that, since the changes had been accepted in Phabricator in January and nobody had raised any objections since then (see: D85{61,62,75}), it would probably be better to commit and iterate than to continue waiting for an unspecified number of additional reviews that might never come. Now that the code has landed it's sparked some lively discussion about potential improvements, but that's a much better situation than the silence Steve heard for a long time in Phabricator. So: is there a strong reason why a backout-and-re-commit approach is superior to iterating on the code in-tree? SHA-1 doesn't give me the warm fuzzies either, but I don't see why the whole framework has to be backed out rather than just receive incremental improvements, e.g., disabling or removing SHA-1 while keeping it easy for downstream consumers to re-enable/re-add whatever algorithms their customers want. Jon -- jonathan@FreeBSD.org