mock fails to build Leap 15.4 buildroot on Fedora 38 #1062
Comments
|
Somewhat related, I think: https://bugzilla.redhat.com/show_bug.cgi?id=2192374 FWIW. |
praiskup
added
configs
|
|
@praiskup Yep. rpm-software-management/rpm-sequoia#46. I was told elsewhere that I need to stay on F37 if I want to build Leap 15.4 packages with |
|
So do we want to |
That seems pretty dangerous. How do we know we are not getting malware infected RPMs which could infect the RPMs we are asking mock to build? Is it even clear that this is a problem with SUSE's keys or is that rpm-sequoia is not allowing for a perfectly valid GPG signing use-case? |
Yes, but keeping the chroots broken is not good for CI systems.
hmmm, I did not understand it this way actually :-) but anyway... Any other way than rollback to F37 in Fedora Copr (pretty much a non-option really)? |
Completely agreed. Our CI system broke when this rolled out and we had to scramble to fix it.
Not other than rpm-sequoia getting fixed AFAIU. I can't say I know GPG intricately enough to know for sure, but rpm-software-management/rpm-sequoia#47 says it fixes rpm-software-management/rpm-sequoia#46. It just doesn't seem to be going anywhere and I was told I was being "too demanding" asking if this whole mess could get resolved so I stopped pursuing it. I was also told that I just need to be satisfied with Fedora 37 as a mock build platform until this whole mess is fixed. I just hope that happens before F37 becomes EOL and unsupported. So, no. I know of no other way to fix this other than to stick with F37. But I also think it's a pretty serious issue/change to just stop checking RPM signatures in a public CI system that people would otherwise believe to be securely checking RPMs being used in it. It changes the entire trust model of software built in COPR. Well, I guess limited to Leap 15.4 builds. But still, it's pretty serious to change the trust model of even just one platform so that people building for that platform don't really know that the trust model has been compromised/weakened. I do wonder how many other distributions this issue affects -- distributions that are managing their keys such as SUSE does. I wouldn't have the foggiest as we only build for RH/EL clones and SUSE distros. But given the number of RPM based distros out there, I would have to imagine that some others are affected. Or is SUSE seriously the only single outlier in how they are managing their package signing keys? Might be interesting if somebody created a simple hello world RPM building project and built it on every supported distro on COPR and see which ones break. |
|
One way around this is to use the bootstrap image feature: |
|
Also see the #1101 proposal. |
|
Bootstrap image feature was enabled in Fedora Copr for openSUSE Leap 15.3 and 15.4. Tested. |
|
This is resolved. Leap 15.4 and 15.5 seem to install and build fine with Mock 5.5 on Fedora. |
Short description of the problem
When trying something even as simple as
mock -r opensuse-leap-15.4-x86_64 --chroot idthe buildroot fails to build.Output of
rpm -q mockSteps to reproduce issue
podman run --privileged --rm -it fedora:38(or whatever else means you want to utilize to be on Fedora 38)dnf -y install mockmock -r opensuse-leap-15.4-x86_64 --chroot idDo not forget to mention full commandline with the mock command you executed.
Any additional notes
Output of `mock --debug-config`
This shouldn't really be necessary as the above reproducer is very straightfoward and should reproduce easily. Morever, trying to include this output makes the comment here exceed GitHub's maximum comment size of 65535 bytes. If this info is found to be actually necessary, I can add it in a subsequent comment upon request.
This is no doubt more fallout from F38's update to rpm to use Sequoia, but nonetheless, mock is not working on F38 with Leap 15.4.
I have not been able to suss out thus far what it is about the key for the failed packages that RPM on F38 is unhappy about.
Maybe this is just another case of rpm-software-management/distribution-gpg-keys#91 but I have not been able to confirm that yet. It seems quite involved getting to the bottom of these GPG key issues that are now newly being flagged by RpmSequoia.
The text was updated successfully, but these errors were encountered: