On 30.12.18 00:04, Matt Milosevic wrote:
> I do not want to complicate matters further, but there needs to be one
> thing clear here: this library is mainly developed and maintained by
> /volunteers/.

For some reason you seem to think this excuses something. I don't.

Fact is: there are a lot of things that could be improved.
Fact is: there are a lot of things that aren't improved, however there are still features added every now and again. The latest things I've seen thus far in the code is TLS 1.3 and kernel TLS. That's nice to have, don't get me wrong, but the base here has been broken for years, and is even made *worse* over time. Opaquing structures so that people cannot know how big they are anymore, which is required for determining the amount of memory such an object needs, has been done in 2016. So, apparently people are *willing* to do wide-spread rewrites of things and are even willing to break existing applications for newer versions (which is brave, again, don't get me wrong here), but ... seemingly not in what I'd call a positive direction.

Turning structures opaque doesn't prevent people from still messing with their internal fields. We know that because people have been doing that on Windows handles for ages, so it only makes their jobs a little harder on that field. On the other hand, turning structures opaque for people who want to *work* with the library, to want to do smart things because they know the requirements of the applications, are actively being hindered by this approach. It adds a lot of code and complexity to the library side, which already *has* a lot of code and complexity by its nature of being a *crypto* library. And it does not even make memory contents more secure, as Heartbleed has shown the world - from what I've been told the reason for why those memory dumps always looked so juicy was because OpenSSL used its own memory pooling. So what is even the point of opaquing here? And yet there's been put a lot of time and effort into this mechanic.

The point is that those volunteers you mentioned happen to volunteer to work on actively bad stuff and/or in an actively bad way. Seggelmann was a volunteer, wasn't he, and he did the hithertofore greatest damage to OpenSSL and cryptography because of his incompetency, whether it was a genuine mistake or intentional. I see a lack of *respect* for OpenSSL in that people who probably *shouldn't* be working on it still work on it as volunteers, because it looks nice on the résumé, and check in shoddy code. Genuine mistakes happen, but they *shouldn't* happen in infrastructure code - and I think I've made myself already clear that I view cryptography as infrastructure. Saying "yeah, well, they volunteered, they put in the time and effort, we should be thankful for that" is not enough. I don't care if the engineer who's building the bridge is being paid or not (he should be, though); what I care about is that the bridge doesn't collapse when a stronger wind appears. Same with code: I don't care if you volunteered to work on SSL or if you're being paid for it, what I care about is the quality of your work. I'd rather have no work at all from you than work that is just bull. I'd rather have no encryption at all than so-called "export encryption" that's been lobotomised for commercial use. And I'd rather walk those 300 meters using a mountain path than using a bridge that didn't cost anything and doesn't look very stable. /At the very least I'll have some sort of security, may it be that we need a dedicated secure channel rather than cryptography, or maybe adding a rail to the mountain path/. And in that sense not having or not wanting to have some sort of leverage against someone who repeatedly sends in shit code is a negative - not a positive.

I also think you're *sorely* underestimating how low people can steep just to say "I've been working on OpenSSL" or "I've been working on the Linux kernel" or "I've been working on Apache". The Apache FCGI module for Perl does not support printing out UTF-8 data to this day - in fact there's code that checks if the UTF-8 is set, and implicitly downgrades that string to ISO-8859-1 if so. If it can't do so it gobs a retarded warning into your server logs. The module's apparently been written in 2003 and received an update in 2010. Did this update get rid of the warning and/or the downgrade? Nope, neither of those. The update merely changed the warning to "[this] will stop wprking [sic!] in a future version of FCGI". In 2010. If this wasn't someone who just wanted to be able to say that they've been working on Apache FCGI I'm going to eat a broomstick, as they say in German.

So, no. I will not show respect to bad code just because it's cheap or free. My respect goes to people who do good stuff, whether it's for free or not. People who just provide shitty things for free deserve shitty respect at best. In turn, people who do good stuff for free deserve a lot of respect without asking for it. You want the same respect? Then maybe not let any volunteer check in code just because they can.

And more often than you'd think "no deal" can still be the best deal if the seemingly only other best deal is still a shit deal. I've been told a lot of Brits are learning that lesson these days.

On 30.12.18 03:40, tincanteksup wrote:
On 29/12/2018 22:08, C.Wehrmeyer wrote:

How am I supposed to get more adept when the documentation is a literal mess?

Let me reverse that: What is the *point* of getting more adept with the API when I feel more and more disgusted by learning how it's working internally?

Welcome to The Jungle ..

I don't get the message. Care to elaborate?

Getting a feeling for the tidiness of the source code isn't a hard problem. If I want to look at the source code of SSL_new() that's not terribly hard. One fgrep through the source directory lists "ssl/ssl_lib.c" amongst other hits, and unlike those other hits this one shows the type it returns (SSL *) and doesn't end in a semicolon. Then just search for SSL_new() until you find it, and then start reading away.

Getting more adept with the library in general? That's hard. There's 280 symbols just starting with "SSL_" in 1.0.0 alone:

$ nm libssl.so.1.0.0 | grep ' SSL_' | wc -l
280

I'm not going to drop all those symbols on you, but how is one to know which function or macro or whatever is the ticket here? The documentation barely helps, we've already established that. Source code reading? That reveals the things that I *do not* want to know too, because it makes me feel uneasy - which really is the point here: you *never* want to reach a point where your users are brought to the point where they start reading your source code, because even though that might teach them what to do it makes them unable to sleep at night. I've had that problem with the nouveau driver, which wrote random numbers to random hardware registers without even trying to make some sense of it, in other words it was completely undebuggable; I've had that problem with freetype, whose API was even worse than OpenSSLs because they didn't even *attempt* to give higher-levels the option to pass pointers to cached objects, so they'd constantly allocate and free subobjects via malloc() and free() every time an object was created; and I've had that problem with PCSX2, which, at least the last time I checked, doesn't support x64 builds and is as such limited to a reduced amount of virtual memory space, which it actually sorely needs for image file mappings and random access therein. Well, that, and the fact that instead of using a static buffer with static size for the window title update function they're using lots of dynamic buffers and reallocations each time the function is called.

Why do I mention all of this? Because in all those cases I didn't have to know exactly what those functions and programs did for me to be able to tell that things were messy.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to