[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote: 
> 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.
Well isn't that somehow the point of discussion and defending one's
opinions? Don't you just do the same?

> 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.)
Uhm,... wasn't you who sparked the discussion about RC4 safety within
I think originally I didn't mention kerberos at all.
So either I should have interpreted your following answers then as a
that's Russ' PoV and thus I'm expected to change my own opinion
accordingly, or I could take it as an invitation for discussion.
Or did I get anything wrong here?

My original point was merely that we have a lot of packages where the
situation seems completely unclear and other packages where upstream
makes bad decisions (e.g. Mozilla).
Now of course we can argue back and forth whether Mozilla's decisions
are good or not; I'd say they've waited well too long (and would
consider my point proven by POODLE), others would say it was right.
But I'd expect that neither you, nor Ian nor I'm the only one here who
studied computer science, mathematics and worked in the security areas
and cryptography, and probably we'll find people agreeing with your or
my position and even those with a completely different one.

Alas, a waste of time, for all of us - surely not what I've meant to
gain with #765512.

> 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
> > OS.
> 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.
Uhm no I really just wanted to understand what you were trying to say.
Your point was (AFAIU) that we're not a specialised distro focusing on
security, right? Next I understood, that we shouldn't place security
above interoperability.
That's why I've asked how that affects those other fields, since usually
all of them mean interoperability problems, or at least that things do
not longer work that straightforward out of the box.

> 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."
I see, well that wasn't clear to me, at least from your previous points.

> 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.
But I guess you're aware, that an attacker usually doesn't wait till
software or a distro starts defending itself?

> 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
> succeed.
Well I think that's a bit unfair towards me.

My original bug (before this was drawn over at d-d) mainly questioned
"what shall we do?" cause right now, it's that we basically do nothing
an hope that the big upstreams just do right and... well I guess no one
really looks at the smart pieces of code.

So it seems you blame me for wasting my (and others time) without any
productive outcome.
OTOH you should see, that what I propose (tighten things up, primarily
looking at security) is rejected... so it seems to me that you basically
say "what you propose is wrong/won't work/is unecessary" but don't come
up with a better solution (except to let things as they are).

Someone has brought up a link before, that Fedora is having some effort
on just this topic (okay I don't know how big and concentrated it
actually is)... but especially when we have so many experts here, like
Ian who said he worked and got promoted in this field, it should be
known that most (responsible) big companies and organisations now have
some folks who basically do nothing but looking into security.
Evaluating the situation and how it can be improved. And those who
didn't have usually ran into troubles.
We have of course the security team, but AFAIU the mostly react on
concrete issues in the sense of security holes.

I just felt like we have nothing as what I've asked for in my original
bug report.

> Anyway, I'm afraid that this whole thread is going to be a waste of
> time, so I'm going to stop responding here.
Since you just told me above that this is mostly nothing Debian should
take care about but rather upstream, Ian agreed with you and since Don
already expressed that he feels it's not right to handle this as a
bug,... I'll think I withdraw myself and apologise to everyone wasting
time about yet another security discussion.

I further think it's appropriate to close #765512, probably I just
overestimated the need for taking action and this is a non-issue.

Anyway,... sorry for causing troubles,

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: