Originally posted by ssokolow
View Post
Announcement
Collapse
No announcement yet.
OpenSSL 3.0 Officially Released
Collapse
X
-
Originally posted by ssokolow View Post
I don't think a BSD+Patent license that's compatible with the GPLv2 is possible because the patent-related requirements, being not present in the GPLv2, would count as additional restrictions and thus inherently GPLv2-incompatible.
The LLVM exception is sort of a grey area since it's effectively saying "if courts deem that the patent rules are incompatible with the GPLv2, then you may ignore them when redistributing this code as part of a larger GPLv2 work"... so I have trouble seeing how it's significantly different from just releasing something under "Apache-2.0 OR GPL-2.0" terms.
Hell, the Rust ecosystem uses "Apache-2.0 OR MIT" because, as long as you care about getting your changes upstreamed, it has the same effect, patent-wise.
I'm not a fan of exception notices. As you pointed out, it effectively turns established licenses into dual licenses or new licenses entirely. I think the Rust ecosystem not pushing for MPL-2.0 was a missed opportunity, but if they still really wanted a permissive license, a BSD-3+Patent license would've been perfect. It's a shame they're stuck in dual-licensing hell now.
- Likes 2
Comment
-
Seems to work for me at least. One thing I hate about OpenSSL is how intertwined everything is. Even if I "no-xxxx" and disable every single feature, static linking to the library produces huge binaries. Sometimes I just need a tiny part of the library and for whatever reason the linker can't strip out the fluff. I'm using -fdata-sections -ffunction-sections -Wl,--gc-sections too.
I think the LibreSSL fork was done too hastily. OpenSSL got a LOT of attention after those flaws were exposed and it's very actively maintained these days.
- Likes 2
Comment
-
Originally posted by linner View PostI think the LibreSSL fork was done too hastily. OpenSSL got a LOT of attention after those flaws were exposed and it's very actively maintained these days.
https://www.zdnet.com/article/heartb...eate-libressl/
I must admit, reading through the two codebases it is much clearer what LibreSSL is now doing. They also stripped out a load of niche features and cruft (which usually I am against for backwards compatibility) but for security this is a good idea.Last edited by kpedersen; 07 September 2021, 03:48 PM.
- Likes 8
Comment
-
Originally posted by kpedersen View Post
The LibreSSL fork was actually planned long before heartbleed through growing annoyances
...
I must admit, reading through the two codebases it is much clearer what LibreSSL is now doing. They also stripped out a load of niche features and cruft (which usually I am against for backwards compatibility) but for security this is a good idea.
Comment
-
Originally posted by linner View Post
Interesting. Also LibreSSL seems to be missing features from modern OpenSSL like BLAKE, SHA3, other stuff? I wonder how the performance compares being based on such an old code base.
As for performance, they don't tend to focus on that so much. OpenBSD in general runs with a number of security related overheads (such as salting / cleaning memory (thus the annoyance at the custom memory allocator!), SMT, locking, etc) so the overhead of their LibreSSL is probably negligible in comparison.
For performance, I highly recommend BearSSL (https://bearssl.org/) or some of the embedded alternatives.
Comment
Comment