Spec URL: https://download.copr.fedorainfracloud.org/results/simo/fips-provider/srpm-builds/10298410/fips-provider.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/simo/fips-provider/srpm-builds/10298410/fips-provider-1.5.0-2.fc45.src.rpm Description: This package provides a cryptographic module that is both an OpenSSL provider as well as a PKCS#11 software token. Fedora Account System Username: simo
Copr build: https://copr.fedorainfracloud.org/coprs/build/10304088 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2456554-fips-provider/fedora-rawhide-x86_64/10304088-fips-provider/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
> ## START: Set by rpmautospec I think the spec file posted above should be in the format how you want to import it into the dist git. This one looks like already pre-processed by copr somehow. I would suggest to keep one "source" spec file in some people.redhat.com or fedorapeople.org > local files = rpm.expand("%_specdir/fips-provider-next.spec") This is hashing different file than the package name. I guess using macro for the name will be less error prone (if it will be processed before the Name is defined). > Source3: openssl-%{osslver}.tar.gz Is this upstream OpenSSL release tarball? Should it have the full URL so it can be verified its the authentic release (ideally with gpg signature)? Or is this already patched openssl version? In that case, there should be a comment describing how this was created, from which repository and using which patches so it can be reproduced and verified. > BuildRequires: gcc clang > BuildRequires: coreutils, perl-interpreter, sed, zlib-devel, /usr/bin/cmp Any specific reason why some of the build requires are separated by whitespace and some with comma? Is it taken from the openssl spec file? Should we clean it up? > Patch101: 0001-Re-enable-FIPS-security-checks.patch Nit: I prefer to have the patches next to the sources and build requires after that, but thats probably matter of taste. > %global features kryoptic-lib/fips,kryoptic-lib/nssdb > ... > %cargo_generate_buildrequires -n -f fips,nssdb,ossl400 > ... > %cargo_build -n -f fips,nssdb,ossl400 > ... > %{cargo_license_summary} > ... > %{cargo_license -n -f fips,nssdb,ossl400} > LICENSE.dependencies > ... > %cargo_test -n -f fips,nssdb,ossl400 Please, use the %{features} macro for listing the features to make sure they are defined in one place (as discussed yesterday) and we do not need to keep them in sync at three different places Given that this bundles the whole OpenSSL sources, we will need likely a ticket, but we should do `Provides: bundled(openssl) = %{osslver}`, I think. Going through the packaging guidelines, how this will handle cryptographic policies? For the fips provider its probably not an issue, but for the generic purpose fips token, this might be useful to have answers for. I think this is mostly covered in the following issue and likely applies to kryoptic itself too: https://github.com/latchset/kryoptic/issues/319 > make the automated service complains that we should build in parallel: [!]: Uses parallel make %{?_smp_mflags} macro. From what I see, OpenSSL does that so I would take an inspiration there: https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/openssl.spec#_257 > %define osslver 4.0.0-beta1 Please, try to use global per packaging guidelines where possible: [ ]: Spec use %global instead of %define unless justified. Note: %define requiring justification: %define autorelease(e:s:pb:n) %{?-p:0.}%{lua:, %define osslver 4.0.0-beta1, %define srpmhash() %{lua:, %define __spec_install_post %{?__debug_package:%{__debug_install_post}} %{__arch_install_post} %{__os_install_post} pushd openssl-%{osslver} %{SOURCE4} $RPM_BUILD_ROOT/%{_libdir}/ossl-modules/fips.so %{nil} > mkdir -p -m755 $RPM_BUILD_ROOT%{_libdir}/ossl-modules > ... > mkdir -p -m755 $RPM_BUILD_ROOT%{_libdir}/pkcs11 [ ]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib64/pkcs11, /usr/lib64/ossl-modules I think these should be just created as root explicitly. Likely with something like: %attr(0755,root,root) %{_libdir}/pkcs11 %attr(0755,root,root) %{_libdir}/ossl-modules
(In reply to Jakub Jelen from comment #2) > > ## START: Set by rpmautospec > > I think the spec file posted above should be in the format how you want to > import it into the dist git. This one looks like already pre-processed by > copr somehow. I would suggest to keep one "source" spec file in some > people.redhat.com or fedorapeople.org I did not realize this would be changed by COPR, I will try and find a new place for the "real" spec. > > local files = rpm.expand("%_specdir/fips-provider-next.spec") ouch I will see if I can use %{name}.spec in there... > > This is hashing different file than the package name. I guess using macro > for the name will be less error prone (if it will be processed before the > Name is defined). > > > Source3: openssl-%{osslver}.tar.gz > > Is this upstream OpenSSL release tarball? It is the upstream tarball untouched. > Should it have the full URL so it > can be verified its the authentic release (ideally with gpg signature)? Perhaps, I just copied what's in openssl.spec (from the openssl package), will fix > Or is this already patched openssl version? In that case, there should be a > comment describing how this was created, from which repository and using > which patches so it can be reproduced and verified. it's not, we are good there > > > BuildRequires: gcc clang > > BuildRequires: coreutils, perl-interpreter, sed, zlib-devel, /usr/bin/cmp > > Any specific reason why some of the build requires are separated by > whitespace and some with comma? Is it taken from the openssl spec file? > Should we clean it up? Will do that > > > Patch101: 0001-Re-enable-FIPS-security-checks.patch > > Nit: I prefer to have the patches next to the sources and build requires > after that, but thats probably matter of taste. works for me too > > > %global features kryoptic-lib/fips,kryoptic-lib/nssdb > > ... > > %cargo_generate_buildrequires -n -f fips,nssdb,ossl400 > > ... > > %cargo_build -n -f fips,nssdb,ossl400 > > ... > > %{cargo_license_summary} > > ... > > %{cargo_license -n -f fips,nssdb,ossl400} > LICENSE.dependencies > > ... > > %cargo_test -n -f fips,nssdb,ossl400 > > Please, use the %{features} macro for listing the features to make sure they > are defined in one place (as discussed yesterday) and we do not need to keep > them in sync at three different places ack > Given that this bundles the whole OpenSSL sources, we will need likely a > ticket, but we should do `Provides: bundled(openssl) = %{osslver}`, I think. ok. > > Going through the packaging guidelines, how this will handle cryptographic > policies? For the fips provider its probably not an issue, but for the > generic purpose fips token, this might be useful to have answers for. I > think this is mostly covered in the following issue and likely applies to > kryoptic itself too: > > https://github.com/latchset/kryoptic/issues/319 Although we build all of openssl we only embed libfips.a which is the fips module core, there is no libcrypto, base provider or tls code, no support to load openssl configs, etc... so the crypto-polcies do not apply. The real openssl will apply the proper policies when loading this fips provider as customary. When NSS will decide to use this module for FIPS support the NSS policy will also apply and so forth. > > make > > the automated service complains that we should build in parallel: [!]: Uses > parallel make %{?_smp_mflags} macro. From what I see, OpenSSL does that so I > would take an inspiration there: > > https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/openssl.spec#_257 ok, this is a remnant of issues we had in the past with parallel builds, so I think I can follow that example. > > %define osslver 4.0.0-beta1 > > Please, try to use global per packaging guidelines where possible: > > [ ]: Spec use %global instead of %define unless justified. > Note: %define requiring justification: %define autorelease(e:s:pb:n) > %{?-p:0.}%{lua:, %define osslver 4.0.0-beta1, %define srpmhash() > %{lua:, %define __spec_install_post > %{?__debug_package:%{__debug_install_post}} %{__arch_install_post} > %{__os_install_post} pushd openssl-%{osslver} %{SOURCE4} > $RPM_BUILD_ROOT/%{_libdir}/ossl-modules/fips.so %{nil} ok > > > mkdir -p -m755 $RPM_BUILD_ROOT%{_libdir}/ossl-modules > > ... > > mkdir -p -m755 $RPM_BUILD_ROOT%{_libdir}/pkcs11 > > [ ]: Package must own all directories that it creates. > Note: Directories without known owners: /usr/lib64/pkcs11, > /usr/lib64/ossl-modules > > I think these should be just created as root explicitly. Likely with > something like: > > %attr(0755,root,root) %{_libdir}/pkcs11 > %attr(0755,root,root) %{_libdir}/ossl-modules ok
Created attachment 2136472 [details] Current spec file Uploading current fixed spec file as an attachment to this bug
Rebuilt SRPM: https://download.copr.fedorainfracloud.org/results/simo/fips-provider/srpm-builds/10309483/fips-provider-1.5.0-3.fc45.src.rpm
Created attachment 2136473 [details] The .spec file difference from Copr build 10304088 to 10309542
Copr build: https://copr.fedorainfracloud.org/coprs/build/10309542 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2456554-fips-provider/fedora-rawhide-x86_64/10309542-fips-provider/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
> [ ]: Package must own all directories that it creates. > Note: Directories without known owners: /usr/lib64/pkcs11, > /usr/lib64/ossl-modules Not yet resolved. The following should go to the `%files` section: > %attr(0755,root,root) %{_libdir}/pkcs11 > %attr(0755,root,root) %{_libdir}/ossl-modules > [ ]: Sources are verified with gpgverify first in %prep if upstream > publishes signatures. > Note: Sources 4 and 3 are not passed to gpgverify. Any reason why the OpenSSL tarball signatures are not checked here? And any reason why its not done on the OpenSSL rpm given that I already checked that and noticed? For the BuildRequires, I would prefer the space separation rather than the commas, but its not a big deal > fips-provider.x86_64: W: no-documentation Currently the spec file has description and summary, but no installed manual pages. Given that this is really not meant to be interacted with by users, I think its ok. But we need to make sure the documentation on fips-mode-setup or somewhere is up to date. > Uploading current fixed spec file as an attachment to this bug The automation needs the "Spec URL: " in the comment to kick in. The review template has few items that say justification would be helpful for "unversioned .so files" and few more so some comments around these might come handy: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2456554-fips-provider/fedora-rawhide-x86_64/10309542-fips-provider/fedora-review/review.txt With the above fixed, it looks good to me. I can ack it for you according to the package review process or if you prefer another pair of eyes to have a look through that, please invite them in. https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/ I double-checked the bundling requirements and did not find any specific process or ticket to open so I believe we are ok.
(In reply to Jakub Jelen from comment #8) > > [ ]: Package must own all directories that it creates. > > Note: Directories without known owners: /usr/lib64/pkcs11, > > /usr/lib64/ossl-modules > > Not yet resolved. The following should go to the `%files` section: > > > %attr(0755,root,root) %{_libdir}/pkcs11 > > %attr(0755,root,root) %{_libdir}/ossl-modules I tried this but I cannot seem to create a %files section because the cargo macros already do it. Besides this module doesn't won those directories. > > > > [ ]: Sources are verified with gpgverify first in %prep if upstream > > publishes signatures. > > Note: Sources 4 and 3 are not passed to gpgverify. > > Any reason why the OpenSSL tarball signatures are not checked here? And any > reason why its not done on the OpenSSL rpm given that I already checked that > and noticed? No idea, I guess it is because historically we were shipping hobbled tarballs. > For the BuildRequires, I would prefer the space separation rather than the > commas, but its not a big deal > > > fips-provider.x86_64: W: no-documentation > > Currently the spec file has description and summary, but no installed manual > pages. Given that this is really not meant to be interacted with by users, I > think its ok. But we need to make sure the documentation on fips-mode-setup > or somewhere is up to date. This is just a module and has no manpages whatsoever indeed. It needs to be handled in the openssl main package. > > Uploading current fixed spec file as an attachment to this bug > > The automation needs the "Spec URL: " in the comment to kick in. > > The review template has few items that say justification would be helpful > for "unversioned .so files" and few more so some comments around these might > come handy: > > https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora- > review-2456554-fips-provider/fedora-rawhide-x86_64/10309542-fips-provider/ > fedora-review/review.txt CAn you suggest what we should do? I do not even understand why the review tool woul dflag unversioned modeules that are not libraries shipped in the canonical /usr/lib64 directory, to me it just seem a bug in fedora-review. > With the above fixed, it looks good to me. I can ack it for you according to > the package review process or if you prefer another pair of eyes to have a > look through that, please invite them in. > > https://docs.fedoraproject.org/en-US/package-maintainers/ > Package_Review_Process/ > > I double-checked the bundling requirements and did not find any specific > process or ticket to open so I believe we are ok. I will need help to address any of the issues you raise because I see no straightforward fixes here, esp the %files part.
(In reply to Simo Sorce from comment #9) > (In reply to Jakub Jelen from comment #8) > > > [ ]: Package must own all directories that it creates. > > > Note: Directories without known owners: /usr/lib64/pkcs11, > > > /usr/lib64/ossl-modules > > > > Not yet resolved. The following should go to the `%files` section: > > > > > %attr(0755,root,root) %{_libdir}/pkcs11 > > > %attr(0755,root,root) %{_libdir}/ossl-modules > > I tried this but I cannot seem to create a %files section because the cargo > macros already do it. > Besides this module doesn't won those directories. Nevermind I somehow did not realize I had a %files section above ... will fix this. > > > Uploading current fixed spec file as an attachment to this bug > > > > The automation needs the "Spec URL: " in the comment to kick in. > > > > The review template has few items that say justification would be helpful > > for "unversioned .so files" and few more so some comments around these might > > come handy: > > > > https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora- > > review-2456554-fips-provider/fedora-rawhide-x86_64/10309542-fips-provider/ > > fedora-review/review.txt Adding a comment for this
New SRPM: https://download.copr.fedorainfracloud.org/results/simo/fips-provider/srpm-builds/10309483/fips-provider-1.5.0-3.fc45.src.rpm
Spec URL: https://download.copr.fedorainfracloud.org/results/simo/fips-provider/fedora-rawhide-aarch64/10325498-fips-provider/fips-provider.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/simo/fips-provider/srpm-builds/10325498/fips-provider-1.5.0-4.fc45.src.rpm
Created attachment 2137146 [details] The .spec file difference from Copr build 10326549 to 10326557
Copr build: https://copr.fedorainfracloud.org/coprs/build/10326557 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2456554-fips-provider/fedora-rawhide-x86_64/10326557-fips-provider/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Created attachment 2137147 [details] The .spec file difference from Copr build 10326549 to 10326557
Copr build: https://copr.fedorainfracloud.org/coprs/build/10326549 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2456554-fips-provider/fedora-rawhide-x86_64/10326549-fips-provider/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
I would still prefer to check signature on the openssl sources, but otherwise lgtm Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== C/C++: [X]: Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files in private %_libdir subdirectory (see attachment). Verify they are not in ld path. Generic: [X]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. Note: Using prebuilt packages [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: "Unknown or generated", "*No copyright* Apache License 2.0", "*No copyright* GNU General Public License, Version 3", "*No copyright* Public domain". 251 files have unknown license. Detailed output of licensecheck in /var/lib/copr-rpmbuild/results/fips- provider/licensecheck.txt [X]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [X]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib64/pkcs11, /usr/lib64/ossl-modules [X]: %build honors applicable compiler flags or justifies otherwise. [X]: Package contains no bundled libraries or specifies bundled libraries with Provides: bundled(<libname>) if unbundling is not possible. [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. [X]: Package obeys FHS, except libexecdir and /usr/target. [-]: 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]: Useful -debuginfo package or justification otherwise. [X]: Package is not known to require an ExcludeArch tag. [X]: Package complies to the Packaging Guidelines [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]: The License field must be a valid SPDX expression. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [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: [X]: Reviewer should test that the package builds in mock. [X]: Sources can be downloaded from URI in Source: tag Note: Could not download Source2: https://people.redhat.com/~ssorce/simo_redhat.asc See: https://docs.fedoraproject.org/en-US/packaging- guidelines/SourceURL/ [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [X]: 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. [-]: Patches link to upstream bugs/comments/lists or are otherwise justified. [X]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: Sources 4 and 3 are not passed to gpgverify. [X]: Package should compile and build into binary rpms on all supported architectures. [X]: %check is present and all tests pass. [X]: Packages should try to preserve timestamps of original installed files. [X]: Spec use %global instead of %define unless justified. Note: %define requiring justification: %define autorelease(e:s:pb:n) %{?-p:0.}%{lua:, %define __spec_install_post %{?__debug_package:%{__debug_install_post}} %{__arch_install_post} %{__os_install_post} pushd openssl-%{osslver} %{SOURCE4} $RPM_BUILD_ROOT/%{_libdir}/ossl-modules/fips.so %{nil} [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]: Uses parallel make %{?_smp_mflags} macro. [x]: SourceX is a working URL. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [x]: Large data in /usr/share should live in a noarch subpackage if package is arched.
The Pagure repository was created at https://src.fedoraproject.org/rpms/fips-provider