Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Fri, 25 Apr 2008 16:19:45 +0200
From: Niklas Matthies <ml_ivy-user@nmhq.net>
To: ivy-user@ant.apache.org
Subject: Re: secure dependency artifacts
Message-ID: <20080425141945.GA18230@nmhq.net>
Mail-Followup-To: ivy-user@ant.apache.org
References: 
 <745B9EDF57802349B13F90E4E0B4B86C3BA402BB48@HOUEXCH012.corp.halliburton.com>
 <20080424203556.GA89242@nmhq.net>
 <745B9EDF57802349B13F90E4E0B4B86C3BA402BB49@HOUEXCH012.corp.halliburton.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <745B9EDF57802349B13F90E4E0B4B86C3BA402BB49@HOUEXCH012.corp.halliburton.com>
User-Agent: Mutt/1.4.2.3i

On Thu 2008-04-24 at 16:21h, Shawn Castrianni wrote on ivy-user:
> How would all the developers unencrypt it? They each have their own
> credentials with their own passwords.

You can encrypt a file for multiple keys, so that it can be decrypted
with any of the keys for which it was encrypted. This is used for
example when sending an encrypted e-mail to multiple recipients.

The way this is usually implemented is that the content is encrypted
with some symmetric key, and for each recipient a copy of this content
key is itself encrypted with the recipient's public key and stored in
the so-called envelope, so that each recipient can decrypt the content
key and then use it decrypt the content.

The envelope data can actually be stored separately from the encrypted
content, so that you can update the envelope with different recipients
without having to touch the file containing the encrypted content.
(In other words, it wouldn't require re-publishing the encrypted
artifact with Ivy.)

Of course users don't have to deal with these details (assuming an
appropriate set-up), they just enter their passphrase.

> What I am trying to achieve is for only the developers that have
> access to the source code in the Subversion repository to be able to
> see the src.zip when they do a resolve/retrieve.  That way nobody is
> getting access to source code that they don't already have with
> Subversion.

What I'm suggesting is to separate the issues of how and where the
source code is distributed vs. who is able to access it. That way the
distribution infrastructure doesn't have to concern itself with access
control and provide special support for it. It also has the benefit
that you don't have to trust the distribution infrastructure to
correctly implement the access control mechanics.

-- Niklas Matthies