commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
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:
>>>>> <;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 
>> 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,

> 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:
For additional commands, e-mail:

View raw message