Earlier quoted context omitted.
I don't think so. It sounds like the audit hasn't begun yet, and they don't expect to have anything to publish until the summer.
Oh, you might be right. I must have misread it then.
Yea, we haven't started yet :)
OpenSSL Audit
61–70 of 82 posts
Re: OpenSSL Audit
#62Earlier quoted context omitted.
libressl's binary is already half the size of openssl. I wonder if the audit is re-doing existing work to some extent.
> libressl's binary is already half the size of openssl What does binary size have to do with quality? OpenSSL has been around for a long time, and still is the standard for most deployments. It will take a long time before LibreSSL has been proven enough to become the standard for anything outside the BSD community. For as nasty as the OpenSSL code appears to be, it sure did work (and worked well) for a long time. R…
> What does binary size have to do with quality?
I think grandparent meant that binary size is related to code size. The number of bugs being related to the number of lines of code, you could infer that a bigger binary means more lines of code which means more bugs. In my experience, this tends to be true. Of course this makes the big assumption that the binaries have been compiled with similar compilers using similar optimizations and are both stripped.
Re: OpenSSL Audit
#63Earlier quoted context omitted.
Rust doesn't have custom allocator support yet, so no, it's not currently possible to make this error ;)
It doesn't have custom allocator support as in "you can't have one function allocate memory and pass it for another function to use it", or as in "you can't replace the runtime's own malloc"? OpenSSL were doing the former, not the latter. (Edit: I'm really really curious , not necessarily trying to prove a point. I deal with low-level code in safety-critical (think medical) stuff every day, and only lack of time is w…
You can't say "this vector uses this allocator and this vector uses another one." If you throw away the standard library, you can implement malloc yourself, but then, you're building all of your own stuff on top of it, so you'd be in control of whatever in that case.
(We eventually plan on supporting this case, just haven't gotten there yet.)
Re: OpenSSL Audit
#64Earlier quoted context omitted.
Rust doesn't have custom allocator support yet, so no, it's not currently possible to make this error ;)
It doesn't have custom allocator support as in "you can't have one function allocate memory and pass it for another function to use it", or as in "you can't replace the runtime's own malloc"? OpenSSL were doing the former, not the latter. (Edit: I'm really really curious , not necessarily trying to prove a point. I deal with low-level code in safety-critical (think medical) stuff every day, and only lack of time is w…
Well, anything is possible because ... human ingenuity.
However, Rust currently statically links in jemalloc - even when building a dynamic shared library. There is no easy way around it.
(because someone might ask: rustc -C prefer-dynamic dynamically links everything except jemalloc)
Having said that, I hope jemalloc gets linked externally soon so my code doesn't have to pay the memory penalty in each of my memory-constrained threads.
Re: OpenSSL Audit
#65It's a very sad thing that the world depends on a library that has been virtually unmaintained for years.
My understanding is that they received $1M in donations, etc, per year.
> My understanding is that they received $1M in donations, etc, per year.
They were only getting about $2,000 a year and had one active developer.
[1] http://arstechnica.com/information-technology/2014/04/tech-g...
Re: OpenSSL Audit
#66Earlier quoted context omitted.
libressl's binary is already half the size of openssl. I wonder if the audit is re-doing existing work to some extent.
> libressl's binary is already half the size of openssl What does binary size have to do with quality? OpenSSL has been around for a long time, and still is the standard for most deployments. It will take a long time before LibreSSL has been proven enough to become the standard for anything outside the BSD community. For as nasty as the OpenSSL code appears to be, it sure did work (and worked well) for a long time. R…
> What does binary size have to do with quality?
Do OS/2, 16 bit Windows, and Data General Unix support indicate quality to you?
Re: OpenSSL Audit
#67Earlier quoted context omitted.
> libressl's binary is already half the size of openssl What does binary size have to do with quality? OpenSSL has been around for a long time, and still is the standard for most deployments. It will take a long time before LibreSSL has been proven enough to become the standard for anything outside the BSD community. For as nasty as the OpenSSL code appears to be, it sure did work (and worked well) for a long time. R…
> What does binary size have to do with quality? Do OS/2, 16 bit Windows, and Data General Unix support indicate quality to you? http://opensslrampage.org/
It doesn't indicate either way. If the code is in there, if it works for those platforms, and has no adverse effects on other portions of the codebase, then it doesn't matter (those code paths are never executed unless you run on those platforms).
Re: OpenSSL Audit
#68Earlier quoted context omitted.
No reason you can't look at the recent commits yourself and determine if they are 'mature' enough for you.
They did really try to seize the moment and imho did act a bit disingenuous towards OpenSSL. They even played on the point that OpenSSL's coding style wasn't "modern" and adequate and therefore made it near impossible for people to work on[1]. Since when does having curly brackets on different lines make something impossible to read? They also gutted more than 90,000 lines in the first month (something that would be…
They did, but they also were frustrated beyond sanity at what OpenSSL was doing like adding a wrapper around malloc & free and that was new code not old legacy cruft that can be excused. It also taught us all an important lesson in rage commits when Theo screwed up one of them :-P
Re: OpenSSL Audit
#69Earlier quoted context omitted.
> What does binary size have to do with quality? Do OS/2, 16 bit Windows, and Data General Unix support indicate quality to you? http://opensslrampage.org/
It doesn't indicate either way. If the code is in there, if it works for those platforms, and has no adverse effects on other portions of the codebase, then it doesn't matter (those code paths are never executed unless you run on those platforms).
You can't guarantee that code path never gets executed. For a good historical example, Windows NT4 also came with inbuilt OS/2 and POSIX subsystems that were never used by users, but typically used by people on the internet to crack boxes.
Re: OpenSSL Audit
#70Earlier quoted context omitted.
I don't understand this argument. For example, if I use a language that doesn't allow buffer overflows to happen, I've eliminated an entire class of security bugs being caused by programmer error. Why would you not want to use such a language? Performance and existing libraries will factor in to this obviously but I don't understand why you wouldn't consider security built into the language as a benefit. Yes, securit…
> For example, if I use a language that doesn't allow buffer overflows to happen, I've eliminated an entire class of security bugs being caused by programmer error. There are several assumptions behind "if I use a language that doesn't allow buffer overflows to happen" which you aren't taking into account. For instance, are you entirely sure that the implementation of that language's compiler will not allow buffer ov…
My point is simply that every programmer will make mistakes when coding so I want the most automated assistance possible to point out those mistakes. If a programmer has a pressing need and the persistence to work around those checks, that's fine, at least the surface area for those mistakes are then limited to a smaller amount of code.