On Thu, Jan 24, 2008 at 12:24:11PM -0600, Michael Wolf wrote:

...

when building locally with osc, I just ran into this:

The following package could not be verified: /var/cache/osbuild/Apache/SLE_10/i586/libGeoIP-devel-1.4.4-1.1.i586.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#09ca02b0)

What's the plan to handle this?

The attached patch is the workaround I'm using for now. Not ideal, but better than being unable to get anything done at all.

Thanks for the patch. I just committed something along these lines to svn. I'll also roll a new package, to increase availability of the fix...! Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Thu, Jan 24, 2008 at 08:22:05PM +0100, Marcus Rueckert wrote:

On 2008-01-24 18:38:36 +0100, Dr. Peter Poeml wrote:

...

when building locally with osc, I just ran into this:

The following package could not be verified: /var/cache/osbuild/Apache/SLE_10/i586/libGeoIP-devel-1.4.4-1.1.i586.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#09ca02b0)

What's the plan to handle this?

micha wants to fix that bug and will retrigger all broken packages.

Clarification of the bug: libGeoIP-devel is in the Apache repo because of an aggregate. The current aggregate code doesn't re-sign the packages. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Friday 25 January 2008 12:30:17 wrote Dr. Peter Poeml:

On Fri, Jan 25, 2008 at 12:09:54PM +0100, Michael Schroeder wrote:

...

On Thu, Jan 24, 2008 at 08:22:05PM +0100, Marcus Rueckert wrote:

...

On 2008-01-24 18:38:36 +0100, Dr. Peter Poeml wrote:

...

when building locally with osc, I just ran into this:

The following package could not be verified:

/var/cache/osbuild/Apache/SLE_10/i586/libGeoIP-devel-1.4.4-1.1.i586.r pm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#09ca02b0)

What's the plan to handle this?

micha wants to fix that bug and will retrigger all broken packages.

Clarification of the bug: libGeoIP-devel is in the Apache repo because of an aggregate. The current aggregate code doesn't re-sign the packages.

Yes, I found the reason when I was awake this morning, by thinking :-)

Is there an ETA when this is going to be fixed? I depend on it, because I intented to work on the redirector this week... for which I need a functional Apache and Apache:Modules project.

actually, I am not that sure that this should be changed. How should an external see that this package was not build by this certain project/person ? -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

...

...

On 25-01-2008 at 13:49, Adrian Schröter wrote: actually, I am not that sure that this should be changed.

How should an external see that this package was not build by this certain project/person ?

Well, there we anyhow come to a critical point: a Project get's a new person for one package. There is close to no background check performed on such a person, access is granted withing few minutes after asking on the ML (I know it... I was actually surprised myself how easy I got access to repos like {GNOME|KDE}:Community. Sure, the packagers are the one we need to grow, but how can an end user now 'trust' such a constellation of packages? With aggregates, the problem is that several packages within one repo are signed with a key different from the one specified in the repo. Does the end user to be aware of this? Or could he just trust the project owner that he aggregated packages which he trust? (indirect trust relationship). Dominique -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Friday 25 January 2008 13:28:12 wrote Dirk Stoecker:

On Fri, 25 Jan 2008, Adrian Schröter wrote:

...

...

Is there an ETA when this is going to be fixed? I depend on it, because I intented to work on the redirector this week... for which I need a functional Apache and Apache:Modules project.

actually, I am not that sure that this should be changed.

How should an external see that this package was not build by this certain project/person ?

There is no difference between _link and _aggregate in this respect. Both rely on the source to be valid. The only difference is that the for _aggregate you theoretically need to check a whole repository (e.g. a modified build tool can introduce malware), whereas for _link only one package needs to be checked. But the trustlevel is the same.

right ... therefore the trust system will need to checked all these deps in future... -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tue, Jan 29, 2008 at 08:56:15PM +0100, Michael Schroeder wrote:

On Fri, Jan 25, 2008 at 12:30:17PM +0100, Dr. Peter Poeml wrote:

...

Yes, I found the reason when I was awake this morning, by thinking :-)

Is there an ETA when this is going to be fixed? I depend on it, because I intented to work on the redirector this week... for which I need a functional Apache and Apache:Modules project.

Re-signing is now implemented.

Cool! Thanks, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development