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. Of course this should not stop anyone from setting up and testing Jump already now. 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?
So, I like to avoid this...
That I do really understand, especially if you are one of the main persons who has/wants to implement this while I'm currently only adding comments from the sideline. Nevertheless I hope you see addressing some of my concerns as a chance to keep trustworthiness and accountability at least at the same level we are enjoying today.
2) the package signing is not very important in practice. zypp stack is verifing signature of the repository meta data and also the %_vendor of the rpms. But the package signature itself is not verified (only indirectly via the hash sum of the entire file).
Setting "pkg_gpgcheck=1" [1] in a repo file, I would expect zypper not to install a package that is only (rpm) signed by a not trusted key.
okay, if you enable that it may check rpm signatures in addition. Not our default though.
This should work with the rpm directly [2], no?
And of course my hope is this feature won't get lost.
It should not.
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. 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. 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?
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.
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." 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. 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. If this can be only discovered some time after publishing by someone who tries to reproduce the build, gets different results and might have no clue for the reason because of lacking insight into the SUSE internal build config/service, this in in my view too late and not really effective.
Using two keys and the binaries is making this just more visible to the user.
What I see as a good thing in regard to transparency.
Can you follow me here?
I do understand you and might have a similar view if I would find myself in the position having to implement this. It is one possibility to add the SLE signing key. Having to adapt the complete tool chain is way more complicated and probably not achievable in the time frame that was communicated. Nevertheless "trust" is a touchy thing and granting it by default to an entity that is not controlled by openSUSE should in my opinion not be done if other ways are possible, although more complicated. 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.
bye adrian
bye cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org