https://bugzilla.redhat.com/show_bug.cgi?id=2350145 --- Comment #2 from Fabio Valentini <decathorpe@xxxxxxxxx> --- Notes: 1. I have not submitted a koji scratch build, though there are test builds in COPR for all architectures: https://copr.fedorainfracloud.org/coprs/decathorpe/aws-lc-rs/monitor/ 2. I put up a repo on pagure with spec file, patches, and rust2rpm.toml config file for easier review: https://pagure.io/aws-lc-rs/blob/main/f/rust-aws-lc-sys 3. After looking through the source code, I don't think this package contains anything objectionable (wrt. cryptography that Fedora isn't allowed to ship). This needs a double-check. 4. I don't think un-bundling aws-lc (the C / C++ library) is feasible. aws-lc doesn't provide a stable ABI, and the bindings in aws-lc-sys are tightly coupled to a specific version (the version that is bundled). The -devel subpackage (with contains the source code) has appropriate "Provides: bundled(aws-lc) = 1.46.0". 5. There are some pre-compiled object files included (used only in Windows), but they are stripped in %prep regardless. 6. The patches should be appropriately documented in the spec file, but here's a summary: - Patch 0001: Unconditionally regenerate Rust bindings for aws-lc at build time (requires rustfmt). - Patch 0002: Set CMake mode for building the bundled aws-lc to RelWithDebInfo unconditionally. - Patch 0003: Enable re-generating some generated assembly code from scratch (requires Perl). - Patch 0004: Hack to work around a "bug" in the cmake crate which would otherwise cause build failures. - Patch 0005: Set CMake minimum_required_version to 3.15 (instead of 3.0) to avoid failures with CMake 4. 7. This has not yet gone through the review wrt/ Crypto Policies: https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/#_new_crypto_libraries Note that I'm not sure whether this requirement even applies here (or *can* be applied). In the default configuration, aws-lc-sys provides only APIs that are roughly equivalent to libcrypto from OpenSSL, not those from libssl. As I understand it, that amounts to low-level cryptography primitives, and not protocol implementations like TLS. I'm not sure applying a crypto policy in these low-level APIs would make sense - or would even be possible. To me, it seems like crypto policy enforcement would need to be handled in higher level code, like actual TLS protocol implementations. This crate (aws-lc-sys) does provide a feature ("ssl") to optionally also provide symbols equivalent to libssl, however, this feature is unused in the "safe" Rust bindings in aws-lc-rs. So, to be safe, it would even be possible to unconditionally disable this feature in the package. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2350145 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202350145%23c2 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
