maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Pocock <>
Subject Re: Source code verification/compliance with Maven?
Date Fri, 10 May 2013 11:12:48 GMT
On 10/05/13 12:21, Stephen Connolly wrote:
> On 10 May 2013 10:09, Daniel Pocock <> wrote:
>> On 09/05/13 17:21, Manfred Moser wrote:
>>> Correct. The other thing you want to ensure is your acquisition of the
>>> jar. With Nexus (and other repo managers probably) you can connect to the
>>> https secured version of Central and enforce checksum verification so you
>>> can be sure that any component you get into the repo manager is the same
>>> as upstream.
>> Authenticity of the binary is just one element in the big picture
>> though.  The requirement I have involves various factors, some of which
>> appear to be addressed by CLM.
>> - some plugin that is essential to the build process is only available
>> in binary format.  The developer has put a time restriction on the
>> binary (e.g. it stops working in 2014) as they plan to start charging
>> money for it in future, but no user is aware of this restriction until
>> it's too late.
> I can do that in obfuscated code just as easily... doesn't even need to be
> that obfuscated...
> Personally speaking, though, if some timebomb like that landed on me I
> would *never* use anything from that developer again... so using the do on
> to others principle I do not support the practice.

There are many `softer' examples of such practices - look at the way
Skype offered Asterisk connectivity and then took it away again when
they were bought by Microsoft.  Such things are done with terms and
conditions far more often than they are done with obfuscation alone. 
Some users who find themselves in such a predicament may not be able to
take a principled stand, the immediate cost of developing an alternative
may be high and they may still have to pay for the plugin or whatever,
at least to get themselves 6 months to develop an alternative.

I don't think I ever claimed that having source or building from source
guarantees a rosy future where developers never have to review code.

Rather, being able to do a full recursive source build with Maven would
simply let developers save some time by excluding all those non-free,
sans-source elements of the toolchain and dependency graph with a simple
flick of the switch.  From there, developers would still be responsible
for some manual analysis of what remains.

I agree that this wouldn't work universally: but if there is a template
for how to go about it, then I suspect a majority of genuinely open and
free Maven-based projects could be rebuilt transitively, and once again,
developer effort would only need to be spent on those that remain.  If
project foo lacks a full pom.xml, then I could clone it in git, add the
pom.xml on a branch and give Maven some override list telling it where
to find project foo and others like it in my local git repositories.

All those obfuscation techniques you describe are a genuine risk: but
there is a very strong algorithm that can counterbalance that risk too. 
Community.  If a project (dependency, plugin or build tool) is open
source, and if it uses tools like git with signed tags, and if you can
see the history, mailing lists, (maybe you see it is supported by ASF?),
then you can make weighted decisions about trust and about what to
review.  If a project is developed by a diverse group of contributors
(and you can often see that from the repository and mailing lists) then
maybe you will decide to trust it more than 1 million lines of Java code
that has been uploaded by a single commiter.  If it is hard to measure
the strength of community around some component, then you can focus on
reviewing it and also bring it to the attention of those people who are
directly connected with it in the dependency graph.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message