Announcement

Collapse
No announcement yet.

OpenSSL 3.0 Officially Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by ssokolow View Post

    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.
    One significant difference between dual licensing and effectively similar licensing exception clauses is that dual licensing can lead to license specific forks. Some projects want to avoid that.

    Comment


    • #12
      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.
      From what I understand, it is compatible because it lacks the "litigate against me and your patent grants are revoked" part. It's fully compatible with section 7 of GPLv2.

      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.

      Comment


      • #13
        Originally posted by uid313 View Post
        But is it secure?
        Totally secure until the next major flaw, that isn't present in LibreSSL, is found.

        Comment


        • #14
          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.

          Comment


          • #15
            Originally posted by linner View Post
            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.
            The LibreSSL fork was actually planned long before heartbleed through growing annoyances. It was the custom memory allocator that was also the final straw, not the commonly cited heartbleed.

            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.

            Comment


            • #16
              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.
              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.

              Comment


              • #17
                What's wrong with GnuTLS as an alternative?

                Comment


                • #18
                  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.
                  They do backport a few security related things (and also the original OpenSSL shares many of their improvements too). They seem a little reserved when it comes to brand new features though again some do get cleaned up and integrated but not all.

                  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


                  • #19
                    Originally posted by S.Pam View Post
                    What's wrong with GnuTLS as an alternative?
                    Probably the copyleft license, depending on who you ask.

                    Comment


                    • #20
                      Originally posted by kpedersen View Post
                      For performance, I highly recommend BearSSL (https://bearssl.org/) or some of the embedded alternatives.
                      Is this related in any way to BearSSH?

                      Comment

                      Working...
                      X