Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Received-SPF: pass (hermes.apache.org: domain of steve.loughran@gmail.com
 designates 64.233.184.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=VtejAhwnoCGeWDAd9feeP6ZJInlMmIfJ64m/CifA02es1HR4A+WyJMg4PsRW2jmFGd0h12rEfHE5pQzXrKutCQkO8yZQcNuplMLc8ODSC/boNF4LcX71dGm4WyRj3qf/gQnJjh9eTerSI9MY059QxVDzquIr/A6Y70GbZfRn4Js=
Message-ID: <c84a507805031513203227e126@mail.gmail.com>
Date: Tue, 15 Mar 2005 21:20:28 +0000
From: Steve Loughran <steve.loughran@gmail.com>
Reply-To: Steve Loughran <steve.loughran@gmail.com>
To: repository@apache.org
Subject: Re: security, hashing.
In-Reply-To: <4236F68A.3000905@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <c84a5078050310121173aac83d@mail.gmail.com>
	 <853ac4f40503150632263b70ad@mail.gmail.com>
	 <4236F68A.3000905@gmail.com>

On Tue, 15 Mar 2005 09:51:54 -0500, Mark Diggory <mdiggory@gmail.com> wrote:
> Russell Gold wrote:
> 
> >On Thu, 10 Mar 2005 20:11:20 +0000, Steve Loughran
> ><steve.loughran@gmail.com> wrote:
> >
> >
> >>The disadvantages
> >> -no obvious 'latest version' in the repository
> >> -harder to field support calls, "what is the hash of your artifacts"?
> >>
> >>
> >
> >Not to mention, really complicating the job of upgrading to new versions.
> >
> >Is there a danger here of solving the 1% case at the expense of the 99% case?
> >
> >
> >
> axis-0.0.1-04f3d5aab0.jar
> 
> then you have the version and the hash... Think of the hash as similar "alpha", "beta" or "rcN" identifiers (isn't it really? Your just identifying this particular "packaging" of axis-0.0.1.).
> 
> But then again, this starts to get into the arena of Jar Signing, and there already is facility for that in Jar Artifacts...

The trouble with signed jars is the side effect. sign a jar and it
becomes implicitly sealed: you cannot load new classes into populated
packages. For example, if Ant signed its jars, org.apache.tools.ant,
org.apache.tools.ant.taskdefs.optional and the like would only be
allowed to contain JARs which came from Ant. If any one is signed: all
the rest are locked out.

This is , IMO, complete antithesis to open source dev -there is no
point giving you the source if you can't use it.

What I am thinking of for a short term solution that works with the
existing repository is allow people to put the SHA1 digest in the
build file when loading a library

<library project="junit" version="3.8.1" sha1="3fc00lbabe456" />

This puts the checksum declaration into the build file, giving whoever
writes the file control. This will work with the existing system; I
just build the SHA1 checksum and compare it with what the user asked
for. The project/artifact/version info is all that is used for
retrieval though.