reply to Adrian Schröter:
On Freitag, 17. April 2020, 18:52:56 CEST wrote cunix: [...] AFAIK, it would be an incompatible change in rpm's binary format. So nothing what I hope for soon.
If rpm upstream thinks about implementing something similar it should hopefully be usable downstream. Having this done "soon" in rpm and other software that has to be adapted might be a challenge, indeed.
However, we could of course also find an indepdend way of signing it detached. Means into another file. (but on the other hand this more or less the same as the openSUSE signed rpm-md data).
see below [...]
I think we should first come to a conclusion what this second signature should tell in first place. And if we can not achieve it in a different way.
So, it basically means that openSUSE approved this particular SLE package for usage with an official openSUSE distribution.
Right?
Literally speaking, IMHO, it should tell: "I'm the build service of the openSUSE project and do have access to the private part of the openSUSE signing key. I received sources and binaries from some another entity, rebuild this package and hereby guarantee that my build result was the exact same as is included in this rpm file. This I do promise by adding my signature."
What we will do in current setup is basically to import both gpg keys, SLE and openSUSE by default as trusted keys.
That was my fear and is the point I'd like to see prevented somehow.
Otherwise Leap would only be usable for those not turning "pkg_gpgcheck" on or accepting the SLE key as trusted.
I am not sure if that really breaks this option, since it would be still be a trusted key imported into rpm database.
But this is exactly what in my opinion should be avoided: There should be no need to import the SLE key into rpmdb for Leap users. And it should especially not be done by default. Of course users might choose to opt-in explicitly, for example those wanting to switch to SLE. But others should in my opinion be able to enable "pkg_gpgcheck" and/or continue using Leap without having to install or trust the SLE key.
However, it should be much more easy to adapt this functionality since it does not involve a new rpm binary format.
[...]
In my opinion openSUSE should only include package signing keys trusted by default that are under full control of openSUSE.
okay, so it would be an option to have method to accept the SLE signed package only if it is signed by meta data signed by openSUSE?
Would that be a solution?
That should be solvable in zypp tooling IMHO (not checked with zypp developers).
Me talked about something similar in a messages in this thread (as option 5.c), but we were both of the opinion that this increases complexity and is at best a fallback option. Nevertheless, in my opinion slightly better than having to trust the SLE key. Using a solution implemented inside rpm has in my opinion several advantages. For example currently doing rpm -Vvv installedPackage seems to verify that the rpm header is correctly signed and shows via keyID by whom. If we are able to keep the SLE key outside of Leap systems by some kind of zypp workaround but the rpm package still has only a SLE signature, the above rpm command might not be able to verify the installed package (headers) because it has not the SLE public key in the db and is not aware of some detached signature it should consult. This reveals some kind of trust gap between zypper and rpm because the former accepted installation while the later can't verify the installed package. This is not ideal. Thus, in my opinion, a solution where both signatures are available but Leap users can solely rely on the signature coming from openSUSE and completely ignore the additional (first) SUSE signature seems to be more robust. Users switching to SLE can do the opposite (trust SLE and ignore openSUSE) without reinstall.
openSUSE Leap should only ask its users to fully trust a key, that openSUSE (and only openSUSE) can create/revoke/regenerate/access/use for signing etc. without relying on a third party that might follow different rules and is not governed by openSUSE.
What would be the answer if some other entity asks openSUSE to include and trust its packaging keys in Leap by default in order to create a better user experience when installing binaries from this entity?
I don't know. Depends on the entity and the reason. But this other entity is not providing already the core content of the distro, so I am not sure if that is a good analogy.
Yes, sorry. Question was a little bit nasty. In my opinion the answer should always be a clear and unconditional "No", unless openSUSE can control this key in the same way as her own. Thinking about packman, a project somehow closely related to openSUSE, their signing key is not trusted by default in Leap (perhaps I'm wrong here?), or? [...]
Having to trust either the SLE key, turn off pkg_gpgcheck or stop using Leap is in my view sort of a regression.
k, I can follow you here. But maybe this can be solved by my proposal to require the openSUSE key in addition for the metadata.
As said above, might be possible but solving this inside rpm is perhaps a better choice. [...]
Hopefully you understand the saying "Trust is good, control is better."
Yes, and therefore we agreed that the option of reproducibility is a hard requirement.
Do you already have an idea how this requirement will be enforced? Will obs rebuild each package sources coming from SLE and only publish the binary rpm for Leap if the build was successful and identical? Or is this more some kind of policy, meaning the binary is published and shipped to Leap anyway, but interested users are encouraged to rebuild and if they can't reproduce the package, bugs should be filed? [...]
But given the rpm format limitation I see the second signature inside of the rpm critical. We could think about to sign something detached though...
I do understand your concerns. As said above, a detached- or meta signature will solve some problems, but not all and might introduce some new. If this route is followed by investing work in supporting such detach- or meta signatures but it is later realized that this produces some new issues, there might be an incentive to get done by again picking the "quick" solution and just require Leap users to trust the SLE key by default. Therefore, it is in my opinion a "cleaner" solution to go the hard way from the beginning, try to tackle the issue at the root (in the rpm) so that nothing "trust" related has to be changed for Leap users and they are treated equally compared to those using Tumbleweed. [...]
yes, thank you. And please do not think we know already how to implement it. There are many open questions indeed and the failure of the project is still an option :)
Thank you for being open to a discussion about your idea! Hopefully not having solved all issues until 15.3 release is not considered as a failure and there is enough flexibility to start shipping something jumping officially with a later version of Leap in case the tooling is not ready at 15.3 release time. cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org