[openssl-project] FW: April Crypto Bulletin from Cryptosense

[Richard Levitte]

In message <20180406170540.GK80088 at mit.edu> on Fri, 6 Apr 2018 12:05:43 -0500, Benjamin Kaduk <kaduk at mit.edu> said:

kaduk> On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote:
kaduk> > > This is one reason why keeping around old assembly code can have a cost. :(
kaduk> > > 
kaduk> > > https://github.com/openssl/openssl/pull/5320
kaduk> > 
kaduk> > There is nothing I can add to what I've already said. To quote myself.
kaduk> > "None of what I say means that everything *has to* be kept, but as
kaduk> > already said, some of them serve meaningful purpose..."
kaduk> > 
kaduk> > Well, I also said that "I'm *not* saying that bit-rot is not a concern,
kaduk> > only that it's not really assembly-specific." And I can probably add
kaduk> > something here, in addition to already mentioned example of legacy code
kaduk> > relying on formally undefined or implementation-specific behaviour. It's
kaduk> > not actually that uncommon that *new* C code is committed[!!!]
kaduk> > "bit-rotten". So one can *just as well* say that supporting another
kaduk> > operating system has a cost, and so does using another compiler... Why
kaduk> > not get "angry" about that? What's the difference really? Relevant
kaduk> 
kaduk> Yes, supporting another operating system has a cost!
kaduk> At risk of drawing Richard's ire, if we did not intend to support
kaduk> (e.g.) VMS, we might have been able to get away with not writing our
kaduk> own custom build system in favor of some "industry standard".
kaduk> Supporting non-POSIX systems (e.g., Windows) also adds overhead in
kaduk> how we implement many of our interfaces (file handling, thread
kaduk> handling, locking, randomness, etc.).

I can channel my ire, thank you ;-)

But speaking of these things, I somewhat understand where you're
coming from, and somehow, this makes me think of the way the OpenBSD
folks do things, starting with something that's purely and entirely
for OpenBSD, and then expanding it with platform ports, and that's
actually a line of thought I could live with... BUT, and yeah, that's
a bit BUT...  our layering principles currently suck enormously, and
that also adds to the total cost of maintaining stuff.  Basically, we
have a number of platform specific stuff injected in the code a little
here and there, when we really should make the effort of putting
together an architecture independent layer that anyone would much more
easily write an implementation of for whatever new platform that comes
around, and could even come as a separate porting package that someone
else provides.

In a way, the new build system that I put together is exactly meant to
be a thing that makes it easier to port to other platforms, and at
least try to make it so that port could be delivered as a separate
package.  That was always my goal, and that was also the reason I
decided to write it in perl, 'cause that language is already ported to
all kinds of platforms like no other scripting language.  Not even
python, which is actually quite well ported, reaches as far.
(auto* tools are an abomination to try to port to anything that
doesn't look like a POSIX environment.  I tried, about 20 years ago.
Cmake, which was otherwise a strong candidate i my book, has presented
some challenges to port to VMS as well...  others have tried.  I don't
know so many others that have become popular enough to be considered
"industry standards")

But going back to what I said higher up, I very much wish we had an
actual consistent architecture agnostic layer.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/