Skip to content

Update libchallenge bypass ristretto ffi#106

Merged
exarkun merged 7 commits intomainfrom
update-libchallenge_bypass_ristretto_ffi
Jan 13, 2022
Merged

Update libchallenge bypass ristretto ffi#106
exarkun merged 7 commits intomainfrom
update-libchallenge_bypass_ristretto_ffi

Conversation

@exarkun
Copy link
Copy Markdown
Collaborator

@exarkun exarkun commented Jan 13, 2022

Fixes ever-green libchallenge_bypass_ristretto_ffi link errors. Probably for good this time, maybe!

@exarkun
Copy link
Copy Markdown
Collaborator Author

exarkun commented Jan 13, 2022

This is in good shape for review except that it should be changed to point at a master revision of python-challenge-bypass-ristretto once there is one that has the currently targeted branch merged (see LeastAuthority/python-challenge-bypass-ristretto#42).

Copy link
Copy Markdown
Contributor

@tomprince tomprince left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine to land after the upstream PR has landed.

I do have a suggestion about nixpkgs pins, but that should be handled in a separate PR.

Comment thread .circleci/config.yml
# time of this comment. We can bump it to a newer version when that
# makes sense. Meanwhile, the platform won't shift around beneath us
# unexpectedly.
NIXPKGS_REV: "92609f3d9bc3acffbdbe54fa1c591a885612aa73"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the only place this was being used was for the fetchFromGitHub call in nix/challenge-bypass-ristretto-repo.nix so is now unneeded.

sources = import ./sources.nix;
in
import "${src}/default-challenge-bypass-ristretto-ffi.nix" { }
{ callPackage
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this means that we use whatever pinned version of nixpkgs that we get from haskell.nix for compiling the rust library. I wonder if we should instead be using our own pin, which we can update on our own schedule (in practice, we'd pass in the version from PrivateStorageio for deployment, I think).

I think for the haskell packages, it makes sense to use the haskell.nix pins, since that we we can use their binaries, and it matches what they test. But they update the pin less often than we do, so it would make sense to use our pin for things not related to haskell.

However, this is out-of-scope for this PR.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yea, that sounds like a reasonable future change.

@exarkun exarkun marked this pull request as ready for review January 13, 2022 21:20
@exarkun exarkun merged commit 56f9e8f into main Jan 13, 2022
@exarkun exarkun deleted the update-libchallenge_bypass_ristretto_ffi branch January 13, 2022 21:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants