-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libressl: add 3.1.3, default to it, remove 2.9 #88195
Conversation
Let's see which of the builds will fail: @GrahamcOfBorg build acme-client |
The foundationdb packages seem broken already (e.g https://hydra.nixos.org/build/119086724/nixlog/1). But, wasm-pack's failure is more actionable: https://logs.nix.ci/?key=nixos/nixpkgs.88195&attempt_id=88b84284-44e8-4d93-8105-08c64ddc3430 . I think the proper fix for it will be making it switch to openssl. Could you please test this locally before pushing? |
|
||
libressl = libressl_3_0; | ||
libressl = libressl_3_1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I'd like to see a comment here, indicating future contributors, that libressl
should always point to the latest version. See https://discourse.nixos.org/t/nixpkgs-policy-regarding-libraries-available-in-multiple-versions/7026 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a comment, with a link to that topic.
Thanks for taking a look!
This is the result of a conservative compatibility check in Is there a way to override a single crate for a Rust project? I suppose we can patch Probably switching to OpenSSL is the quick fix, what do you think @doronbehar? Edit: Yet another alternative would be to make |
In the meantime, LibreSSL 3.1.2 was released. I’ve updated this pull request accordingly. |
Patching Cargo.lock is a bit annoying... It wouldn't have been that hard if we had only started right from the start to keep derivations for all crates we use to build Rust programs as derivations in Nixpkgs. Rather, we use fixed output derivations which have even more issues than this, see NixOS/nix#2270 & my comment & discussion at #84826 (comment) .
I think it'll be most proper to let future us handle that :). But seriously, I think this is the cleanest way to handle our issue. More over, I think that we should avoid having some projects depend on Libressl and others on Openssl if they are almost compatible. I mean, unless a project requires specifically Libressl, what advantage does one have on the other? I'm aware of the licensing issue, but is it a big deal for wasm-pack? IDK, it'll need some research... Perhaps it'll be best to change |
Oh and BTW please squash 082e12f . |
There's an upstream issue for wasm-pack with openssl, as indicated by the comment in wasm's default.nix: rustwasm/wasm-pack#650 I'm taking my words back. An even cleaner solution, would be this: diff --git i/pkgs/top-level/all-packages.nix w/pkgs/top-level/all-packages.nix
index 548b09a6849..8ff32d7fc92 100644
--- i/pkgs/top-level/all-packages.nix
+++ w/pkgs/top-level/all-packages.nix
@@ -26174,6 +26174,7 @@ in
wasmer = callPackage ../development/interpreters/wasmer { };
wasm-pack = callPackage ../development/tools/wasm-pack {
+ libressl = libressl_3_0;
inherit (darwin.apple_sdk.frameworks) Security;
}; Which will even reduce by 1 the amount of packages ofborg will detect as affected by this change. |
Stable LibreSSL releases are supported one year after their OpenBSD release. OpenBSD 6.5 with the 2.9 branch was released on 2019-05-01.
It is the latest now, let's default to it. 3.0 will still be supported until October, when OpenBSD 6.6 turns one year old. Also add reminder to use the latest version, as suggested by doronbehar.
The application is incompatible with LibreSSL 3.1 because rust-openssl has a compile-time check for supported LibreSSL versions, and the version of rust-openssl that wasm-pack depends on does not yet support LibreSSL 3.1.
Yes, that seems like the cleanest solution to me too. I added that, and I squashed 082e12f. Please take another look. I can also confirm that |
Exactly 👍. Let's perform another builds test: @GrahamcOfBorg build acme-client |
Among those that failed to build by ofborg at this point, are:
All of the foundationdb related packages seem to fail already to build on hydra, according to:
(Thanks As for So to summarize, this PR Should be good to go. |
@thoughtpolice, cc @fpletz, is there anything else I can do to help move this forward? |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
In the meantime, LibreSSL 3.1.3 has been released. I updated this PR accordingly. |
got this output from nix-review, not sure if there is any regression. Somebody will have to check.
|
@Lassulus We already checked 3.1.2 at #88195 (comment) and it seems that these packages were already broken. Let's run once more for 3.1.3, the builds that shouldn't fail: @GrahamcOfBorg build acme-client |
Looks like all the builds that are expected to pass still do, please take another look @Lassulus. |
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)I also tested compiling Nginx against this LibreSSL, which succeeded.