Re: Bug#765512: general: distrust old crypto algos and protocols perdefault
Christoph Anton Mitterer <email@example.com> writes:
> So what's wrong about my approach, apart from the paradigm "security
It feels to me like you're spending lots of time telling other people
they're wrong and telling other people what they should be spending time
on, and then arguing with anyone who tells you that how you're going about
this isn't effective. I find myself feeling frustrated and demoralized
rather than inspired to go do a bunch of work on something that you care
about. That energy would be better put into making an actionable plan for
accomplishing something and then inviting people to help you make that
Your response to this message is another good example. I pointed out that
everyone knows that RC4 needs to go away and that the Kerberos upstreams
have long-term plans for how to do that with a reasonable level of
disruption, and your response was paragraphs about how horrible RC4 is.
One, you're preaching to the choir, and two, I don't understand what
you're trying to accomplish by haranguing me about this. You seem to have
entirely missed the point I was trying to get across, which is that many
upstreams are closely monitoring these issues and have a plan already,
and, when that's the case, their plan is probably better than something
Debian would come up with for their software. (As Brian points out, this
isn't always the case, but that was partly Joey's point: we need to look
at whether upstream is engaged and has a plan, or whether they're ignoring
the problem or unaware.)
If you think upstream's plan is wrong, then you need to go argue with
*them* about that, not with us, unless upstream is *so* wrong that it
looks like we should just fork. For good upstreams, such as the Kerberos
upstreams, they generally have crypto expertise in their team already and
can have a detailed discussion with you about exact threat models and
timelines for deprecating enctypes. When that sort of expertise exists
upstream, I'm arguing that this is not the effective place to do
something. Diverging from upstream has a rather significant cost,
particularly if we diverge from upstream and then *get it wrong*, which is
not outside the realm of possibility.
And then you go on to put words in my mouth, like this:
>> If we were making a security-hardened distribution that chooses
>> security over interoperability across the board, we may well want to
>> make other decisions.
> So you suggest against efforts of securing / hardening Debian? What
> about introduction of hardened compiler flags, apparmor, selinux, etc.?
> I personally don't think that hardening contradicts being a universal
which is just frustrating. I feel like you're turning my opinion into a
parody of what I said to make it easier to argue with.
Of course doing those sorts of things is consistent with being a universal
operating system. But you'll notice that Debian did hardening roughly
around the same time (or even a bit later) than other major distributions,
which was nowhere near as fast as some of the security-focused
distributions did it. And I'd love to have a solid and reliable SELinux
setup that we could just turn on, but *everyone* in the Linux distribution
space has found that extremely difficult to achieve. My point is not
"don't do security stuff." My point is "Debian is not going to be on the
cutting edge of disabling features in the name of security."
In other words, if your primary concern is security, Debian is always
going to be a little slow for you. I don't think that's a problem, nor
does it imply that Debian should *never* push on security. Just that
Debian is not a distribution that values security *above everything else*.
There are some distributions out there, including Debian derivatives, that
*do* take that approach, and I think that's very valuable for seeing just
how far one can push security measures and how much breaks.
Anyway, I'm afraid that this whole thread is going to be a waste of time,
so I'm going to stop responding here. I just hate to see people wasting
their time writing long replies to threads like this that are going to go
nowhere because there's not an effective structure for accomplishing
anything, which is why I (and several other people here) are trying to
nudge you in the direction of something more productive and more likely to
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>