On Tue, Apr 3, 2018 at 6:30 PM, Justin Forbes <jforbes@xxxxxxxxxx> wrote:
>>
>> If there actually was a good explanation for the tie-in, it should
>> have been front-and-center and explained as such.
>>
> Honestly, yes, the major distros have been shipping this patch set for years
> now, and every time it comes to upstream, the same damn arguments emerge.
Well, I think it's because the explanations have been bogus.
Just look at this thread. It took closer to a hundred emails (ok, so
I'm exaggerating, but not _that_ much) until the *real* reason for the
tie-in was actually exposed.
For the first 50+ emails, the explanation was "oh, only if you do
secure boot does this make sense".
Which is still pure BULLSHIT. Of _course_ that kind of stuff raises
peoples hackles and makes people not trust the messenger - he's
clearly being evasive and there must be something else going on.
So instead of the bullshit explanations, just explain the purely
_practical_ side.
Because I find it a *lot* more convincing to hear:
"We'd like to just enable it all the time, but it's known to break
some unusual hardware cases that we can't fix in software, and we
wanted *some* way to disable it that requires explicit and verified
user intervention to do that, and disabling secure boot is the
easiest hack we could come up with".
See? No bullshit. Just straight talk about the *actual* reason why
people decided on this particular tie-in, and admitting that it's a
hack, but also clearly stating the reason for the hack.
Now, I still don't necessarily agree that it's the best possible
option, but when stated in those terms I at least understand why that
option was picked as a reasonable one, and it changes the discussion a
lot, and (at least for me) makes it much more palatable.
Because as long as the explanation is just some "you must use secure
boot or you've already lost and further security is pointless"
hocus-pocus magical thinking, I immediately go "no, that sounds
completely bogus, and it makes testing and coverage much worse, we've
done other things quite like that without this secure boot tie-in".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
