On Wed, 2014-10-15 at 21:55 +0200, Jonas Meurer wrote: > While I appreciate your efforts to raise security-relevant topics within > the Debian distribution, I have to admit that exactly the same happens > to quite a few of your "meta-bugreports" as well. There's a lot of > discussion and a few changes here and there, but then the bugreport is > forgotten and nobody cares anymore. Sure, Jonas, I know,... and basically nothing has changed,... or well not much at least... and the same with the discussion about secure APT, downgrade/blocking attacks, the stuff about package downloaders, etc..
I mean that's just the problem what I try to explain every time again,... it won't just work if you have some lone knights trying to do this on their own, given the vast number of packages and software affected, it's rather something a larger group would need to do. Or even better, having guidelines, set up by such expert group, and maintainers of packages should need to check through them... just like proper auditing works. But here comes the difficult part: It's usually not easy to get people into a security conscious thinking, so one won't find many people fighting this quest along one's side. In practise it's even worse,... not rarely you have to fight maintainers like windmills, endless discussions about what can be considered enough secure, or whether it's more important to have stuff just being colourful™ and working out-of-the-box™, rather then secure. And these are only the problem's to the point, when you may break peoples' setups which actually should break, because they're highly insecure. That's just as with the SSLv3 thingy... Mozilla for sure would argue "well we had to keep it that long for interoperability". When you then come to actual technical issues, as there *may* be with my request to considerably shorten the validity times for Release files... it's even more difficult to get something going. Of course the respective developers have their own projects they want to follow, but of course it should also be clear that one single person (like me) cannot easily get fully involved in dozens of complex projects like APT (and the security stuff - at least when one wants to do it right - usually requires deep knowledge). So you're absolutely right, when you say that not much comes out,... but I guess for a single person it's not easily possible to do more than constantly pointing at such issues, trying to start organising efforts and then helping along. > If you feel like keeping track of those distro-wide changes, I think a > properly maintained wiki page is much more appropriate for that purpose. Well I had that once[0] ... but the problems above remains,... if there aren't more people that jump on the train - especially the affected maintainers - you drive into a dead end > In most cases your claim is true, but in some cases there might be > reasons for keeping support for old/broken algorithms. And as I wrote, I fully agree,... I mean this is basically what Russ said in the other post: On Wed, 2014-10-15 at 12:55 -0700, Russ Allbery wrote: >For another example, upstream for both Heimdal and MIT Kerberos know >very well what the situation is with the RC4 use in the Kerberos >protocol and are making well-informed decisions based on compatibility >with existing clients Okay what does that mean? AFAIU it means: well there are still so many people with outdated software out there, we can't just disable RC4, even if it's broken. I see it a bit differently: RC4 is broken. Full stop. Therefore new versions clients and servers should per default not use/enable/accept it. Of course Russ is right, that this would cause interoperability issues,... but IMHO that should be manually decided by the admins/users. If an kerberos admin says "well I still want/need to provide/trust RC4" he should manually need to enable in the configs. Same for a user/client, the other way round. So I'm not saying that old broken/algos should be thrown out completely[1] - they should just not come into use without user/admin intervention. > I suggest to file > individual bugreports against particular packages, ideally already with > suggestions/patches on how to fix them. Mhh... nah I don't agree here. Discussing that with every package maintainer is actually what makes it impossible to ever finish... I rather think there should be project wide guidelines how to deal with such questions. Nothing that needs to be cut in stone and where one cannot make exceptions in valid cases. If there was consensus on how we actually want to handle security (here in the sense of cryto strength: strong, medium, weak, none) then it makes sense to move to the next step an actually implement it. But as we've just seen... people's views already differ too much here to have a staring point: One says interoperability is important and one musn't break working systems just for security... another one like me says rather break stuff (and let people then decide what they actually want) but to hell with MD5, SHA1 and ideally even distrust the NIST ECDSA curves ;-) As you can see from Jonathan's mail, we even cannot agree on whether having broking algos is a bug or just meta-bug ;-) Cheers, Chris. [0] https://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices [1] actually I was quite surprised before, when doing some tests with openssl s_client,... and it really didn't support -ssl2 anymore (even though still in the --help and manpage)
smime.p7s
Description: S/MIME cryptographic signature
