https://bugzilla.redhat.com/show_bug.cgi?id=2255917
--- Comment #4 from Fabio Valentini decathorpe@gmail.com --- Thank you for the comprehensive review! I'll respond to your points inline.
I will post a new version of the package as soon as I'm back at my Fedora machine.
(In reply to Ben Beasley from comment #3)
Package Review
Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
The package is based on the output of rust2rpm, simplifying the review.
The following differences are noted:
The tests are disabled due to missing dependencies. While rust-ntest was packaged since the review was posted, there is still no rust-interprocess.
Since this package is security-relevant, it would be especially nice to enable the tests at some point.
Yes, I agree. That is why I already packaged ntest and submitted a review request for editdistancek. I did not want to package the interprocess crate, since it pulls in additional dependencies, and it itself and some of its dependencies are problematic wrt/ packaging. The interprocess crate appears to be used only for *some* integration tests, so with editdistancek and ntest available, I should be able to run most of the test suite.
Patches make two changes that are reasonable to do downstream-only:
- drop features for unavailable crypto backends
- build with OpenSSL crypto backend
The default crypto backend is Nettle, but with OpenSSL being the preferred crypto library in Fedora, I thought it would make sense to switch. This also matches what we do in rpm-sequoia.
A patch ports from the home-dir crate to shellexpand, calling the former obsolete.
This makes sense to do upstream, and in fact I found that you offered it
there:
# https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/merge_requests/111 # https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/commit/ 03f23a7f960f1cc0ff74b499c0c2d1ce657e9a52
Please add a spec-file comment to document the patch upstream status.
- The license expression was correctly constructed based on %cargo_license_summary.
===== Issues =====
The upstream status of the patch to migrate from home-dir to shellexpand should be documented. Please add a link to the merge request and/or commit:
#
https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/merge_requests/111 # https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/commit/ 03f23a7f960f1cc0ff74b499c0c2d1ce657e9a52
Sure, I will do that. I forgot that this MR was merged just *after* the 0.4.0 release.
- The file src/err-codes.h.in is taken from libgpg-error and retains the LGPL-2.1-or-later license of that package, but the Cargo.toml file only mentions the “overall” license of GPL-3.0-or-later. At minimum, it looks
like the base package License needs to change from
License: GPL-3.0-or-later
to
License: GPL-3.0-or-later AND LGPL-2.1-or-later
based on current Fedora license guidelines that prohibit using an “effective license.” Does that mean you should patch Cargo.toml and/or ask upstream to change it? I don’t know; you’re the Rust expert here. ;-)
There *is* a LGPL-2.1-or-later term in the binary RPM’s License, but that is by chance, from buffered-reader and several sequioa-* crates.
The bundling should also be indicated, something like:
# A single header describing error codes, err-codes.h.in, is copied from # libgpg-error. Since this is not a public header file, unbundling is not # possible. It is not clear exactly which version of libgpg-error this
file # was copied from. Provides: bundled(libgpg-error)
Good catch. I will add both for the next revision of the package (as soon as I'm back at my Linux machine).
Rpmlint reports:
sequoia-chameleon-gnupg.x86_64: W: crypto-policy-non-compliance-openssl
/usr/bin/gpg-sq SSL_CTX_set_cipher_list
https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/ #_cc_applications
I know that calling SSL_CTX_set_cipher_list() is OK as long as the string is "PROFILE=SYSTEM". That function isn’t mentioned in the source code, so the call is happening in a dependency (so if there isa bug, it isn’t in this package).
In dependency crate source openssl-0.10.62/src/ssl/connector.rs, I see:
impl SslConnector { /// Creates a new builder for TLS connections. /// /// The default configuration is subject to change, and is currently
derived from Python. pub fn builder(method: SslMethod) -> Result<SslConnectorBuilder, ErrorStack> { let mut ctx = ctx(method)?; ctx.set_default_verify_paths()?; ctx.set_cipher_list(
"DEFAULT:!aNULL:!eNULL:!MD5:!3DES:!DES:!RC4:!IDEA:!SEED:!aDSS:!SRP:!PSK", )?; setup_verify(&mut ctx);
Ok(SslConnectorBuilder(ctx)) } […] }
There are other hard-coded cipher lists in SslAcceptor, but they are in functions explicitly corresponding to configurations recommended by Mozilla (mozilla_intermediate_v5, mozilla_intermediate, mozilla_modern), which seems like is should probably be acceptable.
It seems likely that the builder function above is called, but I’m not sure how to prove that or otherwise further analyze this. I did find DEFAULT:!aNULL:!eNULL:!MD5:!3DES:!DES:!RC4:!IDEA:!SEED:!aDSS:!SRP:!PSK in the output of “strings gpg-sv”, which supports the above theory.
Anyway, *if* there is a failure to respect the system crypto policy it’s probably not due to anything in this package’s, so I am not sure whether it should block this review, but it does appear that this needs investigating.
Hm. I've seen similar issues in other Rust packages that use the OpenSSL bindings. But I agree, since the code in question is not in this package, it should be "fixed" (if there *is* something to be fixed) in the actual place the code is located.
I *could* switch the crypto backend back to Nettle, I'm sure that would silence the rpmlint warning (but I don't even know if Nettle follows the system crypto policy :))
===== Notes =====
Rpmlint reports:
sequoia-chameleon-gnupg.x86_64: W: no-manual-page-for-binary gpg-sq sequoia-chameleon-gnupg.x86_64: W: no-manual-page-for-binary gpgv-sq
Man pages are always desired, https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages, but
the help2man output for these commands is not great, so there isn’t much to be done here unless we want to maintain them by hand.
Most Sequoia PGP projects ship their own actual man pages, but they rely on the translation layer from the "clap" command line parser -> man page. But this project does *not* use "clap" for parsing command line arguments, so that's not possible here. I agree that "help2man" isn't really helpful here, so I'd say I'd rather ship *no* manpages (and let people use the "--help" flag) than ship sub-par or broken man pages.