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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
