On Friday, March 14, 2014 08:17:23 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 03:10:27PM -0400, Jason wrote:
Hi Marcus,
On Friday, March 14, 2014 08:02:35 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:35:40PM -0400, Jason wrote:
On Friday, March 14, 2014 07:19:09 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:00:34AM +0200, Uwe Geuder wrote: <snip>
<snip>
It chains like this:
repodata/repomd.xml (signature in repomd.xml.asc)
this contains sha256 signatures of the XML files in repodata/: repodata/*.xml
these contain sha256 signatures of all RPMs and other files.
The RPM signature is usually not involved in this framework.
Thank you for clarifying.
Hope you don't mind me pestering a bit more:)
How easy is it the hypothetical mitm in this case?
It is not really possible I hope.
Lacks reassurance :P
I imagine if the package is different it would fail at digest check anyway so this key issue wouldn't crop up but nevertheless, is it sensible to add the key 'trip point'?
I do not fully understand?
I'm seldomly experiencing sha digest checks (no logging available so fwiw) where zypper stops and asks me what to do (btw, it should fail and not give me options) What I'm saying, this happens _before_ the warning that is the topic of the exchange. (Here I assume lack of my understanding in the process, will get to that later) And what was the question, 'trip point' where _before_ installation zypper won't install the package with non-matching key sig.
Also, since it is served over http, repodata.xml could be injected so digest would pass but not fail at package key check?
Sorry if I'm overbearing, but I'd like to understand why is it acceptable for zypper to process the offending package.
repomd.xml has a detached signature in repomd.xml.asc
This signature is done by a GPG key that is either already in the system or zypper/yast2 will ask you about.
If repomd.xml does not match the repomd.xml.asc signature zypper will put up a big fat warning. If repomd.xml.asc is not present, also a big warning will be printed.
Ok, i think I got it now, thank you. During the query/download process, if anything is modified _between_ me and the server it will put up at least a warning.
The trust concept we currently use does not to include the RPM embedded GPG signatures itself, although they are signed by the same key as repomd.xml usually.
Ciao, Marcus
This actually leaves to possibility of server-side compromise? If attacker signs with his key, or no key, package will be installed? -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org