On Thu, Aug 17, 2017 at 12:24:46PM +0100, Arnt Gulbrandsen wrote: > ael writes: > > I am happy with that. Just as long as one can enable it when > > *necessary*. > > You have a compiler and building is easy.
Are you seriously suggesting that large numbers of Devuan users each need to compile their own versions, and sort out the inevitable dependency problems that will arise, just to do common things like read their email? OK, I have needed to compile and install my own versions of packages now and again, but as it is not something I do often, refreshing my memory and getting back up to speed takes far too long. I have other things to do! > > > What is unacceptable is for Devuan to take away the freedom to read > > email or prevent communication with devices which cannot be updated. > > Keep in mind that compiling with SSL2/SSL3/TLS1.0 support opens the door to > downgrade attacks. Yes, if it is enabled by default. What is now being suggested on the Debian mail thread for offlineimap is that is be compiled in, disabled by default, but with an option to enable it on specific applications. The Debian maintainer has not yet responded to those suggestions. If he accepts something of that sort, Devuan can just use the same package. Otherwise there is a problem if Devuan is to be a viable distribution. > The process works like this: 1. Someone discovers an attack against, say, > 40-bit DES. The only way to remain safe against the attack is to stop using > 40-bit DES. 2. Some maintainers leave in support for 40-bit DES to it can be > used "when necessary". 3. A MITM attacker persuades one end of a connection > that the other end supports nothing better. 4. The connection now uses > 40-bit DES, which the attacker decrypts. > > You want support for the vulnerable protocol when YOU think it's necessary. > But the code doesn't ask WHO thinks it's necessary, you or an attacker. I don't disagree with your analysis, but if the defective protocols are only enabled for specific applications with the user's explicit permission - which would only be for non critical cases like email (where there is real security available with pgp etc) - then that seems a reasonable solution when there is absolutely no chance of upgrading the server. ael _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
