1. 38

  2. 19

    I believe pretty much everything that LibreSSL originally was (consistent codingstyle, cleanup of obsolete/dead code etc.) has happened in OpenSSL these days. It’s more that there’s some myth around LibreSSL from these early days (where the people behind it raised back then valid criticism about OpenSSL) than any real value.

    This prompted me to check if OpenSSL still had support code for big endian x86_64. They do.

    #   elif defined(B_ENDIAN)
            * Most will argue that x86_64 is always little-endian. Well, yes, but
            * then we have stratus.com who has modified gcc to "emulate"
            * big-endian on x86. Is there evidence that they [or somebody else]
            * won't do same for x86_64? Naturally no. And this line is waiting
            * ready for that brave soul:-)
    1. 3

      That comment is begging for someone to scream YAGNI as a response.

      1. 1


        (You might need it someday…)

    2. 15

      One of the main reasons they list as hindrance is that Gentoo doesn’t allow OpenSSL and LibreSSL to coexist. What the article doesn’t mention that there is another distro that offers LibreSSL and that’s NixOS, where those two happily co-exist.

      1. 13

        It’s the default on macOS:

        qbit@plq[0]:~% openssl version
        LibreSSL 2.8.3
        1. 13

          Incidentally, I was just reading through the Void issue for this this morning: [RFC] Switching back to OpenSSL

          This project was created only a couple of weeks after the disclosure of Heartbleed, which seems rather too early to conclude that the problems with OpenSSL itself could not be addressed without a fork. OpenSSL turned out not to be as unfixable as it seemed, and OpenBSD is saddled with the cost of carrying its own fork rather than benefiting from the rejuvenated OpenSSL effort.

          I think the Heartbleed was just the final straw after years of frustration; see e.g. the old “OpenSSL is written by monkeys” rant by a (I believe now-former) OpenBSD dev.

          I also don’t think the OpenBSD people see it as “being saddled with” either; OpenBSD reinvents a lot of wheels, which is kind of part of its appeal. Whether or not it will work well on Linux isn’t really a big concern: the main concern is whether or not it will work well on OpenBSD.

          1. 4

            It is sad, but it does seem the writing is on the wall for LibreSSL providing libcrypto and libssl on Linux.

            Hopefully though more people will have libtls available and just rely on that.

          2. 9

            I heard the news last week, and while I was using LibreSSL, I was really using it for libtls. I then saw https://git.causal.agency/libretls/ which is libtls for OpenSSL. I made the switch, and the software just worked like it always has. I think some people from the Gentoo project are behind this.

            For me, libtls is what most people should be using, not OpenSSL or LibreSSL.

            1. 4

              I think some people from the Gentoo project are behind this.

              Where did you hear that? LibreTLS was written by June of ascii.town to make it easier to use pounce and catgirl on systems without libressl (also motivated by some problems with libressl’s TLS 1.3 implementation related to the status_request extension, which have since been fixed).

              For me, libtls is what most people should be using, not OpenSSL or LibreSSL.

              Agreed. It is a much nicer API to use, and at this point has three implementations I’m aware of (the third being my own libtls-bearssl).

              1. 2

                I recall reading the Gentoo mailing list archive about them dropping LibreSSL, and I recall them keeping libretls. I might have mistaken that as a Gentoo initiative.

              2. 3

                LibreSSL-portable also can be built to have a self-contained libtls. When I write code touching those libraries, I too wish to focus on libtls instead of caring about the underlying SSL lib versions.

              3. 7

                It is sad that the world chose to respond to openssl’s incompetence by rewarding openssl while ignoring libressl.

                1. 4

                  Perhaps. But OpenSSL was fixed by loads of companies that have zero interest in OpenBSD.

                  1. 6

                    That’s likely the same companies that use OpenSSH regardless of their complete lack of interest in OpenBSD.

                    And do not contribute a cent to that, either.

                    1. 6

                      I don’t disagree with the goals of LibreSSL, but they really didn’t go about it in a way that encouraged external contributors. Its canonical home is a CVS repository (yet, even in 2021) and it has a read-only GitHub mirror. If you want to submit patches, they are submitted to OpenBSD’s CVS repository.

                      They didn’t start by trying to build a consensus around what needed doing, they just announced that they were forking the project and immediately reformatting all of the code into OpenBSD’s style, so it was impossible to diff their changes against OpenSSL properly. Now, I agree that applying a uniform style is a good idea, but reformatting a large existing codebase is a guaranteed way of preventing any reunification in the future. At least working with OpenSSL to upstream a clang-format file so that they could do their refactoring after the first set of cosmetic changes would have enabled the two to coexist, but the OpenBSD folks decided that upstream OpenSSL needed to die. The only way you can really do that is to build consensus across the majority of OpenSSL users and contributors that the new project is the continuation. They never tried to do that.

                      1. 4

                        I don’t think LibreSSL was ever conceived as a general replacement for OpenSSL. It was conceived as a replacement for OpenSSL for OpenBSD.

                        I think other people felt that the project was a perfect fit for them them but didn’t take the OpenBSD-specific nature of the project into account.

                      2. 7

                        The main developer of the portable SSH distribution has worked for Google since 2006. Google also contributes to the OpenBSD foundation.

                        OpenSSH started in 1999, after the original SSH project began locking down its license to commercialize. OpenBSD folks forked and significantly enhanced an older version for the initial OpenSSH release. There was every reason to build on OpenSSH.

                        But OpenSSL remained open, so there was little reason to adopt LibreSSL. Google had already maintained their own patches on top of OpenSSL for some time, contributing upstream fixes along the way. It was natural to formalize that project as BoringSSL rather than throwing out all prior work and backing LibreSSL instead.

                  2. 3

                    As someone who tried to use LibreSSL in certain “we absolutely require OpenSSL” scenarios, they have diverged so much that it’s become a nightmare to simply switch between them.

                    I was really upbeat and happy with it for a few years, but now I am not even sure it’s feasible anymore, at least if you are not some sort of distro upstream with real resources and not a few people not well-versed in crypto…

                    1. 2

                      While porting software I have come across some projects that ship with their own LibreSSL in one way on another. Funnily enough this can sometimes make it annoying to port to OpenBSD. Mostly because of how the build works though. I think the goal might have been to use what macOS uses.

                      On a somewhat off-topic, but mildly related note. To my big surprise I have come across Linux only cloud source games that requires sndio. I don’t know what that is about though.

                      1. 2

                        While the OpenBSD people are more paranoid than most, they don’t go much beyond enforcing secure coding guidelines. I would much rather see time and effort put into supporting high-assurance crypto libraries leveraging formal verification.