https://bugzilla.redhat.com/show_bug.cgi?id=2255917 --- Comment #4 from Fabio Valentini <decathorpe@xxxxxxxxx> --- 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. -- 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=2255917 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202255917%23c4 -- _______________________________________________ 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
