previously on this list people contributed: > On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote: > > Hi, > > > > But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL > > 1.0.1g. > > One of the problems with anything from OpenBSD is that they only > care about OpenBSD, and if you want to use that fork you'll > actually have to go and revert some of the things they're doing. >
Not true actually but of course their primary concern is naturally OpenBSD. They takes POSIX seriously and atleast one patch has brought it closer to POSIX standards. It is also clear to me that Theo wants all to follow and benefit from best practice and bug hunting, the fact that there is so much resistance is not his fault... is strlcpy still rejected by glibc on the false premise of not solving truncation despite better performance than strncpy and when it makes finding truncation much easier! when used how they have been applying it to openssl. https://lwn.net/Articles/507319/ > Some of the things they're changing are actually good changes, > but some are also just wrong. They don't seem to be understanding > why things are the way they are and seem to be changing code they > don't understand. > Based on what? heartbleed happening due to > performance for embedded but there is little need and no need for doing so generically. Sure they are ripping much out and rewriting parts just to get it going on OpenBSD initially with the statement on undeadly that portability can be brought back later. OpenSSH development certainly looks more than co-operative to linux portability. > They also seems to like to do white space changes, which is really > helpful. > Apparently it is to them in following the style(9) they are used to. What's the problem, ignoring whitespace for diffing is easy. > > It's now using native malloc/free instead of its own allocator > > which allowed the Heartbleed bug to happen. > > This did not allow heartbleed to happen. It might have hidden > CVE-2010-5298 more, but it was always there and is unrelated to > heartbleed. > It did because it would have been picked up likely weeks after the bug was introduced due to OpenBSD and Gentoo hardened bug reports or static analysis resulting in bug reports. As Theo says possibly before it was actually released meaning all risk avoided "essentially for free". > > > I wonder if this might result in an alternate SSL/TLS library we could > > use in Debian? > > There are alternatives, but I guess you mean alternative to > openssl. Currently it actually doesn't look like a good option to > me. > If it is more secure then it meets most users needs better and so I disagree. The suggestion was for another package anyway like OpenNTP which avoided the recent security issues. Of course it is too early for this to be done now and who knows how upstream will react but considering their revenue streams that will likely have a lot to do with damage limitation. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd _______________________________________________________________________ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) _______________________________________________________________________ -- 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/602746.76025...@smtp109.mail.ir2.yahoo.com
