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