Trust and reproducible build (was: Help needed from Java developer to finish maven)

[Hartmut Goebel]

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? 

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 code.)

> 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. 

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.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | address@hidden               |
| www.crazy-compilers.com | compilers which you thought are impossible |