incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <bm...@apache.org>
Subject Re: Fwd: Re: An ASF yum repository?
Date Sat, 25 Feb 2012 00:59:54 GMT
On 02/24/2012 04:44 PM, Henk P. Penning wrote:
> On Fri, 24 Feb 2012, Bruno Mahé wrote:
>
>> Date: Fri, 24 Feb 2012 22:43:15 +0100
>> From: Bruno Mahé <bmahe@apache.org>
>> To: bigtop-dev@incubator.apache.org
>> Cc: Steve Loughran <stevel@apache.org>, Henk P. Penning <penning@uu.nl>
>> Subject: Re: Fwd: Re: An ASF yum repository?
>>
>> Some questions for our dear mentors:
>>
>> * Given that we are targeting a release by end of march, is it ok to let
>> the current convenience artefacts as is but make sure everything will be
>> signed from now on?
>>
>> * The previous convenience packages were not signed but the ones for the
>> coming release will be. That means packages/repositories metadata will
>> contain a signed checksum of the artefacts. Therefore signing files such
>> as
>> incubator/bigtop/bigtop-0.2.0-incubating/repos/ubuntu/pool/contrib/h/hadoop-zookeeper/hadoop-zookeeper_3.3.3.2.orig.tar.gz
>>
>> wouldn't achieve anything but make the checker script happy since no
>> user or package management would knows about such signature required by
>> the checker script. Signing any file to make the checker script happy is
>> absolutely fine if it is used by Apache infra to ensure files integrity,
>> but it has be noted no one but package management systems will look at
>> these tarballs. The only thing looking at these signature will be the
>> checker script. So as part of the release process, is signing these
>> tarball for the checker script a requirement?
>
>   Yes.
>
>   1. Of course "keeping the checker script happy" isn't the real
>      reason, but if that's your motivation : fine.
>
>      The real reason is the rule :
>
>        Every artifact distributed by the Apache Software Foundation
>        should and every new one must be accompanied by one file
>        containing an OpenPGP compatible ASCII armored detached
>        signature and another file containing an MD5 checksum.
>
>      which is motivated here : Why We Sign Releases :
>
>        http://www.apache.org/dev/release-signing.html#motivation
>
>      The checker just tries to verify that the rules are kept.
>

I absolutely agree with the motivation to sign releases.
But I believe there has been a misunderstanding regarding the way
package manager work.
Signed packages contain the signed checksum of the tarball in their
metadata. And a package manager will only look at that metadata.
A package manager will not look at any signed checksum put in the same
directory as the tarballs. It does not even know how to handle them
because it uses another mechanism.

So following stricto-sensu the apache release-signing page will not
improve or achieve any security at all.
Humans do not interact with these files at all.
If somehow the tarball would not match the signed checkesum from the
package metadata, it would be then detected by the package manager.
So a signed package already enables the following:
"users can make sure that what they received has not been modified in
any way, either accidentally via a faulty transmission channel, or
intentionally (with or without malicious intent)"

So again, any signed checksum put in the same directory as the tarball
will only help making the checker script happy, which is absolutely fine
since this enables the Apache infrastructure team to directly check the
integrity of a file without going through the package managers. But
users/package managers won't even know about it.



>   2. The items with "missing sigs" mentioned in the checker page
>      belong to some package repo you publish. It is clear that,
>      according to the rules, these packages must be signed, or
>      removed.
>
>   Regards,
>
>   HPP
>

Sure, since Roman was the release manager I guess he will have to sign
every single file.
I just opened the following ticket:
https://issues.apache.org/jira/browse/BIGTOP-421

Mime
View raw message