svn commit: r335402 - head/sbin/veriexecctl

[Jonathan Anderson]

On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:

> On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan 
> <hackagadget at gmail.com>
> 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 at FreeBSD.org