| 1 |
(i'd just like to add a few clarifications) |
| 2 |
|
| 3 |
On 5/28/06, Karl Trygve Kalleberg <karltk@g.o> wrote: |
| 4 |
> |
| 5 |
> Calvin Austin wrote: |
| 6 |
> |
| 7 |
> > 1. source vs jars ebuilds. |
| 8 |
> > I built everything from source minus one jar file. I had to drop to |
| 9 |
> > source 1.4 or patch the code in some cases. However some projects are |
| 10 |
> > based on maven jar repositories, getting a source version of these can |
| 11 |
> > be a huge project in itself. |
| 12 |
> |
| 13 |
> That's true, but we'll of course never include any .jars from Maven in |
| 14 |
> our tree, since we cannot know which evil backdoors they put into their |
| 15 |
> code: we don't have the source code. |
| 16 |
|
| 17 |
|
| 18 |
for jars with a full and correct POM (maven project descriptor), the source |
| 19 |
code used to build the release will be available from the tag in the |
| 20 |
appropriate repository as noted in the POM. however, most jars do not have |
| 21 |
fully correct POMs... |
| 22 |
|
| 23 |
for apache jars, the maven repository @ ibiblio is just a mirror of the |
| 24 |
normative java repository @ apache. providing that the binaries are verified |
| 25 |
against the signature files created by the release manager and hosted by |
| 26 |
apache, they are as trustworthy as building new jars from the source |
| 27 |
distributions. |
| 28 |
|
| 29 |
maven2 is starting to distribute source jars (for IDEs). these should match |
| 30 |
exactly the binary version. |
| 31 |
|
| 32 |
Also, we can never know if we need to do a security update, since the |
| 33 |
> versions of the jars in the maven repo do not always correspond to an |
| 34 |
> actual upstream release of anything. |
| 35 |
|
| 36 |
|
| 37 |
IMHO there are two separate issues here: |
| 38 |
|
| 39 |
1 there are a relatively small number of jars (which were uploaded in the |
| 40 |
early days of maven) whose exact provinence is unknown (at least in terms of |
| 41 |
the tag from which the build was created) and some of which are badly |
| 42 |
numbered. this issue really hurt the maven team a year or two ago and took a |
| 43 |
lot of energy to address. the maven2 repository is much cleaner and is much |
| 44 |
better supervised. so, i believe that (going forward) this particular |
| 45 |
problem is overstated. |
| 46 |
|
| 47 |
2 security patches are relatively rare in the java world: new minor releases |
| 48 |
are much more common. this is particular because many common security issues |
| 49 |
with C and C++ are prevented by the langauge but is also cultural. this |
| 50 |
approach seems likely to cause difficulties downstream. |
| 51 |
|
| 52 |
In conclusion: binary .jars are banned. |
| 53 |
|
| 54 |
|
| 55 |
otherwise this wouldn't be gentoo ;-) |
| 56 |
|
| 57 |
> 2. Using open source components vs certified binary components. |
| 58 |
> > Downloading certified jars from Sun or other vendors was a pain, however |
| 59 |
> > picking up a free implementation that may have never been certified may |
| 60 |
> > be just as bad if you don't know what you are doing |
| 61 |
|
| 62 |
|
| 63 |
passing a TCK is quite a lot of effort. the process takes a long time even |
| 64 |
if the implementation is already ready without the right contacts, it can |
| 65 |
also take hard cash. it's probably beyond the means of open source projects |
| 66 |
which aren't backed by a big organisation. |
| 67 |
|
| 68 |
- robert |
Archives