Change:
}; in { <del> libressl_3_4 = generic { version = "3.4.3"; hash = "sha256-/4i//jVIGLPM9UXjyv5FTFAxx6dyFwdPUzJx1jw38I0="; knownVulnerabilities = [ "Support ended 2022-10-14." ]; patches = [ (fetchpatch { # https://marc.info/?l=libressl&m=167582148932407&w=2 name = "backport-type-confusion-fix.patch"; url = "https://raw.githubusercontent.com/libressl/portable/30dc760ed1d7c70766b135500950d8ca9d17b13a/patches/x509_genn.c.diff"; sha256 = "sha256-N9jsOueqposDWZwaR+n/v/cHgNiZbZ644d8/wKjN2/M="; stripLen = 2; extraPrefix = "crypto/"; }) ]; }; </del> libressl_3_6 = generic { version = "3.6.2"; hash = "sha256-S+gP/wc3Rs9QtKjlur4nlayumMaxMqngJRm0Rd+/0DM=";

Discussion:
LibreSSL 3.4 is no longer supported upstream. It became unsupported on October 14th 2022, one year after . At the time of writing, 3.5 and 3.6 are both supported. that fixes a serious vulnerability: I suspect (but haven’t verified) that this vulnerability is present in LibreSSL 3.4. It is time to remove it from Nixpkgs. However, there are some packages that still depend on it. all depend on . I tried building against and , but both fail. I don’t see any packages that depend on , so I think we could remove the older versions, if we can first update FoundationDB to a version that is compatible with a more recent LibreSSL release. Maybe will be sufficient for this. Alternatively, we might patch FoundationDB. The compilation errors are about an incomplete type for which only a forward declaration is known. I haven’t looked into it deeply but it may be easy to fix. as the maintainers of , what are your thoughts on this? This has been addressed by . <details<summaryOriginal comment</summaryThe other package that explicitly depends on LibreSSL 3.4 is . This is a proprietary package so I couldn’t test if it is compatible with a more recent LibreSSL release, it might actually be. as the maintainers of , could you try and see if it is compatible with a newer LibreSSL release? </details
The x400Address issue that was patched recently is present in LibreSSL 3.4. The fix is very small and applies to all older versions that have it, so it might be an option [patch it][1] while you sort out the other issues. If you could share build logs for the foundationdb issues I can take a look if you want. [1]:
You can drop this. uses their bundled OpenSSL and drops the dependency since it's incompatible with even this LibreSSL version. It's about to merge.
all of darwin depends on 34 at the moment. You've pinned to 3.4, do you know if by any chance we can upgrade to 3.5 ? maybe ?
I'm quite sure we can't. My history with that package is and . happened, because someone did .

iirc happened, because this package depends on ancient long unsupported openssl APIs that weren't part of anymore.
Small rectification, after a bit more testing, it doesn't appear to be all of darwin that is impacted by that change. So perhaps we don't need to put too much effort into this. I'm still trying to figure out the impact.
I’m working on a fix for , which drops the dependency on from by unconditionally dropping Unbound from the build (instead of only on aarch64-darwin). Apple doesn’t even include Unbound in macOS anymore, and it’s not present in newer source releases. That should remove as a blocker for dropping LibreSSL 3.4.