On 31.12.18 10:12, Richard Levitte wrote:
Yes, it's true, new features are going in. And it's true that it's
often more exciting to add new features than to do the janitorial
work.
You realised what I have left unspoken thus far, which is this almost
obsession-like preference of OSS coders to add new features rather than
improving the old, boring codebase. However, there's a reason why it's
still called code*base*. It's the base of everything. And adding more
and more features to that base is going to make ripping off the band-aid
more painful in the long run.
Also, infrastructure again. I, as a user, don't care if the kernel gets
a new feature that makes some black magic happening. What I care about
is that the kernel doesn't throw away my writes (which has happened in
May of 2018, see):
>
https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG%2BvzHun1EqMxyQg%40mail.gmail.com#CAMsr+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@xxxxxxxxxxxxxx)
Cryptography libs should be equally conservative, considering that
cryptography is conservative to begin with. I don't care if TLS 1.3 lets
me use new exiting ciphers and handshakes when it unreasonably bogs down
my server code.
BUT, you also have to appreciate that stuff is happening around us
that affects our focus. TLS 1.3 happened, and rather than having to
answer the question "why don't you have TLS 1.3 yet?" (there's a LOT
of interest in that version), we decided to add it.
Sure, but didn't Matt just say that there are a lot of volunteers
working on that library? The disadvantage here is that quality assurance
is barely a thing - however, the *advantage* of this is that OpenSSL
does not have to follow commercial interests. If we look at this at face
value you could just say "No, people, it's high time we streamline some
of the internal aspects of the library, TLS 1.3 will have to wait. You
can't wait that long? Well, sorry".
However, your message is clear, we do need to do some cleanup as
well. More than that, I agree with you that it's needed (I've
screamed out in angst when stumbling upon particularly ugly or
misplaced code, so the feeling is shared, more than you might
believe).
But what does "cleanup" entail? That's the hot-button question here.
I've already made a suggestion, that is to say, getting rid of opaque
structures. If that is deemed too insecure (for whatever reasons),
export symbols that allow programmers to query the size of structures,
and provide two versions of functions: one function expects the caller
to pass an object to which the changes are to be made, and the other one
allocates the necessary memory dynamically and then calls the first
version. Or just don't allocate my object memory dynamically anymore.
That being said, cleanup happens, and documentation happens, in a
piecemeal fashion, 'cause that's what most people have capacity for.
So, what you're effectively saying is that I'm the first one who ever
asked for SSL object reuse, right? Because if piecemeal work happens on
the documentation, and Viktor says that it's possible, then surely no
one would have ever answered that question on the mailing list and *not*
put it piecemeal-ly in the OpenSSL documentation, right?
Now, here's something else that you need to consider: API/ABI
compatibility needs to be preserved.
No it doesn't. We *know* it doesn't. When OpenSSL 1.1 was released it
broke all *sorts* of applications out there, because all sorts of
applications used struct fields rather than accessors. wget, mutt, neon,
python, you name it, you broke it.
> https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/
So since when do we need to consider API/ABI compatibility? Did we grow
up recently?
Or maybe OpenSSL should have switched the language. The point of C is
that structures are public. And if I'm going to be honest that approach
saved my sorry arse more than a couple times. When zlib choked because
it couldn't go past 4 GiBs of data since its fields were uint32_ts, I
was able to easily workaround this problem. But what do I know.
Counting symbols is, however, nothing other than a blunt instrument.
Quite a lot of those symbols are convenience macros and functions that
have accumulated over time.
You're taking my statement out of context. Counting the symbols wasn't
supposed to suggest that there are too *many* of them. I'm in no
position to say that, seeing as the original context in which my
statement was put is that *I'm not familiar enough with the library*.
What I said was that reading the code is easy. Learning what the library
provides is hard, and that you won't learn much just by looking at the
symbols because there's so many of them.
But nevertheless, I do hear you call for a remake of the SSL API as
well as cleaner internals. The latter is easier, and I'm sure it will
happen piecemeal as per usual so as to not break something /
inadvertently change a behavior (i.e. break ABI). The former is a
fairly massive project, and is more of creating a new API and library
rather than a mere cleanup job. That will be a massive effort, and
you do have to keep in mind how much time all involved can put into
it.
I'm not saying it needs to be done right now. I'm merely suggesting that
it might be a good goal post for OpenSSL 2.0.
Turning structures opaque doesn't prevent people from still messing
with their internal fields.
True. But it makes for a clear delineation where people are forced to
be aware that they are playing with internal stuff, and that it may
not be a safe thing to do.
Then why not provide small helper functions for covering the "playing
with internal stuff" part? That way it's still controlled, and
documented, and unified. You guys must've had some examples to show off
in order to justify the process, so surely you know what it is that
people do when they use internal stuff. Make functions for those. Don't
give them any reason to continue playing with internal stuff.
I don't like code that tries to protect programmers from themselves. I
like code that lets good programmers do smart things. And if bad
programmers use that freedom to do bad stuff, then doesn't that mean
your API simply didn't support this, and they had to make it work
somehow else? Again, helper functions.
Uhmmmm.... this is factually incorrect. OpenSSL doesn't use its own
memory pooling. We have thin wrappers around the usual malloc() /
realloc() / free(), which allows any application to do its own memory
pooling.
>
https://web.archive.org/web/20150207180717/http://article.gmane.org/gmane.os.openbsd.misc/211963
If you don't wanna read too much:
> https://xkcd.com/1353/
Read the mouse-hover text.
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.
Wow...
So what you're saying is that one huge enough mistake, and that
cancels out everything else you do or have done?
If it only was one mistake. I read in June 2014 that Seggelmann was
*also* responsible for the DTLS code:
https://www.openssl.org/news/secadv/20140605.txt
And Thor knows how many others that we aren't aware of.
And just in case you don't get this: this has caused *massive* damage.
It's not just *one* mistake. Heartbleed was caused by input validation
screwups. We've been known since at least the 80s that this causes
widespread issues. For f*cks sake, this November we were informed that
FreeBSD could be pinged to death.
And not only Seggelmann f*cked up. Also the guy who went over his code.
On New Year's morning, no less, where it should have been *clear* that
no one is in the right mental state of mind for that. For instance I
don't do any coding in the evening because I know myself enough to know
that my brain is mush and that whatever I'll produce is equivalent with
horse barf.
So, no, this isn't just *one mistake*. This is "I have no idea what I'm
doing, in a field where certified security experts f*ck up things every
now and then, but I'm doing it anyway for my dissertation" while
everyone was looking away.
Wanna assign incompetence for mistakes like this? In that case,
there's plenty to go around, and there's isn't one single competent
programmer alive. Errare humanum est 'n all that.
Only there's a difference between a mistake and dabbling in forces you
shouldn't dabble in. But again, it looks nice on the résumé.
Genuine mistakes happen, but they *shouldn't* happen in
infrastructure code
It's easy to say. Still, humans err... you can look at any
infrastructure (say, roads) and realise that mistakes are made, and we
try to learn from them.
WE HAVE HAD INPUT VALIDATION PROBLEMS SINCE THE 80S. SO WHAT HAVE WE
LEARNT, HUH? WHAT HAVE WE LEARNT? WE HAVE LEARNT JACK-EFFING-SHTIE.
Decades went by, but we're as arrogant as ever.
I HATE this approach. "Programmers shouldn't be held accountable for
their screw-ups because to err is human" is what it effectively says.
Did this story have ANY consequences for Seggelmann? Not that I'm aware
of. Only when people began to suggest that this may be a backdoor he
felt the need to save face. And as far as I'm aware he hasn't even
apologised once.
But that's what you get when you prefer to add features over a solid
codebase.
Speaking of learning, one of the things we did after Heartbleed was to
put a code review process in place. We do hope that it will help to
keep shitty mistakes out. It's not an absolute guarantee, but we do
believe it's *better*.
It certainly didn't help against:
> npad = (48 / md_size) * md_size
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.
Not that I would know why we should care about shit in other projects
here, but considering it's open source, you could do the required
modification and contribute there.
You're just a bigger target than Apache FCGI. This heartbleed stuff was
pretty much only for Seggelmann's career. And look what kind of example
he set, seeing as I don't see him suffering consequences for that.
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.
I'll gently point out that for non-free / non-open-source code, you
have no idea if the code is shitty or not. All you have to see is the
API.
Unfortunately I never said that I have an idea about whether or not
non-open-source code is good or bad. What I actually said was that
people who do good work should be paid for that, and if they do that for
free that's even more admirable.
(I'm not going to discuss business models on how people can make money
with cryptography code while it still being Open-Source.)
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'm sorry if my code causes that level of angst.
Not the code per se. However I (and several other people I know) have
given up on reading code they weren't paid for. Otherwise they see
things that makes them want to throw it away in disgust, and if that
happens a couple times they're left there with their kernel and a text
editor. It's a self-preservation policy.
So, no, it's *reading* your code that causes ... angst? You used that
word twice now. I don't know what it has evolved into in English, seeing
as I only ever see people accusing others of "being angsty", but just
for the record: in German "Angst" ("a" somewhat like the "u" in "hunt")
means genuine fear and fright. "Angst" and "anxiety" share the same
roots, but "anxiety" is usually more mellow. Not that "anxiety" is the
right word here, again - "disgust" fits better.
However, I disagree with you, we *do* want users to look at our code,
'cause at least some of them will come back and help us improve it.
Or well, we hope they will.
I know enough people who wouldn't, and that's all I'm gonna say about this.
To conclude, I have a question for you: are you only willing to rant
(*), or are you willing to help out in another way?
This is not the question I feel you should ask because we haven't even
established if I *could* make contributions to the project, as my
mindset appears to be so much more different. Especially the idea of not
wanting to break APIs/ABIs is a huge limitation - just looking at
SSL_new() made me give up hope here.
I'm no cryptography expert, I've made that clear from mail one, and my
cleanup jobs would be more widespread than what seems to be deemed
acceptable right now. I can read and write scalable C code, otherwise I
wouldn't even have tried to reuse that SSL object from the beginning.
So, I ask a question in return: what do you think I *could* be helping with?
Also, a happy new year to all.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
