crate2nix stumbles over arbitrary #[cfg] conditionals about crate2nix HOT 4 CLOSED

Looks like this was fixed by

• #307

https://github.com/dalek-cryptography

Be careful. Performance is not the reason why signing and decryption primitives are written in assembler. Constant-time execution is the reason.

https://github.com/dalek-cryptography/subtle/blob/6b6a81ad9a6a00c0b42c327eaf4b2f785774377e/README.md?plain=1#L13-L15

https://github.com/dalek-cryptography/curve25519-dalek/blob/72761ca6b4772af985f969db53faf7accbad9b36/curve25519-dalek/README.md?plain=1#L215-L216

from crate2nix.

@amjoseph-nixpkgs true.

I knew that supporting all target expressions will be tricky, so I thought the approach to avoid errors and be fine if it compiles is a good one. But I was not thinking about security implications...

Probably, this should be opt-in but then again it will break already "working" crates again...

from crate2nix.

But I was not thinking about security implications...

Oh, my comment about constant time refers to @flokli's reproducer crate, dalek-cryptography.

I was not criticizing crate2nix!

In any event I think this issue can be closed as resolved by #307. I'm able to crate2nix generate && nom build -f Cargo.nix the reproducer crate.

from crate2nix.

This indeed does work now, thanks.

Any chance for a new release to be tagged? There's quite a bunch of things I cherry-pick since the last release…

from crate2nix.