maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Source code verification/compliance with Maven?
Date Fri, 10 May 2013 11:33:04 GMT
On 10 May 2013 12:12, Daniel Pocock <daniel@pocock.com.au> wrote:

> On 10/05/13 12:21, Stephen Connolly wrote:
> > On 10 May 2013 10:09, Daniel Pocock <daniel@pocock.com.au> 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.


My conjecture is that a sufficient minority (which will end up on a
majority of dependency trees) will fall over at that step as to cause the
tooling to fail often enough that people will just give up on using such
tooling.... but that is my conjecture... which is why I don't intend on
working on such a tooling, but don't let my conjecture prevent you from
exploring your conjecture... the only way to test either hypothesis is to
build a tool to try and recursively build from source.


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

You miss the point I was making with those points... namely that building a
project from source does not prove (in the original meaning of test) that
the project is safe.

There are two tools that you can use:

1. Eyeballs
2. Binary analysis tools (e.g. on JVM that would be e.g. findbugs and its
ilk)

eyeballs requires a trusted path from source to binary, a community and
trust in the community...

binary analysis tools suffer from the false positive false negative
dilemma... if you set the threshold too low you get false claims of OK...
if you set it too high you get false claims of BAD, and in-between you have
varying degrees of warnings to evaluate and put eyeballs against

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message