Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://fedorapeople.org/~csnyder/subscription-manager-rhsm-certificates/subscription-manager-rhsm-certificates.spec SRPM URL: https://fedorapeople.org/~csnyder/subscription-manager-rhsm-certificates/subscription-manager-rhsm-certificates-20220425-1.fc35.src.rpm Description: This package contains certificates required for communicating with the REST interface of a Red Hat Unified Entitlement Platform, used for the management of system entitlements and to receive access to content. Fedora Account System Username: csnyder
Note for reviewers: the binary package, subscription-manager-rhsm-certificates, already exists in Fedora, currently built by the subscription-manager source. We (subscription-manager developers) recently split the certificates in their own repository, as they change very rarely. The content (in terms of files installed, directories owned, etc) of the subscription-manager-rhsm-certificates built by this source is the same as the current version built by the subscription-manager source; the only change should be the addition of %license, more in line with the modern Fedora packaging style.
Taking the review. I am not sure why /etc/rhsm/ca directory were chosen. I think much more appropriate would be something like /etc/pki/rhsm. Could it maybe use symlinks to pki for backward compatibility and move certificates to /etc/pki, where I think this kind of content belongs. Those pem files do not have %config(noreplace) tag. Are they configuration files or not? Either they should have %config(noreplace) for *.pem files or those files should be in /usr/share/pki/rhsm. If backward compatibility were symlink, they would allow simple replacement in /etc/rhsm with locally configured data. I would suggest checking at least validity of certificates in %check section. For example by openssl tool: for PEM in *.pem; do openssl x509 -in $PEM -noout -checkend 0 done
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues found: - /etc/rhsm is owned both by subscription-manager and subscription-manager-rhsm-certificates But python3-subscription-manager-rhsm, dependency of subscription-manager, requires certificates anyway. I think that makes /etc/rhsm directory candidate to be owned just by certificates and subscription-manager could just explicitly require rhsm-certificates as well. - /etc/rhsm is used for *.pem certs, but does not use %config(noreplace). Use /usr/share if that content is not for suitable for manual configuration. ===== MUST items ===== Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "GNU General Public License, Version 2", "Unknown or generated", "*No copyright* GNU General Public License, Version 2". 10 files have unknown license. Detailed output of licensecheck in /home/pihhan/fedora/review/2078592-subscription-manager-rhsm- certificates/licensecheck.txt [!]: Package does not own files or directories owned by other packages. Note: Dirs in package are owned also by: /etc/rhsm(subscription- manager, subscription-manager-rhsm-certificates) [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [!]: Package obeys FHS, except libexecdir and /usr/target. [x]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 0 bytes in 0 files. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [ ]: Final provides and requires are sane (see attachments). [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [?]: SourceX tarball generation or download is documented. Note: Package contains tarball without URL, check comments [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [x]: Package should compile and build into binary rpms on all supported architectures. [!]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Cannot parse rpmlint output: Rpmlint (installed packages) ---------------------------- Cannot parse rpmlint output: Requires -------- subscription-manager-rhsm-certificates (rpmlib, GLIBC filtered): Provides -------- subscription-manager-rhsm-certificates: subscription-manager-rhsm-certificates Generated by fedora-review 0.8.0 (e988316) last change: 2022-04-07 Command line :/usr/bin/fedora-review -b 2078592 Buildroot used: fedora-rawhide-x86_64 Active plugins: Shell-api, Generic Disabled plugins: fonts, PHP, C/C++, Java, Ocaml, Perl, R, Haskell, SugarActivity, Python Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH
Hi Petr, thanks for the review! Note that this is mostly a split of an existing binary package to its new source from the "subscription-manager" source -- see my notes in comment #1. > I am not sure why /etc/rhsm/ca directory were chosen. I think much more > appropriate would be something like /etc/pki/rhsm. Could it maybe use > symlinks to pki for backward compatibility and move certificates to > /etc/pki, where I think this kind of content belongs. We cannot really change the directory, as it is what subscription-manager uses by default; I think it is also wanted to use a separate sets of certificates than the system ones, and in general this kind of discussion would be better suited for upstream. > Those pem files do not have %config(noreplace) tag. Are they configuration > files or not? Kinda not. If I read the RPM documentation correctly, I think we should rather use %config (without noreplace), as those files are generally not modified, so we want updates to them to be available by default. > I would suggest checking at least validity of certificates in %check > section. For example by openssl tool: > > for PEM in *.pem; do > openssl x509 -in $PEM -noout -checkend 0 > done I thought about that too, however it seemed "too dumb". Proposed upstream: https://github.com/candlepin/subscription-manager-rhsm-certificates/pull/1 (In reply to Petr Menšík from comment #3) > Issues found: > - /etc/rhsm is owned both by subscription-manager and > subscription-manager-rhsm-certificates > But python3-subscription-manager-rhsm, dependency of subscription-manager, > requires certificates anyway. > I think that makes /etc/rhsm directory candidate to be owned just by > certificates and subscription-manager > could just explicitly require rhsm-certificates as well. Hm maybe something to change in subscription-manager, rather than subscription-manager-rhsm-certificates.
Thank you very much for the review!! I'm not sure I see the benefit of adding the %config directive for these files which are not intended to be modified by the user. We can consider moving the pem files to another directory but it is worth mentioning that this directory is used by katello and related tooling to add *.pem files for use in communicating with foreman / Satellite instances so unless it is a blocking item I'd rather continue that discussion with those folks as well after the addition of this package. To address the ownership of the /etc/rhsm directory I've opened this PR against subscription-manager: https://github.com/candlepin/subscription-manager/pull/3045 What are the next steps?
(In reply to Chris Snyder from comment #5) > Thank you very much for the review!! > > I'm not sure I see the benefit of adding the %config directive for these > files which are not intended to be modified by the user. > We can consider moving the pem files to another directory but it is worth > mentioning that this directory is used by katello and related tooling to add > *.pem files for use in communicating with foreman / Satellite instances so > unless it is a blocking item I'd rather continue that discussion with those > folks as well after the addition of this package. > > To address the ownership of the /etc/rhsm directory I've opened this PR > against subscription-manager: > https://github.com/candlepin/subscription-manager/pull/3045 > > What are the next steps? If they are never intended to be modified, they belong to /usr/share instead. I think every file under %_sysconfdir should be marked either %config or %config(noreplace). Please mark it as %config, it would keep the behaviour on updates, but possible user's changed won't be lost forever. If those certs should never be updated manually, then they should be moved to /usr/share and only symlinks provided for backward compatiblity. Please choose one of approaches, but I don't think non-backed up files belong anywhere to /etc. Note: guidelines make it clear they *must* be marked config files. It is not only should, therefore I would give release+ if they are either config files or just links to /usr dir. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_configuration_files
(In reply to Petr Menšík from comment #6) > (In reply to Chris Snyder from comment #5) > > Thank you very much for the review!! > > > > I'm not sure I see the benefit of adding the %config directive for these > > files which are not intended to be modified by the user. > > We can consider moving the pem files to another directory but it is worth > > mentioning that this directory is used by katello and related tooling to add > > *.pem files for use in communicating with foreman / Satellite instances so > > unless it is a blocking item I'd rather continue that discussion with those > > folks as well after the addition of this package. > > > > To address the ownership of the /etc/rhsm directory I've opened this PR > > against subscription-manager: > > https://github.com/candlepin/subscription-manager/pull/3045 > > > > What are the next steps? > > If they are never intended to be modified, they belong to /usr/share instead. We all agree with this. The problem here is that "the ship has sailed". subscription-manager has been using for many years /etc/rhsm/ca as default location for CAs to use when connecting to the entitlement server, which makes changing this a non-trivial task. Other software interacts with it by adding own content (e.g. katello), so we cannot just switch the location. Other approaches are possible, but IMHO they are out of the scope of this new package process. > I think every file under %_sysconfdir should be marked either %config or > %config(noreplace). Please mark it as %config, it would keep the behaviour > on updates, but possible user's changed won't be lost forever. The situation is that the user very rarely, if ever, needs to _change_ the existing files in /etc/rhsm/ca. Adding new ones, for example to authenticate the connection to an own Candlepin, is definitely supported. > Note: guidelines make it clear they *must* be marked config files. It is not > only should, I did a research about this: packages such as fedora-gpg-keys, ca-certificates, and containers-common do install bits in /etc/pki without marking them as %config (unless I misread their spec files). So IMHO there is either - an inconsistency in the distribution - or a different handling for this kind of "non-textual" stuff > therefore I would give release+ if they are either config files > or just links to /usr dir. Petr, I understand you want to improve the quality of Fedora, and I don't think anyone of us wants to make it worse. However, please consider the situation here: - there is existing software with long-term practices, be them good or bad - it is not possible to change the software right now - the subscription-manager-rhsm-certificates package exists *already* in Fedora, without the files in /etc/rhsm/ca marked as %config - the current proposed new source builds a new package that is _not_ worse than what is already existing, and actually improves it a bit (for example LICENSE is shipped properly) Therefore all I ask is to look at the whole picture, not only at the Fedora guidelines, and be slightly more understanding of the situation. Accepting the proposed new source does not lower the quality of Fedora, and we definitely can fix further issues on it faster once it's approved. Thanks for the review, and the patience.
Yes, but there was long discussion abount moving fedora-gpg-keys to /usr where they belong. The only block were too many certificates already present in /etc. All of those packages install just certificates to /etc/pki subtree. But I have explained that all and you are unwilling to even mark it %config. Which would not break anything, would not make backward incompatibility. Okay, I have stated what I wanted. It is clear you disagree. As it seems this review is blocking further building, I will make it pass. It could be improved in further version. Or not, it is your call.
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/subscription-manager-rhsm-certificates