Christoph Anton Mitterer <cales...@scientia.net> writes: > So what's wrong about my approach, apart from the paradigm "security > first"?
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 plan reality. 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 > 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. 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 succeed. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d29sby0g....@hope.eyrie.org
