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 Thu, 09 May 2013 09:54:57 GMT
On 9 May 2013 10:44, Stephen Connolly <stephen.alan.connolly@gmail.com>wrote:

> On 9 May 2013 10:15, Daniel Pocock <daniel@pocock.com.au> wrote:
>
>> Hi,
>>
>
[snip]


>  b) stop if any source JAR contains binary artifacts or if a
>>
> dependency/plugin source is not available?
>>
>
> You could write an enforce rule that validates this... it would need
> exceptions for certain file types and how exactly do you determine what is
> a binary file anyway? what about a i18n resource bundle with UTF-16
> encoding... that will be non-ASCII... or UTF-8 without a BOM and with
> mostly asian characters... how do you differentiate that? or what about
> image resources / photos, etc
>
>
Ohhh just thought of the best yet... what is to stop somebody running a
decompiler to generate the source .java from the bytecode (with all the
obfuscated parameter names and function names etc that the obfuscator they
used applied to their .class file coming out in the resulting .java file...

Now you have a .java file that compiles to the .class file but is just as
useless as running the decompiler on the original .class file in the first
place.

In other words you can still meet the letter of your requirement of having
a -sources.jar that compiles to *an equivalent*[1] .jar without meeting the
spirit as you are no better off than when you only had the .class file in
the first place

At some point you need to come back to the question of trust.... do you
trust the source of this .jar... that's why there is the GPG signing
requirement for all new artifacts going into central. Turning on GPG
verification right now is not practicable as there are still sufficient
dependencies on artifacts without GPG signatures that you'd end up turning
it off again... but hopefully in the near future that is something that can
be turned on

[1] not an identical, as we do not not for certain exactly which build of
the JDK they used and inclusion or exclusion of debug info can tweak
things, so a byte for byte compare will only be valid if using the same JDK
build and options and if run through a debug info stripper in advance of
the byte for byte compare.

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