On 24 December 2014 at 15:11, Gilles <gil...@harfang.homelinux.org> wrote: > 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.
Binary releases still need to be reviewed to ensure that the correct N & L files are present, and that the archives don't contain material with disallowed licenses. It's not unknown for automated build processes to include files that should not be present. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
