commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Git question (Was: [VOTE][RC3] Release ...)
Date Wed, 24 Dec 2014 15:11:16 GMT
On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote:
> Le 24/12/2014 15:04, Gilles a écrit :
>> On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe wrote:
>>> Le 24/12/2014 03:36, Gilles a écrit :
>>>> On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote:
>>>>> This is a [VOTE] for releasing Apache Commons Math 3.4 from 
>>>>> release
>>>>> candidate 3.
>>>>>
>>>>> Tag name:
>>>>>   MATH_3_4_RC3 (signature can be checked from git using 'git tag 
>>>>> -v')
>>>>>
>>>>> Tag URL:
>>>>>
>>>>>
>>>>>
>>>>> 
>>>>> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34>
>>>>>
>>>>>
>>>>
>>>> Is there a way to check that the source code referred to above
>>>> was the one used to create the JAR of the ".class" files.
>>>> [Out of curiosity, not suspicion, of course...]
>>>
>>> Yes, you can look at the end of the META-INF/MANIFEST.MS file 
>>> embedded
>>> in the jar. The second-to-last entry is called 
>>> Implementation-Build. It
>>> is automatically created by maven-jgit-buildnumber-plugin and 
>>> contains
>>> the SHA1 identifier of the last commit used for the build. Here, is 
>>> is
>>> befd8ebd96b8ef5a06b59dccb22bd55064e31c34, so we can check it really
>>> corresponds to the expected status of the git repository.
>>>
>>
>> Can this be considered "secure", i.e. can't this entry in the 
>> MANIFEST
>> file be modified to be the checksum of the repository but with the 
>> .class
>> files being substitued with those coming from another compilation?
>
> Modifying anything in the jar (either this entry within the manifest 
> or
> any class) will modify the jar signature. So as long as people do 
> check
> the global MD5, SHA1 or gpg signature we provide with our build, they
> are safe to assume the artifacts are Apache artifacts.
>
> This is not different from how releases are done with subversion as 
> the
> source code control system, or even in C or C++ as the language. At 
> one
> time, the release manager does perform a compilation and the fellow
> reviewers check the result. There is no fullproof process here, as
> always when security is involved. Even using an automated build and
> automatic signing on an Apache server would involve trust (i.e. one
> should assume that the server has not been tampered with, that the 
> build
> process really does what it is expected to do, that the artifacts put 
> to
> review are really the one created by the automatic process ...).
>
> Another point is that what we officially release is the source, which
> can be reviewed by external users. The binary parts are merely a
> convenience.

That's an interesting point to come back to since it looks like the
most time-consuming part of a release is not related to the sources!

Isn't it conceivable that a release could just be a commit identifier
and a checksum of the repository?

If the binaries are a just a convenience, why put so much effort in it?
As a convenience, the artefacts could be produced after the release,
accompanied with all the "caveat" notes which you mentioned.

That would certainly increase the release rate.

Best regards,
Gilles

> We do our best to ensure they are genuine and we do apply
> signatures to them too, but people who do not trust them should use 
> the
> source, audit them, and then compile them on their own (assuming they
> also trust their compiler, their OS ...).
>
> best regards,
> Luc
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message