maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Pocock <dan...@pocock.com.au>
Subject Re: Source code verification/compliance with Maven?
Date Fri, 10 May 2013 09:09:09 GMT
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.
- a user wants to run their own on-site code analysis tool, and as the
quality of the tool improves, they want to re-run it over all their open
source code from time to time as well
- a user stresses a particular part of the code that has never been used
in anger before, and they need to profile and optimize that code with
some tools that require an original source tree

As I see it, CLM may provide the foundation for addressing these
concerns (e.g. by making sure that all components provide sources), but
the most prudent users still potentially need a convenient way to repeat
the build(s) locally on demand in a clean, offline environment.

Does Sonatype offer a public CLM demo of some multi-component open
source project, e.g. to show how CLM reports on Eclipse and perhaps some
application server like Apache ServiceMix?

The other thing that caught my attention is the Maven SCM capability,
and the <scm/> element in pom.xml - is this only used for making tags
after a build?  Or does any tool use this information to recursively
check-out and build dependency projects?

In Stephen's earlier reply, he commented on the difficulty of
recognizing embedded code (e.g. class files or JARs).  I don't think
this is as bad as it sounds though: a quick check of the signature of a
file is enough to determine if it is a PNG or a JAR or something
unknown.  A recursive scan of sources would probably classify each of
those artifacts for a different action.  e.g. *.png could be
whitelisted, while source repositories that keep binary copies of some
build tools would generate an alert for manual attention.


> This avoid the problem of building from source as you suggest since this
> is very often extremely difficult (just as the Debian folks or other Linux
> distros that try to rebuild everything from sources.. its a HUGE task).
I am one of those Debian folks and I do provide all my own packages in a
manner that enables people to repeat the build, add patches, etc in a
very uniform manner - although bringing Maven-based projects into Debian
wasn't the reason for my query in this instance.


> Sonatype CLM includes integration with Nexus, Eclipse IDE and
> Jenkins/Hudson as well as a backend server to define rules and more.
>
> manfred
>
> PS: Disclaimer I work with Sonatype on their documentation ..
>
>
>> Well, I know that Sonatype has a product they have been pretty aggressive
>> with called CLM.
>>
>> CLM shows both vulnerabilities and license threats -- including undefined
>> licenses...  Perhaps that is what you need?
>>
>>
>> Thanks,
>>
>> Roy Lyons
>>
>>
>>
>>
>>
>> On 5/9/13 4:15 AM, "Daniel Pocock" <daniel@pocock.com.au> wrote:
>>
>>> Hi,
>>>
>>> There is a lot of confusion about the distinction between software that
>>> is free (like malware in app stores) and software that is really free
>>> with open source code.
>>>
>>> Several people have asked me how they can be sure that a Maven build
>>> (including all downloaded plugins) only uses genuine open source
>>> software, and that the binary downloads are identical to the source
>>> releases.  There are many users that want to build projects from source
>>> code in clean, non-networked environments.
>>>
>>> How can somebody tell Maven to
>>> a) recursively download source JARs for all plugins and dependencies
>>> (and their build plugins) and compile them one by one?
>>> b) stop if any source JAR contains binary artifacts or if a
>>> dependency/plugin source is not available?
>>> c) put all downloaded source in some kind of tree where it can be tarred
>>> up, copied onto a DVD and then built by a machine that is offline?
>>>
>>> I'm aware of the command "mvn dependency:sources", but this only appears
>>> to fetch the sources on a best effort basis and doesn't appear to
>>> compile them.
>>>
>>> Regards,
>>>
>>> Daniel
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message