From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hartmut Goebel Subject: Trust and reproducible build (was: Help needed from Java developer to finish maven) Date: Mon, 24 Apr 2017 15:36:10 +0200 Message-ID: <58FDFF4A.2000000@crazy-compilers.com> References: <58F9E310.4070201@crazy-compilers.com> <22f7c69e-da5c-6652-ecc4-13b97e83506b@crazy-compilers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2eA5-0004Dq-PY for guix-devel@gnu.org; Mon, 24 Apr 2017 09:36:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2eA2-0007tj-HE for guix-devel@gnu.org; Mon, 24 Apr 2017 09:36:17 -0400 Received: from mail-out.m-online.net ([2001:a60:0:28:0:1:25:1]:46820) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d2eA2-0007tQ-7h for guix-devel@gnu.org; Mon, 24 Apr 2017 09:36:14 -0400 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Hilco Wijbenga Cc: guix-devel Am 24.04.2017 um 03:20 schrieb Hilco Wijbenga: > First, if it's about trust ("am I really running a stock, > unmanipulated Maven") then there are the checksums and signatures on > the download page which exist for exactly that purpose. While signatures are very useful in many cases, in this case they are not. A signature on a JAR file only proofs that the JAR file was build by some person or organization. It does not proof that the content of the JAR file is exactly what was produced when compiling the source. > If you feel > you cannot rely on those then why trust the SCM that holds the Maven > code?=20 The source can be reviews, the JAR-file content not. (One could disassemble and reverse engineer it, but for this you need to trust another tool: the disassembler. And then you still have to review the cod= e.) > Second, as an end user this makes it even harder to trust the end > result. I now have to trust both the Maven devs *and* the Guix devs > who worked on the packages. Now this is where reproducible build steps in: You don't need to trust the guix developers. Package descriptions are quite easy to review for code manipulations (even ugly and long ones like the one for java and the one for maven). So you can get the maven source-code from some different source, easily verify the one you have is unchanged and build it. And you will get the same checksums as anybody else building maven via guix (on the same platform an guix version). Yes, you still have to trust the guix developers to use a valif version of the C-compiler (and a few other tools), but this is *much* less to trust compared a other operation system distributions (Redhat, Fedora, Debian, Windows, OS X, Solaris), where you have no chance to verify the code. > (By the way, I run Gentoo GNU/Linux so I am very familiar with > building from source. For me (and Gentoo) it's more about control and > performance than anything else, though.) Soi your aim is different than Guix's aim :-) > But, still, building such a JAR from source (once Maven is > available) takes little effort and so is worth it. You are absolutely right. But "once Maven is available" is the key to all of this. > :-) Well, no, of course not. Maven isn't at the pre alpha state > anymore. So in the spirit of "eat your own dogfood", Maven builds with > Maven.=20 Umm, well,, .... It would help a lot if there would be some "minimal maven" which could be used for bootstrapping. But even a "minimal Maven" need tons of other packages > Right, that makes perfect sense except for the part where you jump > through hoops and make unexpected changes to Maven just to be able to > build it in a highly unorthodox way. ;-) :-) Be ensured that I have no plan at all to change maven. in any way. I'm not going to make changes to Maven. I simply try bootstrapping it from source. If there would be some "official" way, I would use it. What I'm doing is simply adption the build.xml in guix. (Hmm, thinking on this, maybe I can trip down my description to manipulate the build.xml. But I don't think this is of much use since I most probably could only reuse two simple tasks.) Please keep in mind that Maven is not a compiler. its just a build tool. So its easy to compare the build results from the guix package description with whatever Maven builds when it is bootstrapping itself. And I'm confident that as soon as I make maven to bootstrap itself from source, it will be correct. > According to msg00536 you patched Maven to use different JARs and > versions. Obviously, that creates a problem so don't do that. Stick > with the JARs/versions that Maven was built with and all will be well. Please try to reproduce what I've done. The error message I posted is in now way related to any version change, since when using the tar-ball I could change the version and still bootstrap maven.As opposed to the guix description, where maven fails to run quite early. > But you would be much better off if you dropped this whole approach as > I mentioned above. Even if you somehow made it work, it would be > unreliable. It would be much better if you'd help finding the cause of the error message instead of spending time arguing about the way :-) No offence meant, but adding precompiled JARS from maven central is not an option. --=20 Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |