In-Reply-To: <Pine.LNX.4.43.0411151232460.746-100000@thinkpad.gardas.net>
References: <Pine.LNX.4.43.0411151232460.746-100000@thinkpad.gardas.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <A477F15E-3732-11D9-B41D-000393CFE6B8@spy.net>
Content-Transfer-Encoding: 7bit
From: Dustin Sallings <dustin@spy.net>
Subject: Re: [Gnu-arch-users] Re: darcs vs tla
Date: Mon, 15 Nov 2004 10:17:43 -0800
To: Karel Gardas <kgardas@objectsecurity.com>
Cc: gnu-arch-users@gnu.org, lode.leroy@advalvas.be,
        jeremy.shaw@linspireinc.com
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 1212
Lines: 40

On Nov 15, 2004, at 3:45, Karel Gardas wrote:

> Darcs' cons:
>
> - darcs does not support patch signing (showstopper for me)

	That's not *exactly* true.  darcs does support having signed patches 
on send when using the following flags:

              --sign                sign the patch with your gpg key
              --sign-as=KEYID       sign the patch with a given keyid
              --sign-ssl=IDFILE     sign the patch using openssl with a 
given private key

...when you apply, you can use one of the following flags for 
verification:

       --verify=PUBRING          verify that the patch was signed by a 
key in PUBRING
       --verify-ssl=KEYS         verify using openSSL with authorized 
keys from file 'KEYS'

	While the signature isn't recorded in the patch itself or your working 
tree (although the patch name includes the sha1), it can be validated 
if you keep the source of the patch (i.e. an email archive if you're 
using email for transport).

-- 
Dustin Sallings


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/