Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

30-Day Status Update On LibreSSL

Soulskill posted about 5 months ago | from the all-the-hyperlinks-you-can-handle dept.

Encryption 164

ConstantineM writes: "Bob Beck — OpenBSD, OpenSSH and LibreSSL developer and the director of Alberta-based non-profit OpenBSD Foundation — gave a talk earlier today at BSDCan 2014 in Ottawa, discussing and illustrating the OpenSSL problems that have led to the creation of a big fork of OpenSSL that is still API-compatible with the original, providing for a drop-in replacement, without the #ifdef spaghetti and without its own "OpenSSL C" dialect.

Bob is claiming that the Maryland-incorporated OpenSSL Foundation is nothing but a for-profit front for FIPS consulting gigs, and that nobody at OpenSSL is actually interested in maintaining OpenSSL, but merely adding more and more features, with the existing bugs rotting in bug-tracking for a staggering 4 years (CVE-2010-5298 has been independently re-discovered by the OpenBSD team after having been quietly reported in OpenSSL's RT some 4 years prior). Bob reports that the bug-tracking system abandoned by OpenSSL has actually been very useful to the OpenBSD developers at finding and fixing even more of OpenSSL bugs in downstream LibreSSL, which still remain unfixed in upstream OpenSSL. It is revealed that a lot of crude cleaning has already been completed, and the process is still ongoing, but some new ciphers already saw their addition to LibreSSL — RFC 5639 EC Brainpool, ChaCha20, Poly1305, FRP256v1, and some derivatives based on the above, like ChaCha20-Poly1305 AEAD EVP from Adam Langley's Chromium OpenSSL patchset.

To conclude, Bob warns against portable LibreSSL knockoffs, and asks the community for Funding Commitment. The Linux Foundation has not yet committed support, but discussions are ongoing. Funding can be directed to the OpenBSD Foundation."
Update: 05/18 14:28 GMT by S : Changed last paragraph to better reflect the Linux Foundation's involvement.

Sorry! There are no comments related to the filter you selected.

Video of the presentation (4, Informative)

ConstantineM (965345) | about 5 months ago | (#47028377)

Re:Video of the presentation (5, Interesting)

Anonymous Coward | about 5 months ago | (#47028445)

Go go go LibreSSL, you guys have my complete support!!! I've filed four bugs and two enhancements with OpenSSL over the years, and all of them have been ignored by the OpenSSL devs. That's lame. I knew OpenSSL was a festering crock of shit, but what were we to do. Now we have LibreSSL and I would encourage everyone to send support, even if only just a pizza, and use LibreSSL.

Re:Video of the presentation (0)

Anonymous Coward | about 5 months ago | (#47030463)

Man is not a bad speaker. I found that rather enjoyable.

As surprise ponies are always fun.

All hail Theo! (-1)

Anonymous Coward | about 5 months ago | (#47028457)

We're not worthy!

Re:All hail Theo! (-1)

Anonymous Coward | about 5 months ago | (#47028475)

Theo is a known prick, no point in you trying to troll that. But they still make cool stuff :)

Re:All hail Theo! (1)

dreamchaser (49529) | about 5 months ago | (#47029441)

I couldn't care less if someone is a prick as long as they produce good product.

Re:All hail Theo! (2, Funny)

Anonymous Coward | about 5 months ago | (#47029519)

It's a matter of mistranslation. In Canadian, "Fuck off or I'll beat you with a hockey stick!" means "We would like to help you with your problem. However, I'm afraid the solution you are proposing would not work for the reasons we have already stated on a previous correspondence[3]. Maybe we could work together in the future.".

Throwing out all compatibility hooks makes it easy (3, Insightful)

Antique Geekmeister (740220) | about 5 months ago | (#47028501)

If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.

Re:Throwing out all compatibility hooks makes it e (4, Insightful)

sulfide (1382739) | about 5 months ago | (#47028521)

if its a festering insecure pile of shit who cares if it runs on more platforms? got to start over at some point, maybe work on a better foundation before more platforms...

yes, they don't plan to support big-endian x86 (2)

ConstantineM (965345) | about 5 months ago | (#47028527)

Like the big-endian x86 support in OpenSSL?

OpenBSD's OpenSSH has a separate portability layer, and they're doing just fine without the extra malloc wrappers. And no big-endian x86 support, either!

Re:yes, they don't plan to support big-endian x86 (1)

rev0lt (1950662) | about 5 months ago | (#47028909)

Big-endian amd64. Its even more funny.

Re:yes, they don't plan to support big-endian x86 (0)

Anonymous Coward | about 5 months ago | (#47028933)

not as funny as the 64-bit Win16 support. On VMS.

Re:yes, they don't plan to support big-endian x86 (1)

Anonymous Coward | about 5 months ago | (#47029433)

Hey, that's mean!
I'm working on the VMS port to MS-DOS team, in order to run Microsoft Word 6.0 spellchecker on George R.R. Martin's writing box.
If you want to read book six you better support OpenSSL for us!

Re:yes, they don't plan to support big-endian x86 (1)

Barsteward (969998) | about 5 months ago | (#47030151)

george uses wordstar 4.0...... and doesn't use a spell checker.... might have been better to use the correct info this for your jape..

Re:Throwing out all compatibility hooks makes it e (3, Informative)

kiddygrinder (605598) | about 5 months ago | (#47028555)

they're mostly throwing out really old multi-platform stuff, like dos, vms, ebcdic, win16 etc.

Re:Throwing out all compatibility hooks makes it e (2)

ron_ivi (607351) | about 5 months ago | (#47029773)

Wonder if the OpenSSL guys have a good consulting business maintaining exactly those ports for ancient government projects.

Throwing out all compatibility hooks makes it easy (4, Informative)

Warren Parker (3658033) | about 5 months ago | (#47028621)

The goals of LibreSSL include preserving API/ABI compatibility (keeping LibreSSL as a drop-in replacement).

Re:Throwing out all compatibility hooks makes it e (3, Interesting)

Antique Geekmeister (740220) | about 5 months ago | (#47029317)

API/ABI compatibility is not the same as cross platform compatibility: the difficulties with 'malloc' incompatibility that led to replace a core libc function clal are precisely the sort of thing that the LibreSSL developers can simply throw out. Replacing it for cross-platform is an excellent example of the difficulties of just such cross compatibility work: preserving the ABI for some of the odder platforms on which OpenSSL currently works is precisely the cross-platform work that the LibreSSL developers can discard. And yes, it will speed the performance of the code. (Rewriting and replacing malloc for cross-compatibility is _guaranteed_ to be slower than native libc functions.)

I'm not suggesting that OpenSSL did not need a stripping of debris and a rewrite. I'm suggesting that if you ignore cross-compatibility and the installled user base, it's much easier to clean up old code.

Re:Throwing out all compatibility hooks makes it e (0)

Anonymous Coward | about 5 months ago | (#47028663)

You're still running OS/2, VMS, ancient DEC Unix or pre-NT Windows?

Re:Throwing out all compatibility hooks makes it e (1)

rev0lt (1950662) | about 5 months ago | (#47028921)

I'm assuming you're running a system with full blown CGA or EGA drivers, then. 1990 called and they want their DOS floppy back.

Re:Throwing out all compatibility hooks makes it e (0)

Anonymous Coward | about 5 months ago | (#47030107)

Hold up. We're going to use CGA until this new-fangled EGA stuff proves itself in production. Kids these days, always onto the next fad.

Re:Throwing out all compatibility hooks makes it e (2)

unixisc (2429386) | about 5 months ago | (#47029541)

If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.

Interestingly enough, that principle doesn't apply to OpenBSD itself, which considers it important to support dead platforms like the Alpha.

Re:Throwing out all compatibility hooks makes it e (3, Informative)

ld a,b (1207022) | about 5 months ago | (#47029711)

This is because the C standard is full of crap such as undead(maybe it was half-unsigned?) chars and non-zero NULL and Harvard architecture hacks. If you want to be sure your program will work as intended when some starry-eyed clang/gcc developer reasons he can optimize away your security code because it is undefined behavior, you must support all the brain-dead architectures that motivated the standard, in order to serve as canaries.
This is not related to supporting non-standard shitty libcs and OSes which run on 64-bit architectures and yet do not support 64-bit pointers.

Re:Throwing out all compatibility hooks makes it e (5, Insightful)

the_B0fh (208483) | about 5 months ago | (#47029779)

They are re-writing LibreSSL for *OPENBSD* across all the hardware platforms OpenBSD runs on.

Once they have stabilized it, another team, the Portability team, will then add a portability layer for other OSes.

What is so difficult to understand, and why is everyone getting their knickers up in a bunch over it?

If you like OpenSSL, continue to use it. If you want a safe, secure ssl implementation, you wait for them to finish LibreSSL and use OpenBSD. If you want a safe, secure ssl implementation on other OSes, you wait for the Portability team to finish its work. To help speed it up, donate $$ so that they can bring in more programmers.

Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).

Re:Throwing out all compatibility hooks makes it e (0)

WaffleMonster (969671) | about 5 months ago | (#47030165)

To help speed it up, donate $$ so that they can bring in more programmers.

Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).

Good idea.. I think I'll donate to the OpenSSL team who created and maintained the project for all these years.

Personally I have no reason to believe BSD is any more capable considering laundry list of CVE's for OpenSSH including an insane PAKE credential bypass.

Also turned off by lack of professionalism. Too many commit comments are childish reflecting lack of discipline I am uncomfortable seeing applied to a project of this type.

Re:Throwing out all compatibility hooks makes it e (5, Insightful)

serviscope_minor (664417) | about 5 months ago | (#47030327)

Good idea.. I think I'll donate to the OpenSSL team who created and maintained the project for all these years.

You mean the ones that made the heartleed bug and let bug fixes and reports rot in the tracker for 4 years?

Personally I have no reason to believe BSD is any more capable considering laundry list of CVE's for OpenSSH including an insane PAKE credential bypass.

To which CVE do you refer?

Also turned off by lack of professionalism. Too many commit comments are childish reflecting lack of discipline I am uncomfortable seeing applied to a project of this type.

Well, here's something you'll hate even more. You know that the mathematiians that develop the underlying crypto algorithms also have a sense of humour and sometimes say things/crack jokes in frustration? Basically the jokes on you. Because the "unprofessionalism" goes all the way down to the maths and you can't escape it.

You have weird ideas of professionalism, by the way to the extent where I suspect you're a suit. It seems you consider cracking jokes in commit messages and on a project mailing list to be more important indications of professionalism than, say, letting bugs rot in a bug trcker for years and coding up and effective anti exploit mitigation layer in a crucial security library.

Re:Throwing out all compatibility hooks makes it e (0)

Anonymous Coward | about 5 months ago | (#47030235)

What is so difficult to understand, and why is everyone getting their knickers up in a bunch over it?

The OpenBSD project used to be pretty rude to a number of people (mostly you could understand why, but that doesn't justify). While some of this is just ignorance much of it is likely people wanting to get back at them and people from the various security services trying to spread dissent.

Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).

He's bitching, whether he realises it or not. He didn't point to a single instance of Alpha support slowing down other platforms. His analogy doesn't apply just because they provide portability. It applies if providing portability to old platforms such as the Alpha slows down the development of OpenBSD, which it probably occasionally does and on the other hand probably keeps people interested in developing on their old Alpha machines contributing and so overall has a positive effect.

Re:Throwing out all compatibility hooks makes it e (5, Insightful)

gnasher719 (869701) | about 5 months ago | (#47030447)

If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.

As a person making their living writing software for MacOS X and iOS, do I care about this code running in MacOS 9? I don't care one bit.

They explain it very well: You don't need to be "multi-platform" if you are standard. Instead of "we have thirteen implementions of SSL_memcpy that run on a dozen completely outdated platforms that nobody cares about", they use memcpy and say "if your platform doesn't support a standard C function correctly, fuck you and your platform". Which is the correct approach.

Multiplatform? (1, Insightful)

im_thatoneguy (819432) | about 5 months ago | (#47028515)

I had read early on that most of the code they had stripped out was code supporting Windows and OSX. Is that true or was that just the initial pass? Dumping hundreds of thousands of lines of code is impressive--but if it comes at the cost of multiplatform support it's not surprising.

Re:Multiplatform? (4, Informative)

_merlin (160982) | about 5 months ago | (#47028525)

They removed support for OpenVMS, Pyramid, Tandem classic MacOS, and other stuff like that. I don't know if they removed Windows and OSX support, but it'd be pretty silly if they did.

Re:Multiplatform? (2, Informative)

Anonymous Coward | about 5 months ago | (#47028657)

They did, this is BSD compatible only.

Re:Multiplatform? (5, Informative)

radarjd (931774) | about 5 months ago | (#47028835)

It does indeed appear to be OpenBSD only at present (from http://www.libressl.org/ [libressl.org] ):

Multi OS support will happen once we have

        Flensed, refactored, rewritten, and fixed enough of the code so we have stable baseline that we trust and can be maintained/improved.
        The right Portability team in place.
        A Stable Commitment of Funding to support an increased development and porting effort.

Re:Multiplatform? (3, Interesting)

Too Much Noise (755847) | about 5 months ago | (#47030099)

It does indeed appear to be OpenBSD only at present (from http://www.libressl.org/ [libressl.org] ):

... and not really that multiplatform for future development, either, since it requires (as per the linked slide)

Modern C string capabilities (strl[cat,cpy]) asprintf etc.

None of the quoted functions are standard C and strl* are BSD-only - yay for GNU-BSD strn*/strl* string function wars :(

It's all nice and good practice that they want to use the best tools available to them on OpenBSD, but not caring for what's available on other platforms is not really how one does portability and *will* produce forks, regardless how much the LibreSSL authors want to 'discourage' it.

Re:Multiplatform? (0)

Anonymous Coward | about 5 months ago | (#47030457)

I prefer that the main part of the library is secure, and that you have to add a layer around it to convert from strn*- to strl*-functions. That way, you limit the wrapper to a handful of functions which can be verified independently from the main parts.

Secure code is maintainable.

Re:Multiplatform? (1)

rev0lt (1950662) | about 5 months ago | (#47028937)

From the presentation, its not. Its POSIX-compatible. I'm not sure if Windows provide an adequate entropy source they mention, but I'd assume so. They explicitly removed dead architectures (hence the VC++ reference).

Re:Multiplatform? (2)

ld a,b (1207022) | about 5 months ago | (#47029349)

No it's not, it is stated quite clearly that it is written for OpenBSD. OpenBSD is mostly "POSIX-compatible" but they aren't too shy to extend libc when there isn't a good alternative. The slides and the talk mention strlcpy/cat(unfortunately ignored by C11 but widely adopted everywhere but GLIBC) and reallocarray. Only obliquely referenced is a proper kernel API (P)RNG which is not available in most platforms(using /dev/*.random instead, which has many issues[1]).
However, like OpenSSH, you can expect the LibreSSL portability team to write wrappers to make the best of what there is in your OS. As opposed to the best Win16 could do.

[1] http://insanecoding.blogspot.j... [blogspot.jp]

Re:Multiplatform? (4, Insightful)

serviscope_minor (664417) | about 5 months ago | (#47030363)

using /dev/*.random instead, which has many issues[1]

I must say, I really, really don't understand most of those issues, or more specifically, most of them seem like pointless fussing non issues.

So a large number of them are "what if someone fucks with /dev/random". Since those are protected by permissions that basically translates as "what if someeone gets root and fucks with /dev/random" which to me translates as "what if someone gets root". My general answer to that would be "j00 r pwn3d!". As far as I can see, if someone gets root, you're completely fucked anyway, since the can do something like:

* Simply read the local unencrypted data you're trying to send or are saving
* Open /prov/pid/mem and read your program memory
* Same, but writing it to compromise the RNG
* Do the same to the /dev/kmem to compromise the RNG for builtin crypto
* Load a kernel module
* Screw with /vmlinuz or whatever and reboot
* Replace the binary you believe you are running with one with compromised crypto
* Monkey with LD_PRELOAD to bring in a compromised libcrypto
* Replace the dynamic loader so you're not running the binary you believe you are.

and so on. In other words it seems that once the person has the ability to compromise /dev/random, you're already fucked six ways to sunday.

But I'm not 100% sure I've missed something in my assessment.

Re:Multiplatform? (2, Informative)

Anonymous Coward | about 5 months ago | (#47029137)

I don't know if they removed Windows and OSX support, but it'd be pretty silly if they did.

They removed Windows and Mac OS pre-10 ("Classic"). Mac OS X should be fine, as it's basically Unix/BSD in the user land.

Re:Multiplatform? (0)

Anonymous Coward | about 5 months ago | (#47030095)

Windows is mostly sane at this point and while not optimal (IOCPs will work better than POSIX style non-blocking IO on windows) code that is written to be portable should compile with minimal work. C99 in MSVC is still a frigging disaster though...

Multiplatform? (1)

Anonymous Coward | about 5 months ago | (#47028595)

The portability approach of openssl was wrong. The idea is drop all multi platform support in order to recreated in a proper way.

Re:Multiplatform? (5, Informative)

Anonymous Coward | about 5 months ago | (#47028867)

Partially true but...
A key issue is that the LibreSSL developers have a different approach to portability than OpenSSL has.
- OpenSSL keeps support for very very old platforms, old compilers, old platform and compiler bugs, etc, etc.
- OpenSSL implements this support by sprinkling the code with different code paths, depending on which platform it's being compiled to.

LibreSSL, like OpenSSH, takes a different approach:
- Aim at a modern platform (OpenBSD) and a modern C dialect.
- Support other platforms by providing implementations of whatever functions are missing on those platforms.

Re:Multiplatform? (5, Informative)

thegarbz (1787294) | about 5 months ago | (#47028927)

It's in the slides. They stripped out code supporting Win16 (which won't run on modern Windows anyway), and they dropped support for pre OSX versions of Mac OS.

That said currently they are cleaning up and perfecting the code with one and only one sane target in mind, OpenBSD. The goal is to have a very good very secure fork of OpenSSL running on OpenBSD that is fully POSIX compliant. Once that has been achieved porting should be relatively pain free.

Give them time.

Re:Multiplatform? (1)

thegarbz (1787294) | about 5 months ago | (#47029719)

Replying to self: The slides actually say "mostly POSIX compliant". There's a few things which will need to be ported to make it work on other systems. But in any case dropping support for ancient systems and doing everything yourself assuming the OS provides nothing was a bad idea, maybe not in the 70s but certainly now.

Re:Multiplatform? (1)

gnasher719 (869701) | about 5 months ago | (#47030461)

I had read early on that most of the code they had stripped out was code supporting Windows and OSX. Is that true or was that just the initial pass? Dumping hundreds of thousands of lines of code is impressive--but if it comes at the cost of multiplatform support it's not surprising.

Code for MacOS is thrown out. That's from MacOS 1 released in 1984 to MacOS 9, where Apple ceased all development in 2001. And there is no need for OS X code. They are writing POSIX code, and POSIX runs just fine on MacOS X and iOS.

what's wrong with economic profit? (1)

ThorGod (456163) | about 5 months ago | (#47028531)

There have always been security bugs, but it seems like it's only in the last couple when it's actually cost enough people enough money for people to invest in it.

Re:what's wrong with economic profit? (0)

Anonymous Coward | about 5 months ago | (#47028787)

and ironically not enough money is going where it really needs to

"OpenSSL C dialect" (1)

sunderland56 (621843) | about 5 months ago | (#47028545)

What is this "C dialect" of which you speak? Last I checked, they are using standard compilers for the various platforms.

Writing cross-platform code is tricky, and you need to avoid using some things that appear fine, but work differently on different platforms. That will make your code look a tad peculiar to the regular single-platform programmer; but I'd hardly call it a "dialect".

Re:"OpenSSL C dialect" (1)

TheSunborn (68004) | about 5 months ago | (#47028587)

It's most likely the subset of C, which was supported by most compilers 10 years ago.

Re:"OpenSSL C dialect" (5, Informative)

ConstantineM (965345) | about 5 months ago | (#47028681)

OpenSSL has basically wrote their own version of libc, and all the functions they've introduced differ is some very subtle ways from what appears in libc used by the rest of the world.

Rest assured, OpenBSD is no stranger to portable code. Just take a look at the number of platforms they support -- http://www.openbsd.org/plat.ht... [openbsd.org] .

Re:"OpenSSL C dialect" (5, Informative)

cbhacking (979169) | about 5 months ago | (#47028729)

Yep. In fact, this was actually one of the reasons Heartbleed was so bad. Normally, anybody repeatedly attempting to read 64k chunks of heap space would hit an unallocated page pretty quickly, causing a crash alerting the victims to something being wrong. However, OpenSSL uses their own funky versions of malloc and free which pre-allocate large chunks of memory from the OS (as in, many pages), then implement their own in-process memory management on top of that. They don't free those pages back to the OS either, at least not anywhere near as soon as a sane memory manager would. This doesn't actually mean huge amounts of wasted memory - the library can mostly re-use the memory it has already requested, rather than grabbing more from the OS - but it does mean that just because something is freed doesn't mean it isn't still mapped into that process. The end result is that Heartbleed had no externally-visible evidence for the vast majority of its victims, so people didn't even know there was something to look for until the news broke.

Re:"OpenSSL C dialect" (1)

WaffleMonster (969671) | about 5 months ago | (#47030123)

OpenSSL uses their own funky versions of malloc and free which pre-allocate large chunks of memory from the OS (as in, many pages), then implement their own in-process memory management on top of that. They don't free those pages back to the OS either, at least not anywhere near as soon as a sane memory manager would.

Common for modern allocators to snatch more than immediately requested and hang on to freed memory longer than necessary. This is the basis by which optimized/fragmentation avoidant allocators are able to function.

Re:"OpenSSL C dialect" (2, Insightful)

Anonymous Coward | about 5 months ago | (#47030253)

Common for modern allocators to snatch more than immediately requested and hang on to freed memory longer than necessary. This is the basis by which optimized/fragmentation avoidant allocators are able to function.

Which is why a library like OpenSSL shouldn't be doing the same thing. If the OS already does this, you end up duplicating the functionality. Also, "modern" allocators often try to have the memory space after it not be valid so they cause exceptions on reads beyond the buffer and put a canary at the end of the allocation and warn if it disappears so buffer overflows also get spotted even if they are tiny. OpenSSL failed to implement this.

Re:"OpenSSL C dialect" (0)

WaffleMonster (969671) | about 5 months ago | (#47030307)

Also, "modern" allocators often try to have the memory space after it not be valid so they cause exceptions on reads beyond the buffer

Everything not in process address space is invalid. Oversized "block" allocations meted out internally within process heap is actually contiguous.. this is how binning works.

buffer and put a canary at the end of the allocation and warn if it disappears so buffer overflows also get spotted even if they are tiny

Obviously no help WRT heartbleed.

I'm neither supporting or defending in aggregate merits of OpenSSL memory management scheme.

My objection is limited to these nonsense assertions usage of operating system allocator would have meaningfully mitigated heartbleed vulnerability.

Re:"OpenSSL C dialect" (1)

sunderland56 (621843) | about 5 months ago | (#47029631)

OpenSSL has basically wrote their own version of libc

The language you use and the libraries you use are different concepts.

C - especially in the (most excellent) Whitesmiths compilers done by completely separated the compiler itself from the libraries; the ones they supplied were completely and totally different from what is now called libc, but everything worked. [wikipedia.org]

This model has been (sadly) broken by things like c99 and c++.

Re:"OpenSSL C dialect" (1)

seebs (15766) | about 5 months ago | (#47030381)

Don't blame C99, that was true in C89 as well, and generally for pretty carefully-considered reasons.

Re:"OpenSSL C dialect" (5, Informative)

tlambert (566799) | about 5 months ago | (#47028823)

What is this "C dialect" of which you speak?

The code is largely in a subset of C; there are certain language features that make it intrinsically harder to do static analysis and checking, and which you avoid in order to avoid introducing certain classes of problems into the code. Examples include unspecified array lengths for arrays declared at the ends of structures (a c99 feature first defined with a slightly different syntax by gcc), use of function pointers that don't end up with a const qualifier after initialization, serialization and deserialization of data objects containing pointers, variant length arrays, varradic functions, with or without in-band format strings for interpretation of arguments subsequent to the format strings, etc.. For a given compiler technology, it can also include dynamic scoping, locally scoped variable, and basic block replications which introduce issues when using some code constructs. Typically, there is also a requirement for single entry/single exit, and similar techniques that can use runtime assertions (statically or optionally compiled in) in order to test on larger data sets, although by definition, such things are relative Ad Hoc, and therefore not provable in terms of code coverage.

Similar dialects are defined by standards, such as "MISRA C" (Motor Industry Software Reliability Association), but of course, it costs money to get that standard, and it's not disclosed, so there's no open source compliance checkers, and there's no open source static analysis tools that can check the compliant code based on compliance related assumptions. One of the disclosed requirement is use of sized type everywhere, so fundamental C types are eschewed in favor of them; so you don't use "char", "short", "int", "long", and "long long", you use things like "uint8_t" and "int32_t", and so on. Another is that there are limits to allowed cyclomatic complexity, as determined by static analysis tools.

What it pretty much comes down to is that C by itself lets you get away with things that, if you are allowed to get away with them, makes the outcome of running the program indeterminate. It's still not possible to solve/prevent the halting problem in these dialects, but it's easier to avoid getting into a situation where you have to, if you use the constrained dialect and programming style in your code.

It's really be handy if some day MISRA or something similar became an open standard so that we could raise the level of discourse on these things, particularly as they apply to life support systems, since some people place both privacy, security of financial transactions, and so on, on an equal footing with straight life support.

I am grateful the OpenBSD team decided to do this (2)

LABarr (14341) | about 5 months ago | (#47028549)

These guys are just awesome!!! I am so grateful to the OpenBSD team for taking this on. I'm going to back up being grateful by supporting this team in any manner that I am able to, and also try to find a way to support their efforts. Be it pizza, donating cash, or maybe even help them test their latest patches and provide any feedback I can.

Fake Security Gurus (1, Interesting)

EmperorOfCanada (1332175) | about 5 months ago | (#47028583)

I have met many security "Gurus" over the years who's primary skill is convincing Baby boomer management types that only they can save them. They then start spouting all the usual things like PKI infrastructure. Military grade encryption, Don't roll your own, industry standard, certified, obfuscation is not security, end to end encryption, and so on with little regard to properly implementing this stuff and generally no regard as to the business needs.

They will do an audit that will show that Russians and Chinese are trying to get into their servers hundreds of times a day and that it is only a matter of time before they do.

Often one of the first things these guys will do "after getting the billing spigot turned on" is to start pushing hardware that gives them the largest kickbacks and ideally require a certification they happen to hold and the IT people don't. So if the system uses switch A they will say switch A is vulnerable and prove it by showing the 10,000 security patches that company has been "forced" to release over the years. So they will install switch B. But if the company uses switch B then they will go with switch A.

The greatest part is that they effectively can deliver nothing but a pain in the ass and look like a hero. "I set up your IPTables to block a custom series of threats my company has identified (Boca Raton)" and if they are really good they will cut off access from root from the company's own administrators.

Often these Guru's entire credibility is based upon some nebulous activity in the past. I could see being an OpenSSL guy would be a huge one. I have long suspected that the main guys at OpenSSL have been spending most of their time giving keynote addresses and rounding up the consulting bucks. I am glad now that anyone who was associated with that project now basically has doggy doo doo on their faces and look like halfwits.

I have worked with these types of guys and they even tend to fall into 3 basic body types. There is the ex-cop looking guy, 50, 5 foot 6, white hair, moustache, round head, round body and talks like they are god's gift to security; these types will use obscure systems that nobody knows so nobody can easily call them on their BS; also these people came into their own in the Y2K days. Then there is the quasi hippy, Longer hair (still balding) not enough light, often thinks they are god's gift to women and security and will give endless advice on both. Usually have a Novell certification in some drawer and will defend Novell to this day. Then lastly there is the fat slob security guy. This one usually works with one of the other two. They are a half assed in nearly everything they do and only manage to keep the demons away by being in the server room 24/7. These people have built their credentials 100% by putting down other people and their technologies. The worst part about this last type is that sometimes they are actually quite skilled but do everything in as stupid way. "Oh I had to rewrite the Linux kernal using code from my wristwatch to make for a better time function for the random number generator. The only problem is that I have to manually reset it every 15 minutes.

Re:Fake Security Gurus (-1)

Anonymous Coward | about 5 months ago | (#47028623)

What's your point? Don't have one, shut the fuck up.

Re:Fake Security Gurus (3, Insightful)

tomhath (637240) | about 5 months ago | (#47028687)

The assertion in the OP is that OpenSSL is run for profit by guys who don't necessarily know security. My own experience with security gurus is the same as GP's; they talk in jargon and blow a lot of smoke.

Re:Fake Security Gurus (1)

Anonymous Coward | about 5 months ago | (#47029495)

Perhaps you need better gurus?

I've been in the security-critical business for ~ 10 years now, and I've never tried to sell a scare tactic. The services of the companies I've worked for are not cheap, but for important systems, customers have been willing to pay for our knowledge. Mostly, I've built application specific components using high assurance techniques (peer review, static analysis, dynamic analysis, etc.) and integrated third party components (i.e., Linux) very carefully after removing most of the attack surface area (i.e., disabling unused syscalls & drivers).

Snake oil is everywhere. Do your homework before you buy into someone's "solution" - but don't discount the entire field as quackery.

Re:Fake Security Gurus (3, Interesting)

rev0lt (1950662) | about 5 months ago | (#47029007)

Military grade encryption

I've actually been in the military (more than a decade ago), and had contact with "top of the line" encryption systems. At the time, I was already using for myself OpenBSD and actual strong encryption. "Military Grade" is like the "Bio" sticker in food - a way of charging more for worthless shit.

I could see being an OpenSSL guy would be a huge one

I don't. OpenSSL has always been the disaster waiting to happen. The codebase is messy, no one really understands it, and there is no real criteria when adding stuff. I have no experience with it and I knew it was a big pile of stinking poo (its not like this hasn't been a probem before), so I hardly doubt that saying you're an OpenSSL dev would give anyone any credit.

Usually have a Novell certification in some drawer and will defend Novell to this day.

I'm not Novell certified (nor a security expert), but Novell DID have his awesomeness - at some level, unmatched today.
I do agree with most of what you said, but the problem is two-fold: actual security experts are either matematicians or hardcore developers, and more often than not, cannot communicate with regular people. And no, this is not a feature. Transmiting a concrete idea to a peer without noise is the ultimate developer experience - you need to develop a subset of the language that allows you to carry your own message without being subject to change on the endpoint; And because most of the guys entwined with computers are too tied in the digital all-or-nothing approach, they think its not their fault they cannot operate on an analog world. Which, by itself, is hilarious, because "digital computers" are actually a subset of the computing field.
In short, the problem is the nerd type. Get rid of them, have them behave and communicate like regular people, and all these bs types are out of a job. And for Pete's sake, its not like most of what is CS is hard.

Re:Fake Security Gurus (3, Interesting)

EmperorOfCanada (1332175) | about 5 months ago | (#47029503)

Bang on. I have looked at the OpenSSL code and what I saw was terrible. It was a laundry list of not just bad coding practices but bad coding so bad that people don't even have terms for it. But as for communications I would think that upper management would be better with bad communications than with lies and over billing.

The real problem is that truly great security is invisible. But it is easier to look cool with heroic security. It is like people believing that medicine has to taste bad and have nasty side effects to work.

One of my favorite complaints about fake good security is when IT department implement complicated password regimes. Basically H@v1ng C0mp1icAted passwords is not actually mathematically sound. Long passwords are the real key. So complicateddogpassword is a zillion times better than insisting upon upper/lower/special characters. And then insisting upon changing the password regularly is about the stupidest thing ever. For one this costs a lot of money. The time wasted across a large company can easily be massive and a business decision not a technical one. Also companies that have frequent password changes then have frequent password forgetting, this then opens up a huge social networking hole.

I made a bet with a relative who works for government where they recently implemented monthly password changes that I could socially hack his password with only the contents of his wallet and his last pay stub. First I looked around his desk, under his keyboard, etc, Then I phoned into IT and said that I was him and that I forgot my password. They then walked me through inputting a new one no questions asked. I asked how they knew I was him and they said, because of what number I was phoning from. I then asked but what if I called from home and they said, oh they would have asked maybe my birthdate or something.

Then we walked around the office (it was a Sunday) and found some passwords on post-it notes and written on the bottom of keyboards. BTW his office processes documents that would be financially worthwhile for unscrupulous parties to obtain.

Re:Fake Security Gurus (1)

Anonymous Coward | about 5 months ago | (#47029793)

One of my favorite complaints about fake good security is when IT department implement complicated password regimes. Basically H@v1ng C0mp1icAted passwords is not actually mathematically sound. Long passwords are the real key. So complicateddogpassword is a zillion times better than insisting upon upper/lower/special characters.

Nope. The words in your password are common words, probably on a short list of around 3000 words. Essentially, you have a 3 "character" password where each character is chosen from a set of 3000 possibilities. That yields 3000^3 = 27,000,000,000 possibilities. An random 8-character password that uses only lower-case letters is 26^8 = 208,827,064,576. That's almost an order of magnitude harder to brute-force. So, length isn't everything. To your point, though, the other example you provide isn't much better since most password brute-force algorithms will automatically try common substitutions (@=a, 1=i, etc.) You want to know what really works? Long passwords from people who can't spell. If your password is complecateddogpassword, it'll be much harder to guess, at least until dictionaries of common misspellings become prevalent. For added difficulty, throw in a random punctuation character (comp,lecateddogpassword). Now you're golden.

Re:Fake Security Gurus (0)

Anonymous Coward | about 5 months ago | (#47030039)

Here is a random 8-character password that only uses lowercase letters: dqvkdnbi. Try memorizing that. Now try memorizing fifty more completely random 8-letter sequences for all your other accounts. (Hint, unless you are a savant, this is impossible.)

(Obligatory xkcd [xkcd.com] )

Re:Fake Security Gurus (1)

Anonymous Coward | about 5 months ago | (#47030343)

Here is a random 8-character password that only uses lowercase letters: dqvkdnbi. Try memorizing that. Now try memorizing fifty more completely random 8-letter sequences for all your other accounts. (Hint, unless you are a savant, this is impossible.)

(Obligatory xkcd [xkcd.com] [xkcd.com] )

I usually make up a story/phrase by using words that start with the random letters if I need to remember such a password. It is doable for a few passwords at least.

As for remembering fifty one passwords and which places/usernames they correspond to, heck no. The correct horse wouldn't manage that either.

Its easy to be critical (5, Insightful)

Megan Woods (2920951) | about 5 months ago | (#47028629)

The thing about OpenSSL et al is that everyone who used it had exactly the same opportunity to review the code and make a decision about its use.
What actually happened was that, for the most part, was that it was just used blindly as its the case with most cryptographic systems and API's.
Whatever the motivators for the OpenSSL group were, whatever the decisions that were made or not made, the simple fact of caveat emptor still applies.

Its good that LibreSSL is getting created, and thanks.. Seriously though, stop bashing the OpenSSL project, it is just as much the product of its community as its developers.

Re:Its easy to be critical (1)

Anonymous Coward | about 5 months ago | (#47028793)

If you watch the video, you'll notice Bob starts exactly by stating that: we're all guitly.

Re:Its easy to be critical (2, Informative)

VortexCortex (1117377) | about 5 months ago | (#47030147)

Not me. I'm not guilty. Even responses to requests for help in compiling against OpenSSL were a huge red flag: "If you're not compiling from source, we won't help you." Asking to clarify behavior about things in their API you're linking against was frowned upon, so I go get get the sources, and then I see why they don't want to help anyone -- they don't know how. Told the 3rd party I was contracting for at the time that I would not recommend OpenSSL for future projects, and to use GnuTLS, Mozilla's Network Security Services (NSS) (Apache mod_nss + mod_revocator), or for embedded: PolarSSL or MatrixSSL. When asked why I said the project did not have code quality or standard testing harnesses and that there were many unpatched bugs filed against the system which had gone unfixed for years.

The only people who are guilty are fucking morons. Saying "We're All Guilty" is just blame shifting. I was just building some business logic for a proprietary CMS / Portal and wrote that shit off on my first encounter -- Fuckers actually put OpenSSL on a distro CD for an OS that purports to be security focused. How retarded is that?!

After having more experience with NSS and MatirxSSL and seeing the complexity FUBAR in the entire security theater CA system I've been "rolling my own" security suites despite "common wisdom". That shit doesn't pass as "secure". Honestly I can't fathom why ANY of the OpenSSL codebase is being used in LibreSSL. Implementing these ciphers isn't hard, the math is well understood, the example code is published, and things like side-channel attack mitigation are well documented, if a bit tinfoil hatty (considering the state of end user OS security). The OpenSSL project does deserve bashing. It doesn't even have a proper test harness and unit test with proper code coverage. How can you even tell if both sides of an #ifdef are equivalent, let alone which one is faster? How can a security product be released with ANY untested branches of code?

Given the existing alternatives and reduction in their target platform environments it just seems fucked to me that LibreSSL would use anything other than the header files from OpenSSL. Sorry, anything to do with that cluster fuck is tainted. No amount of "well, you're guilty too" will dissuade me: OpenBSD, you got egg on your face, and you're aiming for more of the same with forking OpenSSL. Oh, wait... None of those SSL libs I mentioned are BSD licensed... Ah, I see. It's fanaticism vs security, round two, fight!

Re:Its easy to be critical (3, Informative)

serviscope_minor (664417) | about 5 months ago | (#47030395)

Oh, wait... None of those SSL libs I mentioned are BSD licensed...

None of those libraries have the same API either.

You are aware that OpenBSD are keeping API compatibility so that the ports tree of all the useful software that people actually want to use keeps running? I mean it's not like people need any of that software or anything.

Re:Its easy to be critical (2, Insightful)

Anonymous Coward | about 5 months ago | (#47028899)

the bashing is legitimate when you consider that they themselves admit so much of their time was devoted to private & for-profit projects that they couldn't give the codebase proper attention and person-power, allowing it to get so bad that experienced coders had a difficult time deciphering it (no pun originally intended) If they were able to admit that themselves, then responsibly they should have immediately slammed the brakes for a proper code review, and told all clients "X amount of your money will now directly support maintaining the codebase, don't like it? tough. this is important.". It doesn't sound like that happened at all, it was sail-till-it-sinks. These projects are too important to be poorly managed - if you can't do it right STOP. Simple fact is, They let it get out of hand. The bug tracker alone shows the community tried to step up and do its part.

Re:Its easy to be critical (1)

Megan Woods (2920951) | about 5 months ago | (#47029053)

Yea ok, I took a look at the code about a decade ago and decided I would not use it unless I was completely stuck with it. I agree with your observations it was clearly mismanaged. Thanks..

Re:Its easy to be critical (2)

rev0lt (1950662) | about 5 months ago | (#47029027)

The thing about OpenSSL et al is that everyone who used it had exactly the same opportunity to review the code and make a decision about its use.

Yeah, including the OpenBSD team. (As the video mentions) And they bitched about it for years, regardless of their "proactive" approach. It took a huge vulnerability to make them take the step. Meanwhile, work is being done, yet Linux Foundation is trying to cash in on it and is probably still deciding the logo sizes for the new joint task-force or whatever to "save" OpenSSL.

eriously though, stop bashing the OpenSSL project, it is just as much the product of its community as its developers.

Well, its not. If there was some vague quality control, it wouldn't be the mess it is today. If it was developed by competent developers, it wouldn't be the mess it is today. And not everyone excels at crypto stuff. The community did their job - submitted patches and bug reports that went unfixed for years. Everyone knew it was a clusterfuck, no one took the extra step - but the community did what it was supposed to do. The OpenSSL team didn't delivered, though.

Re:Its easy to be critical (1)

Megan Woods (2920951) | about 5 months ago | (#47029157)

I guess I was just trying to be a bit more moderate, I agree with the criticism and the project should be written about in textbooks on what not to do but I feel that the ongoing criticism is just shooting fish in a barrel and doesn't contribute much in the way of value.

Re:Its easy to be critical (1)

rev0lt (1950662) | about 5 months ago | (#47029245)

I understand your point. We can all learn something from it, and it is indeed a valuable lesson in software development and product management, but that a child could have tought - if you don't dominate your fears and fight your monsters, sooner or later they will make you suffer.

Re:Its easy to be critical (0)

Anonymous Coward | about 5 months ago | (#47029747)

Don't be moderate. Be correct.

Re:Its easy to be critical (0)

Anonymous Coward | about 5 months ago | (#47029693)

And like the community, it's now being properly ignored, with a seemingly better alternative in active development.

OpenSSL isn't being improved. Bug fixes aren't happening. Security, and the confidence of it in general, is more questionable now, than probably ever before. So why should OpenSSL, despite its prevalence across a multitude of industries, garner my support? It shouldn't! If the maintainers, or anyone else would step up to the plate, and take the reigns of OpenSSL, I might notice. That isn't happening!

What's even more confusing is the Linux Foundations continued funding of OpenSSL. Why would they fund a code package that isn't being properly managed? Especially one that is heavily used, yet being completely ignored by its maintainers? This doesn't add up, and Zemlin hasn't answered this!

Its easy to be critical (1)

jpostel (114922) | about 5 months ago | (#47029707)

Bob Beck has a pretty healthy track record of throwing verbal grenades with regards (but not limited) to open source licenses, security, and other people's code.

That said, looking at published vulnerabilities (CVEdetails.com), OpenSSH and OpenBSD have a tremendous record for fixing (or simply not having) serious security bugs. The total number of vulnerabilities in OpenSSH (application) since 1999 is 61 (11 being DOS) and NONE have known exploits. OpenBSD (an entire OS) has 136 (57 being DOS) since 1999 with 4 known exploits.

By Comparison, OpenSSL (a protocol library) has 87 (46 are DOS) with 5 known exploits.

None of these are egregious compared to other UNIX OS platforms like AIX (316), Solaris (533), and HPUX (278).

I don't think the OpenSSL folks are bad, but they let the product stagnate a bit. Getting some new perspective on it is a good thing.

Re:Its easy to be critical (1)

Bert64 (520050) | about 5 months ago | (#47030379)

This is a very poor comparison to make...

OpenBSD is a relatively minimal OS compared to AIX, Solaris or HPUX... There's bound to be less issues found.
Conversely these systems (with the partial exception of solaris) are entirely closed source and developed behind closed doors, so many more security holes may have been found and fixed but never disclosed.
Similarly finding and fixing security holes is a primary goal of OpenBSD, and they do so in an open and transparent manner.

Re:Its easy to be critical (1)

jhol13 (1087781) | about 5 months ago | (#47030083)

We should not stop bashing OpenSSL, ever (although I do admit it is "product of the community").
Just to remind people that this kind of development is not acceptable, not "even" in FOSS world.

I'm split (0)

Anonymous Coward | about 5 months ago | (#47028791)

I'm split. Clearly there are a huge number of problems with OpenSSL, and it appears that a lot of cleaning has been done, but most of it before the fork to LibreSSL. The Linux Foundation(tm) doesn't want to backstop LibreSSL, but at least its looking 'clean'. OpenSSL is still a steaming heap, suffering massively from bitrot, and no real cleanup in sight. So do I go to clean, non-crappy LibreSSL, or do I stay with the 'Funded', bitrot filled OpenSSL? Time. I will give the BSD boys (beastie boys), a few months. If LibreSSL is clean and running, and OpenSSL hasn't seen a lot of love in the next few months, I'm kicking OpenSSL to the curb. I've got other GPL projects I'm cleaning up, and I don't think the (one) cryptography class I took in university qualifies me to do serious work on OpenSSL.

Re:I'm split (1)

Anonymous Coward | about 5 months ago | (#47029105)

and it appears that a lot of cleaning has been done, but most of it before the fork to LibreSSL

Well alot of work was done before they 'called' it 'LibreSSL'...no reason to see the name change as a slowdown - Sounds like they are now running on pure hate and frustration!

And, as Bob says, the crypto parts are actually pretty well written, its all the other crap which is in majority - So by all means, help out!!

Comic Sans WTF? (1, Redundant)

wiredlogic (135348) | about 5 months ago | (#47029355)

Who the hell writes up slides with Comic Sans as the font.

Re:Comic Sans WTF? (1)

Anonymous Coward | about 5 months ago | (#47029379)

I had the same thought, but check toward the end of the slidedeck -- he explains why.

Re:Comic Sans WTF? (1)

feranick (858651) | about 5 months ago | (#47029715)

The same guy that wrote on libressl website, proudly, this:

This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags
http://www.libressl.org/

Maryland? (0)

Anonymous Coward | about 5 months ago | (#47029423)

I'm curious what the relevance of stating where they're incorporated is.

Re:Maryland? (1)

ConstantineM (965345) | about 5 months ago | (#47029507)

What's FIPS?

Who requires FIPS?

Think geography. (-:

Re:Maryland? (1)

rubycodez (864176) | about 5 months ago | (#47029549)

two states donated land to make something, the other state was Virginia.

The Linux Foundation is not actually that evil (1)

badger.foo (447981) | about 5 months ago | (#47029537)

Unfortunately the summary gets several important facts wrong, including the status of support from the linux fooundation -- last status is ongoing discussions, not total ignore as the post summary says. And you can see what Bob actually said in the video jason Tubnor uploaded to youtube The real Bob Beck on OpenSSL talk [youtube.com]

Re:The Linux Foundation is not actually that evil (0)

Anonymous Coward | about 5 months ago | (#47029675)

The audio on the talk is mixed too low.

Re:The Linux Foundation is not actually that evil (5, Informative)

Anonymous Coward | about 5 months ago | (#47029767)

Yes, I am extremely annoyed at the misquoting of my presentation, and my slides, by the person who wrote this summary for Slashdot. As I said in the talk, and in the slides, the Linux Foundation has not *yet* committed to support us. Discussions with them are ongoing. Saying that they have somehow "Ignored" us is both slanderous and wrong, and shows exactly what is wrong with Slashdot when they let garbage like this go up. If you have some sort of beef with the Linux Foundation, please take it up on your own time, and use your own name. Don't use mine, or LibreSSL's.

But hey, it's slashdot, everybody expects you to be a dumbass...

-Bob Beck

Portability (0)

Anonymous Coward | about 5 months ago | (#47029907)

LibreSSL needs to be portable to wide range of OS's if they want to replace OpenSSL as the "industry standard SSL/TLS implementation". Portable doesn't just mean BSD and Linux [youtube.com] .

I hope the people working on LibreSSL appreciate what it takes to achieve broad OS and toolchain portability. OpenSSH is not a good model. OpenSSH is only portable to other POSIX-ish systems, and LibreSSL needs broader reach.

Re:Portability (1)

Bert64 (520050) | about 5 months ago | (#47030391)

BSD and Linux are the obvious places to start, as you already cover the vast majority of embedded devices and a significant proportion of server systems.
The only other OS that's really relevant these days is Windows, and that already has its own native SSL implementation.

Please ensure you are actually quoting directly (5, Informative)

WayCool (107037) | about 5 months ago | (#47030013)

I was in this talk, actually the person behind this camera and at no time did Bob state the following above:

Linux Foundation is turning a blind eye to LibreSSL

This is totally incorrect and should be removed. The slide doesn't even state that. Slashdot editorial committee needs to review their posts a lot closer prior to posting in a public space.

So, what about GnuTLS? (2)

VGPowerlord (621254) | about 5 months ago | (#47030031)

I think people forget that GNU has their own communications library for secure sockets... [url=http://www.gnutls.org/]GnuTLS[/url].

I know why OpenBSD won't use it (because it's LGPL), but why won't anyone else?

Re:So, what about GnuTLS? (3, Interesting)

RR (64484) | about 5 months ago | (#47030153)

You mean this GnuTLS? [arstechnica.com] (It had a "goto cleanup" bug similar to Apple's "goto fail" bug.) It isn't API compatible with OpenSSL, and OpenSSL came first. OpenSSL has first mover advantage, and more people are paranoid about GPL, even if it's LGPL.

The consensus among security experts seems to be that TLS (the protocol itself) sucks, OpenSSL sucks, GnuTLS sucks, NSS sucks, and TLS has horrible compatibility problems between implementations. They aren't giving us a lot of options, here.

So, I find it fascinating that OpenBSD is taking OpenSSL (which sucks) and trying to make LibreSSL into something that doesn't suck. I wish them the best of luck and funding.

Re:So, what about GnuTLS? (2)

WaffleMonster (969671) | about 5 months ago | (#47030261)

The consensus among security experts seems to be that TLS (the protocol itself) sucks, OpenSSL sucks, GnuTLS sucks, NSS sucks, and TLS has horrible compatibility problems between implementations.

Blah blah blah ... sucks ... ... blah is shit ... blah is horrible... ad nauseam.

Too easy to invoke. Concurrently too difficult in typical context free usage to falsify... saying "x sucks" ... just ... sucks...

On deleting "cross platform" "cruft" (1)

WaffleMonster (969671) | about 5 months ago | (#47030091)

Has anyone looked at source code for any staple unix program or library?

These things are universally teeming in preprocessor defs for every platform you could imagine. Autotools enshrines defacto standard operating procedures with entire header files, replacement libraries, #ifdef's and funky meta programs for virtually every function and historical errata imaginable.

Existence of these things in and of themselves is not a problem if managed properly. When I see commit comments full of snark and rage while concurrently support for leading platforms and necessary features are dropped this is unfortunate when I can't use it... even if LibreSSL was 100x better in every way... it won't even compile so no point.

Bravo, just like weeding a long-neglected garden (0)

Anonymous Coward | about 5 months ago | (#47030169)

It's tedious and inglorious work, carefully removing all the weeds, deadfall and garbage blown in by years of wind; and in pulling out weeds one might also pluck a few desired plants out by mistake. But the only way to remediate a neglected garden is to clean it up enough to see what's there that is really worth preserving, turn the soil underneath, and then give it some TLC to grow and thrive. One can add back those few plants that got mistakenly pulled in the cleanup if they're really that important...

I was stunned reading the slides at what cruft was in there -- really, VMS? Win16? I think the presenter was right -- somebody was concerned about job security with the FIPS crowd and wanted to keep this crap in to scare everyone else off. And the openSSL Foundation is incorporated in Maryland? As in Ft. Meade Maryland, NSA home turf? If one had a tinfoil hat on, one would think the NSA *wanted* openSSL to be as scary as possible so no one would ever look at it.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?