(I had blissfully acclimatised to how much easier it is to read a revision log when you actually have, you know, a revision log, as opposed to trying to piece history together out of file-based logs. Trying to get an idea of what the OpenBSDs are up to was a painful reminder. In CVS it looks like a lot fewer changes than you realise once you look at a revision log. They really are applying that plasma torch fast and thick.)
Loving the colourful commit messages. “Toss a unifdef -U OPENSSL_SYS_WINDOWS bomb into crypto/bio.” “Go home, VMS, you’re drunk”. “Q: How would you like your lies, sir? A: Rare.” Etc.
Products derived from this software may not be called “OpenSSL” nor may “OpenSSL” appear in their names without prior written permission of the OpenSSL Project.
what’s a “backend engine”? is that just “engine”? if so, i suspect they will keep the engine interface as it’s used by openssh (eg for hardware modules) (if i’m remembering right).
(i hope this works; i hope the openssl crew can then find some way to switch to this (i think that would be hard even without external pressure from companies that have paid for code that is being stripped, but still, i hope it can happen)),
May I propose some more things? Go through the algorithms and identify ones that are basically unused. An example is DSA.
Also, it may be debatable to remove algorithms that are generally considered too weak to be used. RC4 comes to mind, which will probably see a deprecation RFC soon.
It sounds like they’re not just completely abandoning compatibility with upstream; they’re incinerating compatibility with upstream with a plasma torch.
Because they’re smart people and probably learned their lesson after that Frankenstein monster of an Apache they had to solely maintain for so many years before dumping?
wow, you weren’t kidding about the “massive”! very exciting stuff, gives me much the same sort of thrill that reading books like “where wizards stay up late” does.
HA that’s pretty good. I was trying to give OpenSSL a slight touch of respect with that adjective. Everyone’s flat-out trashing it so no need for me to pile on there.
I still think instead of disparaging OpenSSL post-mortem, our time would be better spent turning our eyes to the next one.
Changes so far to OpenSSL 1.0.1g since the 11th include:
Commits are happening pretty fast, but the API is not being changed.
FYI, I’ve posted a git repo of the changes OpenBSD made to https://github.com/jmhodges/libssl
Easier to read than digging through cvs per-file histories. It’s a one-time dump for now.
You can get commit logs for the BSDs at FreshBSD:
http://freshbsd.org/search?project=openbsd&q=file.name:libssl
(I had blissfully acclimatised to how much easier it is to read a revision log when you actually have, you know, a revision log, as opposed to trying to piece history together out of file-based logs. Trying to get an idea of what the OpenBSDs are up to was a painful reminder. In CVS it looks like a lot fewer changes than you realise once you look at a revision log. They really are applying that plasma torch fast and thick.)
Loving the colourful commit messages. “Toss a
unifdef -U OPENSSL_SYS_WINDOWSbomb into crypto/bio.” “Go home, VMS, you’re drunk”. “Q: How would you like your lies, sir? A: Rare.” Etc.commitid support should help there, but I haven’t been able to turn it on for us yet.
I hope the new version is called OpenOpenSSL.
Joking aside, I’d probably vote for OpenTLS.
Can’t.
Haha I thought of that… But I think I like OpenTLS best.
what’s a “backend engine”? is that just “engine”? if so, i suspect they will keep the engine interface as it’s used by openssh (eg for hardware modules) (if i’m remembering right).
(i hope this works; i hope the openssl crew can then find some way to switch to this (i think that would be hard even without external pressure from companies that have paid for code that is being stripped, but still, i hope it can happen)),
All of the engines that interfaced with hardware crypto accelerators. The interface still exists AFAIK, but all of the individual engines are gone.
wow. all of them indeed. strangely, it looks like the pkcs11 engine was always third party - https://www.opensc-project.org/opensc/wiki/engine_pkcs11
I think stripping down openssl is a good idea.
May I propose some more things? Go through the algorithms and identify ones that are basically unused. An example is DSA. Also, it may be debatable to remove algorithms that are generally considered too weak to be used. RC4 comes to mind, which will probably see a deprecation RFC soon.
I think you will see the OpenBSD developers doing this - they are aggressively attacking the code at the moment.
Not supporting things like that may prevent adoption for people who are stuck using them for backwards compatibility with older systems.
Arguably if they don’t have the resources to fix those systems they may not have the resources to switch to this, once it’s usable, anyway. shrug
Will this make merges of upstream changes significantly more difficult?
It sounds like they’re not just completely abandoning compatibility with upstream; they’re incinerating compatibility with upstream with a plasma torch.
Why do you think they have any intention of merging?
Because they’re smart people and probably learned their lesson after that Frankenstein monster of an Apache they had to solely maintain for so many years before dumping?
I think they will follow the same policy as for OpenSSH when it comes to providing code to a project that is of no use to them at all.
It was a fine daemon, really.
Merging of upstream changes stopped because they switched to a non-free license.
wow, you weren’t kidding about the “massive”! very exciting stuff, gives me much the same sort of thrill that reading books like “where wizards stay up late” does.
Congrats, @jcs. I think you’re the first member of the 100 point story club.
“We need a well-designed API, as simple as possible to make it hard for people to use it incorrectly. And we need multiple independent quality implementations of that API, so that if one turns out to be crap, people can switch to a better one in a matter of hours.” - PHK
Go OpenBSD GO!!
After OpenSSL which other venerable yet dusty codebases deserve the fork/cleanup treatment?
venerable or vulnerable? :)
Same thing for me. ;]
HA that’s pretty good. I was trying to give OpenSSL a slight touch of respect with that adjective. Everyone’s flat-out trashing it so no need for me to pile on there.
I still think instead of disparaging OpenSSL post-mortem, our time would be better spent turning our eyes to the next one.
yep
Does anyone know how portable Apple’s Secure Transport is to other *nix?
Not sure, but very little software uses it. Patching the universe of software that uses OpenSSL would be even more work.
OpenOpenSSL.org is it?