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>
Good, I thought I was going crazy over here:)
But, this raises another point:
How is it possible for apper to install packages without key/wrong key? The packages are served over plain http, above shouldn't be acceptable?
Or am I misunderstanding something here, I'd appreciate clarification if possible.
The verification of repositories is done via the YUM metadata.
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.
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?
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. 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 -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org