From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FkJGg-0000v0-Cw for garchives@archives.gentoo.org; Sun, 28 May 2006 11:17:11 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4SBG8cN032455; Sun, 28 May 2006 11:16:08 GMT Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4SBG7Bx006157 for ; Sun, 28 May 2006 11:16:07 GMT Received: by ug-out-1314.google.com with SMTP id j40so583448ugd for ; Sun, 28 May 2006 04:16:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tODt+9cQmECQdMI1wbBdlSM4JUIOd84F6wmyKQyjw0TEL1C4VV0sTCwaHt7bWyAnannfodOHdXX8F2uEwG8CnP9X8Pi0n1WO5ekFIJTpBkkUn1XhuVwKpV+CbBQF3A0dZkbeJS43KiljXHedTlRx/j62mK7tkDMZYXd9Si6EUjk= Received: by 10.67.124.1 with SMTP id b1mr971111ugn; Sun, 28 May 2006 04:16:08 -0700 (PDT) Received: by 10.67.20.7 with HTTP; Sun, 28 May 2006 04:16:08 -0700 (PDT) Message-ID: Date: Sun, 28 May 2006 12:16:08 +0100 From: "robert burrell donkin" To: "Karl Trygve Kalleberg" Subject: Re: [gentoo-java] Split migration-packages Cc: gentoo-java@lists.gentoo.org, java@gentoo.org In-Reply-To: <44796856.1030605@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_677_11676251.1148814968007" References: <4470DE21.3070809@gentoo.org> <447606BB.50600@spikesource.com> <44796856.1030605@gentoo.org> X-Archives-Salt: e4475c60-66ac-49ce-9695-5dacdb4759d3 X-Archives-Hash: 9796d3a250ef4f073976e4c75e5462e7 ------=_Part_677_11676251.1148814968007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (i'd just like to add a few clarifications) On 5/28/06, Karl Trygve Kalleberg wrote: > > Calvin Austin wrote: > > > 1. source vs jars ebuilds. > > I built everything from source minus one jar file. I had to drop to > > source 1.4 or patch the code in some cases. However some projects are > > based on maven jar repositories, getting a source version of these can > > be a huge project in itself. > > That's true, but we'll of course never include any .jars from Maven in > our tree, since we cannot know which evil backdoors they put into their > code: we don't have the source code. for jars with a full and correct POM (maven project descriptor), the sourc= e code used to build the release will be available from the tag in the appropriate repository as noted in the POM. however, most jars do not have fully correct POMs... for apache jars, the maven repository @ ibiblio is just a mirror of the normative java repository @ apache. providing that the binaries are verifie= d against the signature files created by the release manager and hosted by apache, they are as trustworthy as building new jars from the source distributions. maven2 is starting to distribute source jars (for IDEs). these should match exactly the binary version. Also, we can never know if we need to do a security update, since the > versions of the jars in the maven repo do not always correspond to an > actual upstream release of anything. IMHO there are two separate issues here: 1 there are a relatively small number of jars (which were uploaded in the early days of maven) whose exact provinence is unknown (at least in terms o= f the tag from which the build was created) and some of which are badly numbered. this issue really hurt the maven team a year or two ago and took = a lot of energy to address. the maven2 repository is much cleaner and is much better supervised. so, i believe that (going forward) this particular problem is overstated. 2 security patches are relatively rare in the java world: new minor release= s are much more common. this is particular because many common security issue= s with C and C++ are prevented by the langauge but is also cultural. this approach seems likely to cause difficulties downstream. In conclusion: binary .jars are banned. otherwise this wouldn't be gentoo ;-) > 2. Using open source components vs certified binary components. > > Downloading certified jars from Sun or other vendors was a pain, howeve= r > > picking up a free implementation that may have never been certified may > > be just as bad if you don't know what you are doing passing a TCK is quite a lot of effort. the process takes a long time even if the implementation is already ready without the right contacts, it can also take hard cash. it's probably beyond the means of open source projects which aren't backed by a big organisation. - robert ------=_Part_677_11676251.1148814968007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (i'd just like to add a few clarifications)

On 5/28/06, Karl Trygve Kalleberg <karltk@gentoo.org> wrote:
Calvin Austin wrote:

> 1. source vs jars ebuilds.
> I built= everything from source minus one jar file. I had to drop to
> source= 1.4 or patch the code in some cases. However some projects are
> bas= ed on maven jar repositories, getting a source version of these can
> be a huge project in itself.

That's true, but we'll of cour= se never include any .jars from Maven in
our tree, since we cannot know = which evil backdoors they put into their
code: we don't have the source = code.

for jars with a full and correct POM (maven project descriptor),  the source code used to build the release will be available from the tag in the appropriate repository as noted in the POM. however, most jars do not have fully correct POMs...

for apache jars, the maven repository @ ibiblio is just a mirror of the normative java repository @ apache. providing that the binaries are verified against the signature files created by the release manager and hosted by apache, they are as trustworthy as building new jars from the source distributions.

maven2 is starting to distribute source jars (for IDEs). these should match= exactly the binary version.

Also, we can = never know if we need to do a security update, since the
versions of the= jars in the maven repo do not always correspond to an
actual upstream release of anything.

IMHO there are two separate issues here:

1 there are a relatively small number of jars (which were uploaded in the early days of maven) whose exact provinence is unknown (at least in terms of the tag from which the build was created) and some of which are badly numbered. this issue really hurt the maven team a year or two ago and took a lot of energy to address. the maven2 repository is much cleaner and is much better supervised. so, i believe that (going forward) this particular problem is overstated.

2 security patches are relatively rare in the java world: new minor releases are much more common. this is particular because many common security issues with C and C++ are prevented by the langauge but is also cultural. this approach seems likely to cause difficulties downstream.

In conclusion= : binary .jars are banned.

otherwise this wouldn't be gentoo ;-)

> 2.= Using open source components vs certified binary components.
> Downl= oading certified jars from Sun or other vendors was a pain, however
> picking up a free implementation that may have never been certifie= d may
> be just as bad if you don't know what you are doing

passing a TCK is quite a lot of effort. the process takes a long time even if the implementation is already ready without the right contacts, it can also take hard cash. it's probably beyond the means of open source projects which aren't backed by a big organisation.

- robert
------=_Part_677_11676251.1148814968007-- -- gentoo-java@gentoo.org mailing list