reply to Adrian Schröter:
On Samstag, 11. April 2020, 19:50:48 CEST wrote cunix:
reply to Lubos Kocman:
On Sat, 2020-04-11 at 01:50 +0200, cunix wrote: [...] If build power is not the problem, what about the following approach.
It is not the problem.
Packages that should be shared by SLE and Leap are
1. build on internal SUSE build service and signed by SUSE.
2. Sources are submitted from SLE to obs together with hash of SLE build binaries without the signature.
3. obs builds with these new sources.
4. obs compares the hash of the binary it has just build with the one provided from SLE.
5.a. If hashes don't match, obs adds openSUSE signature to its own build result as the only signature and releases it for openSUSE.
OR
5.b. If hashes match, obs adds openSUSE signature to SLE binaries and releases for openSUSE. This is what you don't want to do because it breaks certification?
I do not see what we win with this. I agree that validation of the internal build packages has a value. But why changing the signature?
My hope was that "changing" signature is not the same as replacing it, but adding a second one from openSUSE to the existing SUSE signature. That is currently not possible?: https://github.com/rpm-software-management/rpm/pull/1050 The "win" should have been that Leap users are not required to accept and trust the SUSE signing key. This is necessary with Jump?
My current idea is to keep the vendor of SLE packages as SLE. It makes it hopefully easier and more transparent to the user to see where the origin of a package is. IMHO this is a plus instead of hiding this information again.
I didn't want to hide it and hoped user or system can detect it by checking if rpm has one (openSUSE) or two (openSUSE and SUSE) signatures.
OR
5.c. If hashes match, obs releases SLE binaries for openSUSE.
Perhaps, in case of 5.c., it might be possible for obs to append some openSUSE signed notice to a meta package confirming the SLE binaries are reproducible on obs.
It is definitive a must that the build is reproducible....
Very good.
Would be nice if zypper will be able to query this meta package and can be configured to only accept SLE binaries if meta package includes attestation of build reproducibility.
... but I do not like the extra complexity of doing this with additional meta data and per package.
I didn't like it either but would prefer it compared to a situation where Leap users can only rely on a non openSUSE signature. [...]
This way it is the task of the SLE maintainers (with help of openSUSE colleagues) to bring both build setups in line and produce identical results, while openSUSE users can be sure they get binaries that are at least possible to generate with the sources submitted to openSUSE.
I like to raise the point that having the build in build.opensuse.org repeated is maybe not enough. If you do not trust the admins of SUSE's internal OBS, you can not really trust (me for example;) the admin of build.opensuse.org. (and I do not take this in any way personal)
You are probably right and of course this is nothing personal. Currently every openSUSE user has to trust at least the openSUSE key. Asking all Leap users to additionally trust a (really sorry: "third party") SUSE key might be too much. For you guys inside SUSE this is probably hard to follow and it might not be very rational: From the outside these special SLE things are hard to understand and when reading about non disclosure agreements, certifications and special partner handling there might be some sentiment of seeing this as a little black box some users are not able to grant the same level of trust as for obs.
So it would be indeed the best if the rebuild validation of SLE and(!) openSUSE packages would happen at a complete independend instance.
Agree. At least on my side build power would be kind of a problem ;)
Or you may rebuild specific packages using "osc build --vm-type=kvm" and validate the result.
You could adapt build-compare for automation of the compare, just let it fail in case of difference in "your" instance.
I am happy to help with such a setup though.
Thanks. Out of convenience I would prefer not having to think about having to do something similar before installing SLE/SUSE signed packages because they are additionally signed by an openSUSE key that is already trusted.
happy easter again! adrian
Happy Easter, cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org