HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
libressl
openbsd
C2014–2021
libressl / openbsd

openbsd

Source code pulled from OpenBSD for LibreSSL - this includes most of the library and supporting code. The place to contribute to this code is via the OpenBSD CVS tree. Please mail patches to tech@openbsd.org, instead of submitting pull requests, since this tree is often rebased.

Systems & InfrastructureLibraries & SDKs
Explore on GitHubRead Hacker News discussions
13Distinct people
13Mentions
0Explicit recommenders
246GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Source code pulled from OpenBSD for LibreSSL - this includes most of the library and supporting code. The place to contribute to this code is via the OpenBSD CVS tree. Please mail patches to tech@openbsd.org, instead of submitting pull requests, since this tree is often rebased.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year13 dated mentions

Observed mentions: 2014-07-16 06:13:23 UTC to 2021-03-25 16:16:56 UTC.

0123452014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC303
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC505
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101

What Hacker News says

13 sources
TimWolla·Mar 25, 2021
This is the fix for the LibreSSL issue [1]: https://github.com/libressl-portable/openbsd/commit/5f00b800... This is the fix for the OpenSSL issue: https://github.com/openssl/openssl/commit/02b1636fe3db274497... They don't appear to be related to me. One is a UAF, the other is a NULL pointer dereference. [1] The LibreSSL issue was found by HAProxy's continuous integration pipeline: https://github.com/haproxy/haproxy/issues/1115. Disclosure: I'm a community contributor of HAProxy, I help maintain the issue tracker and I took part in debugging the issue.
In OpenSSL Security Advisory
masklinn·Sep 17, 2019
> inexplicably, instead of actually fixing /dev/(u)random, the Linux engineers decide to add a new getrandom() syscall which implements the correct behaviour of only blocking if the PRNG hasn't been seeded. FWIW the OpenBSD folks first implemented getentropy() and recommended that Linux do the same[0], because devices causes various issues (e.g. chrooting, attacker-controlled FD exhaustion, …) having a reliable syscall is extremely valuable. Sadly the Linux folks way over-engineered the thing with all kinds of tuning knobs so that you can get any preexisting behaviour you want: by default getrandom will read from the "urandom source" but block until the entropy pool has been initialised once. However, you can also: * GRND_RANDOM to have it read from the "random source" and block if "no random bytes are available" * GRND_NONBLOCK to have i
Read the rest
t never block on lack of entropy, whether from the entropy pool not being initialised at all (!GRND_RANDOM) or because "there are no random bytes" (GRND_RANDOM), in which case it can also fail (getentropy should only fail if you give it an invalid buffer address or you request more than 256 bytes) [0] https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00... also through the libressl project complaining about the lack of safe way to get good random data[1] [1] https://github.com/libressl-portable/openbsd/blob/4e9048830a...
In Linux Kernel 5.3
xoa·Oct 12, 2016
I too would definitely be interested if there's any sort of milestone planned for X25519. There are a couple of open enhancement requests on it in both openbsd and portable [1,2] dating to before ratification of RFC 7748 (or Chrome 50), but no assignees yet. I also don't see any discussion on the libressl public mailing list archives at marc.info, though I'm not sure if that's complete. It seems like it may become an ever bigger breaking issue for a lot of folks as support becomes more widespread following standardization, inclusion in OpenSSL 1.1.0, and increasing major browser/OS support. 1. https://github.com/libressl-portable/portable/issues/114 2. https://github.com/libressl-portable/openbsd/issues/58
In Alpine Edge has switched to libressl
montyedwards·Oct 12, 2016
I'm currently evaluating LibreSSL for use in data protection software I licensed to a large company. The optional libtls API bundled with LibreSSL is a really simple wrapper API that is secure by default. And it was a breeze to build on Windows because they use cmake (just need to download released bundle rather than from git to avoid problems.) A couple of the optional libtls functions don't work on Windows (tls_load_file), but 100% of OpenSSL-1.0.1+ api functions I tried so far worked fine. For me, the biggest downside is LibreSSL doesn't support X25519 yet, while BoringSSL and OpenSSL both support it. And BoringSSL is starting to get easier to use with other software like nginx without messy patches. Hopefully, X25519 will be added as a beta feature during LibreSSL 2.5.x and released as stable in 2.6. If you have time, take a look at
Read the rest
https://github.com/libressl-portable/openbsd And email patches to: tech@openbsd.org Edited: tls_load_file instead of tls_read
In Alpine Edge has switched to libressl
neerdowell·Apr 13, 2016
> It fails in a poorly set up chroot, not any old chroot. It fails for any program that calls chroot(2) and chroots to a location that hasn't had /dev/urandom constructed, which is... almost every program that sandboxes by calling chroot(2). > I can't remember ever running out of file descriptors unless a program had a leak. You've probably never used ulimits or login groups then. > But if you want to argue that position too, make sure you mention that cputime and memory could also be exhausted, leading to... well... any other method failing in a similar fashion. You're writing a library and in one of the functions you call arc4random(3). How would you handle memory being exhausted at the time when arc4random is called? Hint: you wouldn't. You'd let the OS handle it, probably by terminating something. Which might be the running process o
Read the rest
r another process. New situation, you're writing a library and in one of the functions you open() a file handle and read() from it. How would you handle that operation failing? Thought about it? Got your answer? Good. Now see the comments in LibreSSL for why your answer to that is wrong: https://github.com/libressl-portable/openbsd/blob/cb62fd8b9b... > But calling /dev/urandom unreliable is a little bit intellectually dishonest. /dev/urandom is not a high-availability randomness source, therefore it is unreliable. It is not intellectually dishonest, it is a statement of fact.
In An Analysis of OpenSSL's Random Number Generator

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.