On Freitag, 17. April 2020, 18:52:56 CEST wrote cunix:
reply to Adrian Schröter:
On Donnerstag, 16. April 2020, 22:01:43 CEST wrote cunix:
reply to Adrian Schröter:
On Dienstag, 14. April 2020, 16:24:20 CEST wrote Neal Gompa:
On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert: > On 4/11/20 5:41 AM, Simon Lees wrote: >> On 4/11/20 9:20 AM, cunix wrote:
[...] We can just resign packages without rebuilding them.
we could do that, but I do not see the point acutally.
1) resigning makes security always weaker because it does not happen in the origin anymore.
Does this apply for "adding" (not "replacing") a signature as well?
No, but IIRC rpm format and/or our tooling is supporting only a single key atm (not checked).
Therefore I would propose to wait with shipping a Jump-like approach officially to openSUSE Leap, until the tools are able to work with multiple keys/signatures.
AFAIK, it would be an incompatible change in rpm's binary format. So nothing what I hope for soon. 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).
Of course this should not stop anyone from setting up and testing Jump already now.
And nothing else is what we do atm :)
Perhaps better solutions are found on the way or other issues occur that might stop this idea - so current tools and their features don't have to be extended.
In any case it would modify the rpm, so the file would not have the same checksum anymore. That makes it harder to compare.
That is probably correct.
Perhaps the second (openSUSE) signature can be "back ported" to the SLE binaries making them bitwise identical again?
Or the tools used should not rely on the hash of the whole rpm but on the pieces of the rpm that are actually signed?
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? ...
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. However, it should be much more easy to adapt this functionality since it does not involve a new rpm binary format.
Choosing the later, systems under my control would accept any binary with a SLE signature, probably not limited to the official openSUSE Leap repositories, although I'm using and trusting openSUSE, not necessarily SLE.
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).
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.
So, I see no feature to go away, but we keep the transparence and the original package.
The second signature would in my opinion keep and improve the transparency.
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.
So making the security weaker and dealing with the same files twice with different signatures is not giving any advantage from my POV.
I would argue, from an openSUSE Leap user's perspective, security is only kept at its current level, if a signature from a nowadays trusted (openSUSE) key is included and this signing authority has verified it would have created the same binary (without SUSE signature) before adding its own signature.
From my POV is that a Leap user anyway needs to trust SUSE and openSUSE atm. Because the sources are submitted directly.
This seems to be a point where we are not completely on the same page, perhaps because you're looking from the inside while I do not have the same insight and have always to take into consideration that I'm not getting the whole picture because knowledge about some shady corners is not publicly shared.
As said previously, this might not be rational and I really don't want to accuse anybody of any wrong doing and this is nothing personal.
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.
Therefore I do trust the binaries build by obs based on sources coming from SLE, because obs is sufficiently open for me to look into the build process. I can't say the same for the internal SUSE build setup.
well, it is the same technology, just a different instance. So the build should be (has to) reproducible.
Consequently I would prefer if obs verifies the binaries build for SLE are indeed those that obs would have produced (before publishing).
The fact that this verification was successful should be expressed by adding the (second) openSUSE signature.
I will setup another project in the next days to try to rebuild the SUSE:SLE-15:GA project in build.opensuse.org. So we have maybe a starting point of the discussion how to verify. 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... ...
Please don't think I'm fundamentally against your idea to implement something like Jump. I do see some benefits, but want to raise at an early stage awareness of things/users/trust that might get lost and propose ways how your idea might be improved.
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 :) -- 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