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 openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power? It guarantees that openSUSE Leap and SLE will be the platform, as no macro expansion or project config will change these binaries.
Next thing that big goal is also to offer seamless migrations, as rpm NVRA will be the same and you can just swap the branding packages. I've discussed some ideas such as replace signed rpm headers, use more efficient delta and so, but you'd still have different release etc.
What we currently propose which we believe can be achieved in a reasonable timeframe. I'd love to see improvements over next two releases. Both process wise and build-setup wise.
Big concern why people hesitate to look at it is really already mentioned certification. Migrated Leap -> SLE product with mixed binaries would be tricky in this regards, or you'd have to replace thousands of rpms. I suppose this effort would be for a way longer run.
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 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.
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....
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. IMHO the entire repository, which provides the SLE packages either needs to be release or not. The initial GA ftp stream will have the SLE binaries mixed with the Backports and openSUSE add-ons though in my current initial setup. Just the update repos will have them seperated.
Of course this is only a second line of defense and serves only to make SLE binaries more trustworthy for openSUSE users because software releases will always be somehow signed by openSUSE release key, but not necessarily the rpm. If the meta package didn't include the attestation, 5.b. and 5.c. shouldn't have happened in the first place, but 5.a.
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) So it would be indeed the best if the rebuild validation of SLE and(!) openSUSE packages would happen at a complete independend instance. 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. happy easter again! adrian -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org