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
