Bug 2213270

*** Bug 2005536 has been marked as a duplicate of this bug. ***

Note: According to discussion in the original bug (RHBZ#2005536) and the Legal mailing list, this package is built from sources from which all code related to the p434 elliptic curve has been removed, since it has not yet been approved as permissible in Fedora.

> git apply ../0001-remove-references-to-code-related-to-the-p434-curve.patch

The patch is missing from the srpm, making the clean archive generation not reproducible.

Not sure if we should follow the policy for pregenerated code[1] here. The situation fits, but it would make the packaging insanely cumbersome even without regenerating the code :(

[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#pregenerated-code

Good catch, I will include the patch as a Source file.

===

The generated code guidelines don't really apply here, as far as I understand. The code is not generated from other sources, but from ... well, prime numbers and a few parameters, and these are documented at the top of each source file.

Additionally, packaging the whole fiat crypto framework (which includes support for a dozen languages, not just Rust). It's also written in OCaml (but already packaged for Fedora): https://src.fedoraproject.org/rpms/coq

So I'd say the relevant parts of the pregenerated sources are fulfilled:

- generated by free software that is available in Fedora
- process would be reproducible since input parameters are documented (but I'm not interested in packaging the tooling itself, because that looks like a whole different beast)

fiat-crypto is an interesting thing. It's, of course, way over my head (I think we need someone like jjames to translate things to a regular English), but I've got a surface grasp of the papers referenced

The team behind fiat-crypto implemented several things:
 1. a formally verified implementation of a set of operations on mathematical primitives used in ECC (Montgomery curves, Solinas primes, etc...) in Coq (a functional language with formal proof capabilities, which is commonly used to implement said formally verified algorithms)
 2. a tooling to rewrite the algorithm of choice in a selected language, specialized for a given set of constants.
 3. a proof that the operation in 2 preserves the properties of an already verified algorithm.
    I'd say they did that by implementing things in Coq, again, but my language comprehension skills struggle with an intermediate level Haskell so I can't read their sources.

Well, if we twist a point of view a bit, we can consider 1 a part of the tooling and not a source code that gets transformed into Rust. With that interpretation I'm going to agree and approve this.

(I'm finding the part with regenerating the archive with `cargo package` curious, but I guess that creates some metadata required by cargo).

---

Please, ensure that the clean archive can be regenerated from the dist-git or srpm before import.

Thanks for the review! Yeah, I agree, this is an interesting (but a bit unusual) project. But I think the way it's done now is the best that can be done with reasonable effort. The part about re-packaging the ".crate" file only ensures that the correct files are included in the tarball (.crate files are just .tar.gz) and that the crate metadata / Cargo.toml remains valid. I will ensure that the "cleaned" .crate file can be produced from dist-git contents before I import and build things.

The Pagure repository was created at https://src.fedoraproject.org/rpms/rust-fiat-crypto

Imported and built:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-7bf086d1d2