Talk:LibreSSL

Latest comment: 2 years ago by A4035 in topic macOS adoption

Merge with OpenSSL?

edit

There is no working code yet and the userbase is practically zero, so, just as MinGW-w64 and libjpeg-turbo do not have their own articles (and they each have quite a respectable userbase), I think this article should be merged into OpenSSL. X-Fi6 (talk) 01:56, 24 April 2014 (UTC)Reply

  • Oppose Even if it never ships, it has gotten enough coverage in the news to be separately notable. PaleAqua (talk) 02:03, 24 April 2014 (UTC)Reply
  • Oppose: We can at least keep the article for now and watch how the whole story unwinds. — Dsimic (talk | contribs) 02:36, 24 April 2014 (UTC)Reply
  • Oppose. In my opinion, this article was created too soon. But it already exists, there already is some coverage to establish notability and more is to come. I am quite confident, that the userbase won't be "practically zero" very soon, as it normally happens to OpenBSD software. The precedent to note is OpenSSH. — Dmitrij D. Czarkoff (talktrack) 09:14, 24 April 2014 (UTC)Reply
  • Oppose. As PaleAqua says, even if it never ships, it's still an independently notable software project that has split off entirely from OpenSSL and represents a major upheaval in the open source crypto world, with plenty of press coverage in WP:RS to prove it. And as Dimitri says above, more is most certainly on its way: development is highly active, very public, and the code is getting smaller and further and further from the OpenSSL codebase day on day. -- The Anome (talk) 09:32, 24 April 2014 (UTC)Reply
  • Oppose for now - although I concur this may have been created too soon, OpenBSD are quite committed to the project and pushing it forward; it doesn't require much crystal ball gazing to say that a remerge would probably just need reseparating later. If it fails, we can remerge at leisure - David Gerard (talk) 11:17, 24 April 2014 (UTC)Reply
  • The primary argument against a merge is simple: right at the moment, it's this aspect of the "parent" subject which is getting the most attention, and if we merged back then this section would quickly overwhelm the target. IMO we're better keeping it split from now and periodically updating the OpenSSL article with the important bits, per WP:SUMMARY. If this fork eventually goes nowhere, we can then safely delete the child article entirely, knowing that we've still weighted it appropriately in the remaining page. Chris Cunningham (user:thumperward) (talk) 15:32, 24 April 2014 (UTC)Reply

Rename from LibreSSL to LibReSSL

edit

I notice that the page was renamed LibReSSL. I see that the latest posting by Theo uses that form of camel casing, as does the post in OpenSSL Valhalla Rampage. Doesn't look like other sources have yet though from quickly scanning news articles about the BoringSSL fork. Is there an official announcement about the name change? If so we might want to mention it explicitly in the article. PaleAqua (talk) 06:14, 22 June 2014 (UTC)Reply

After noticing the change from "LibreSSL" to "LibReSSL" on www.libressl.org (snapshot on May 17), I looked for official announcements or news article, however, I could not find at all. I don't think this change on official website is a mistake, but there is any other evidence. --Claw of Slime (talk) 07:56, 22 June 2014 (UTC)Reply
Article titles should follow sources, not official names. Don't think it would be wise to move the article back at this point, but I would like to see some discussion after a grace period of month or so. FWIW someone with Comic Sans available should update the logo image. — Dmitrij D. Czarkoff (talktrack) 08:02, 22 June 2014 (UTC)Reply

Rename again from LibReSSL to LibreSSL

edit

I noticed today with the release of the first portable version (2.0.0) of LibreSSL that they use LibreSSL under their new logo and everywhere on their homepage.[1] Tamer (talk) 22:19, 11 July 2014 (UTC)Reply

I almost think they are having fun with it. Wonder when it will be renamed OpenTLS or something else next. :) We probably should just leave it at LibreSSL for now even if they switch back to LibReSSL or the like since it will take a bit for third party sources to change and I wouldn't be surprised if many are using the lowercase "r" from before the last change anyways. PaleAqua (talk) 00:08, 12 July 2014 (UTC)Reply
Just keep current title until everything settles. We shouldn't move this article back and forth every time project's website is updated. — Dmitrij D. Czarkoff (talktrack) 00:40, 12 July 2014 (UTC)Reply

