https://bugzilla.redhat.com/show_bug.cgi?id=2456554
Simo Sorce <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|AutomationTriaged | --- Comment #3 from Simo Sorce <[email protected]> --- (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 -- 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=2456554 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202456554%23c3 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