References

  1. ^ "LibreSSL". 2014-07-11. Retrieved 2014-07-11.

Counting vulnerabilities

edit

I've tried to be unpartial in how to count vulnerabilities in both LibreSSL and OpenSSL, but it seems people are reverting it because they don't like the numbers. I've counted something as affected if a released version was affected by it at some point. That means that if they make a release during an embargo to remove the code that they were affected. It also means that if it was fixed a year ago but the security status of it was unknown at the time it's counted. Kurt Roeckx (talk) 14:21, 7 June 2016 (UTC)Reply

Peacock tone

edit

Much of the article reads like a pissing match - as best that crypto nerds can do so - to show that LibreSSL is superior to OpenSSL. Does the article really need a section and iteration of each and every bug and release OpenSSL has announced over the last two and a half years since LibreSSL went live? This is supposed to be an encylopaedic article. What I see from the majority of section 3 is that LibreSSL has been 'victim' to its share of vulnerabilities, even with the vaunted rewrite that would ostensibly minimize/mitigate it. Little of this is informative to the average reader - such excruciating details are better found in direct sources rather than in a place where naughty kids can alter the information as desired, where it can remain unchallenged for random intervals.

I've no axe to grind here - OpenSSL is part of the default installation for my systems, and if LibreSSL were to be chosen by the maintainers to replace it, I'd just accept the maintainer's choices. The tone just strikes me as both peacocky and argumentative. My perception could absolutely be wrong - I just wonder if there are other editors who share that perception, and if so, how to address it in the article. Anastrophe (talk) 19:07, 26 January 2017 (UTC)Reply

Agree that this article has a problem with WP:RAWDATA. A lot of the article is a collection of version histories and vulnerability histories. It would probably be better to have much of that information be linked as a reference and find sources that can be used to have prose talking about reception, differences, development relation to OpenSSL, BoringSSL etc. I see a lot of sources from the time LibreSSL was first forked when scanning news online but fewer more recent sources except those talking about version releases or operating system distributions that have started using LibreSSL. PaleAqua (talk) 16:54, 27 January 2017 (UTC)Reply
I have removed the "Security" section, which includeded the synthesized and unreferenced vulnerabilit counts; and the dated changelist summaries. It seems like a lot more can be done; many references are checkin summaries archived at the project's mailing list, and this seems like completely imappropriate content for Wikipedia. -- Mikeblas (talk) 08:33, 27 September 2018 (UTC)Reply

macOS adoption

edit

I note a few things: 1) macOS is the only entry under "Adoption" that lists any sort of "since <version>"; 2) older versions of macOS have LibreSSL installed as the default OpenSSL, although this may be due to security updates and not necessarily true for the original release; 3) the version number cited for macOS "needs citation"; So, what's the proper next step? Should the version number be dropped since it's misleading, without citation, potentially wrong, and apparently not necessary for any of the other systems listed? Should it be updated to be correct? What's the definition of "correct"? If a macOS release has LibreSSL currently, with all security updates applied, should the oldest macOS be listed? Finally, regarding a citation, is there any source out there which perhaps has the answer so we can just settle the question? Sorry for all the questions. I'm tempted to make a correction and leave the "needs citation" mark, but I don't know what constitutes "original research" BrianWilloughby (talk) 00:02, 7 June 2020 (UTC)Reply

I looked at the issue a bit. It's kinda confusing. https://support.apple.com/en-us/HT206167 talks about a security issue in LibreSSL as a component of OpenSSH – and affecting 10.9 which predates the first release of LibreSSL. https://opensource.apple.com/ does not list LibreSSL at all, at least not as a separate component. So as I see it, at least initially only OpenSSH used LibreSSL code and that has been rolled out to the public mid-cycle in an update no later than 2016. –KAMiKAZOW (talk) 18:53, 8 June 2020 (UTC)Reply
MacOS is listed again without source in "LibreSSL is the default provider of TLS for". I think there should be source confirming 1) LibreSSL is included in macOS 2) macOS APIs and/or frameworks utilize LibreSSL A4035 (talk) 11:51, 19 June 2022 (UTC)Reply