From kristo at no-log.org Tue Jul 1 00:40:42 2008
From: kristo at no-log.org (Kristo)
Date: Tue, 01 Jul 2008 00:40:42 +0200
Subject: sending interactive passwords
In-Reply-To: <87prpzbdpk.fsf@wheatstone.g10code.de>
References: <4867DF70.9060607@san.rr.com>
<48681EAE.5030208@san.rr.com> <48683D60.4010604@san.rr.com>
<87prpzbdpk.fsf@wheatstone.g10code.de>
Message-ID: <486960EA.9060801@no-log.org>
Hi,
I'm not sure I'm talking about exactly the same thing, but I'm using
GnuPG 1.4.7 on window$ and gpg-agent does not work, nor pinentry.
I'd like to use them so I can have different passphrases for different
keys and remember them.
I saw that 1.4.9 binary is available but I don't see its release notes
on the site.
Is the gpg-agent + pinentry issue solved in the 1.4.9 version ?
And, can I install the 1.4.9 without uninstalling the 1.4.7 ?
Thanks a lot
Chris
Werner Koch a ecrit le 30/06/2008 09:10 :
> On Mon, 30 Jun 2008 03:56, adamm at san.rr.com said:
>
>
>> I just discovered --command-fd. It's pretty poorly documented, but it
>> seems to do the trick. Excellent! Sorry for the "unnecessary" posts,
>> but I searched the archives and didn't find a solution.
>>
>
> Or use gpg-agent - it does that all automagically for you.
>
>
> Shalom-Salam,
>
> Werner
>
>
From wk at gnupg.org Tue Jul 1 08:28:52 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 01 Jul 2008 08:28:52 +0200
Subject: sending interactive passwords
In-Reply-To: <486960EA.9060801@no-log.org> (kristo@no-log.org's message of
"Tue, 01 Jul 2008 00:40:42 +0200")
References: <4867DF70.9060607@san.rr.com> <48681EAE.5030208@san.rr.com>
<48683D60.4010604@san.rr.com> <87prpzbdpk.fsf@wheatstone.g10code.de>
<486960EA.9060801@no-log.org>
Message-ID: <877ic69kyj.fsf@wheatstone.g10code.de>
On Tue, 1 Jul 2008 00:40, kristo at no-log.org said:
> I'm not sure I'm talking about exactly the same thing, but I'm using
> GnuPG 1.4.7 on window$ and gpg-agent does not work, nor pinentry.
It will not work. Use GnuPG-2 instead (2.0.9 or later); it is available
as a Beta version from the www.gpg4win.org download page. gpg2 is even
installed as gpg with that installer.
> Is the gpg-agent + pinentry issue solved in the 1.4.9 version ?
There is no need to use 1.4.9 and gpg-agent.
> And, can I install the 1.4.9 without uninstalling the 1.4.7 ?
In theory yes, but it does not make any sense.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From rjh at sixdemonbag.org Tue Jul 1 09:30:41 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 01 Jul 2008 02:30:41 -0500
Subject: sending interactive passwords
In-Reply-To: <877ic69kyj.fsf@wheatstone.g10code.de>
References: <4867DF70.9060607@san.rr.com>
<48681EAE.5030208@san.rr.com> <48683D60.4010604@san.rr.com>
<87prpzbdpk.fsf@wheatstone.g10code.de> <486960EA.9060801@no-log.org>
<877ic69kyj.fsf@wheatstone.g10code.de>
Message-ID: <4869DD21.5080809@sixdemonbag.org>
Werner Koch wrote:
> It will not work. Use GnuPG-2 instead (2.0.9 or later); it is available
> as a Beta version from the www.gpg4win.org download page.
Werner, it was just a couple of months ago you were saying GnuPG 2.x was
in a release state for Windows. Am I misremembering? Or is this just
a beta of 2.0.9, and 2.0.8 is still considered the stable version?
From wk at gnupg.org Tue Jul 1 12:24:10 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 01 Jul 2008 12:24:10 +0200
Subject: sending interactive passwords
In-Reply-To: <4869DD21.5080809@sixdemonbag.org> (Robert J. Hansen's message of
"Tue, 01 Jul 2008 02:30:41 -0500")
References: <4867DF70.9060607@san.rr.com> <48681EAE.5030208@san.rr.com>
<48683D60.4010604@san.rr.com> <87prpzbdpk.fsf@wheatstone.g10code.de>
<486960EA.9060801@no-log.org> <877ic69kyj.fsf@wheatstone.g10code.de>
<4869DD21.5080809@sixdemonbag.org>
Message-ID: <87k5g59a2d.fsf@wheatstone.g10code.de>
On Tue, 1 Jul 2008 09:30, rjh at sixdemonbag.org said:
> Werner, it was just a couple of months ago you were saying GnuPG 2.x was
> in a release state for Windows. Am I misremembering? Or is this just
> a beta of 2.0.9, and 2.0.8 is still considered the stable version?
Right. GnuPG 2.0.9 is pretty stable on Windows.
There is one last change which will go into 2.0.10: The equivalent of
/etc/gnupg as changed on Windows from the installation directory to
%CSIDL_COMMON_APPDATA%/GNU/etc/gnupg.
That change is already available in 2.0.10 snapshot as included in the
mentioned gpg4win beta. The new feature in 2.0.10 will be:
* New keyserver helper gpg2keys_kdns as generic DNS CERT lookup. Run
with --help for a short description. Requires the ADNS library.
* New mechanisms "local" and "nodefault" for --auto-key-locate [gpg].
Fixed a few problems with this option.
* [W32] Initialized the socket subsystem for all keyserver helpers.
* [W32] The sysconf directory has been moved from a subdirectory of
the installation directory to %CSIDL_COMMON_APPDATA%/GNU/etc/gnupg.
* New gpg2 command --locate-keys.
* New gpg2 options --with-sig-list and --with-sig-check.
* Made gpgsm's --output option work with --export-secret-key-p12.
* gpg-connect-agent accepts commands given as command line arguments.
* The gpg2 option --fixed-list-mode is now implicitly used and obsolete.
* New control statement %ask-passphrase for the unattended key
generation of gpg2.
* gpgsm now uses AES by default.
FWIW: We also found and fixed a race condition in GPGME when using
gpgme. Not all file descriptors were closed when executing gpg or
gpgsm; under certain circumstances this could lead to hanging processes.
Easy to fix under Unix (fork(2) rocks!) - hard to get by on Windows:
Marcus had to write a wrapper and to rewrite the invocation of
gpg/gpgsm.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From daniel.leidert.spam at gmx.net Tue Jul 1 22:30:36 2008
From: daniel.leidert.spam at gmx.net (Daniel Leidert)
Date: Tue, 01 Jul 2008 22:30:36 +0200
Subject: Gnupg (1.4.9) Errors in german translation
In-Reply-To: <87bq1sd0r8.fsf@wheatstone.g10code.de>
References: <48556180.8080706@hammernoch.net> <20080616173131.83260@gmx.net>
<4856ADD0.3080601@hammernoch.net>
<87bq1sd0r8.fsf@wheatstone.g10code.de>
Message-ID: <1214944236.3676.5.camel@localhost>
Am Montag, den 23.06.2008, 10:16 +0200 schrieb Werner Koch:
> On Mon, 16 Jun 2008 20:15, ludwig at hammernoch.net said:
>
> > I corrected de.po. from 1.4.9 and created the patch against
> > STABLE-BRANCH-1-4, so it was mostly the inverted patch from issue916.
>
> Commited to 4791.
Attached is another minor typo fix for the German translation.
Regards, Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg.diff
Type: text/x-patch
Size: 419 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg_1_4.diff
Type: text/x-patch
Size: 419 bytes
Desc: not available
URL:
From daniel.leidert.spam at gmx.net Tue Jul 1 23:10:42 2008
From: daniel.leidert.spam at gmx.net (Daniel Leidert)
Date: Tue, 01 Jul 2008 23:10:42 +0200
Subject: Gnupg (1.4.9) Errors in german translation
In-Reply-To: <1214944236.3676.5.camel@localhost>
References: <48556180.8080706@hammernoch.net> <20080616173131.83260@gmx.net>
<4856ADD0.3080601@hammernoch.net>
<87bq1sd0r8.fsf@wheatstone.g10code.de>
<1214944236.3676.5.camel@localhost>
Message-ID: <1214946642.3676.9.camel@localhost>
Am Dienstag, den 01.07.2008, 22:30 +0200 schrieb Daniel Leidert:
> Am Montag, den 23.06.2008, 10:16 +0200 schrieb Werner Koch:
> > On Mon, 16 Jun 2008 20:15, ludwig at hammernoch.net said:
> >
> > > I corrected de.po. from 1.4.9 and created the patch against
> > > STABLE-BRANCH-1-4, so it was mostly the inverted patch from issue916.
> >
> > Commited to 4791.
>
> Attached is another minor typo fix for the German translation.
I found more. Attached patches fix them.
Regards, Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg.diff
Type: text/x-patch
Size: 5575 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg_1_4.diff
Type: text/x-patch
Size: 6312 bytes
Desc: not available
URL:
From adam at adammil.net Wed Jul 2 01:12:15 2008
From: adam at adammil.net (Adam M.)
Date: Tue, 01 Jul 2008 16:12:15 -0700
Subject: BUG: gpg 1.4.9 opens --attribute-file in text mode
Message-ID: <486AB9CF.10207@adammil.net>
On the official Windows build of GPG 1.4.9 available from www.gnupg.org,
GPG opens the --attribute-file in text mode, causing all LF characters
to be converted to CR LF. Since the attribute data is binary, this
corrupts it.
This also seems to happen with --attribute-fd, at least if the file
descriptor is 2.
I looked in the source, and the --attribute-file is opened with
gpg.c:open_info_file(), which doesn't specify O_BINARY if for_write is
true (which it is in this case).
The --attribute-fd is opened with iobuf.c:iobuf_translate_file_handle(),
which also doesn't specify O_BINARY.
I would add a 'binary' (or 'text') parameter to these two functions and
then add the O_BINARY or O_TEXT flags appropriately.
-- Adam M.
From verbal at gmail.com Wed Jul 2 08:12:33 2008
From: verbal at gmail.com (verbal)
Date: Tue, 1 Jul 2008 23:12:33 -0700
Subject: question about setting options with gpgme
Message-ID: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com>
i am trying to set options with gpgme, especially --cipher-algo and --
compress-algo. can someone tell me what the API to do this is?
i am trying to use gpgme to do something like this:
gpg --symmetric --cipher-algo AES256 --compress-algo BZIP2
thanks for the help,
verbal
From wk at gnupg.org Wed Jul 2 12:34:35 2008
From: wk at gnupg.org (Werner Koch)
Date: Wed, 02 Jul 2008 12:34:35 +0200
Subject: question about setting options with gpgme
In-Reply-To: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com>
(verbal@gmail.com's message of "Tue, 1 Jul 2008 23:12:33 -0700")
References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com>
Message-ID: <873ams1sn8.fsf@wheatstone.g10code.de>
On Wed, 2 Jul 2008 08:12, verbal at gmail.com said:
> i am trying to use gpgme to do something like this:
>
> gpg --symmetric --cipher-algo AES256 --compress-algo BZIP2
There is no way to select the algorithm individually per message; you
need to change the configuration file. Gpgme allow to manage several
configuration files by changing the home directory of GnuPG per context.
To change the global options (gpg.conf), you may use the new gpgme
interface for managing the configuration files. They are not yet
documented, so you need to look at tests/gpg/t-gogconf.c or at the GPA
configuration dialog:
http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/src/confdialog.c?root=gpa&view=markup
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From adam at adammil.net Wed Jul 2 23:36:45 2008
From: adam at adammil.net (Adam M.)
Date: Wed, 02 Jul 2008 14:36:45 -0700
Subject: more information desired in --edit-key list output
Message-ID: <486BF4ED.6080509@adammil.net>
The --with-colons --edit-key list output:
(something like this)
pub:u:1024:1:265CC806C45BF178:1214983729:0::u:
fpr:::::::::C4B7E17BBFFDD6792E8CAEEA265CC806C45BF178:
uid:u::::::::John! :::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3
Z1,mdc,no-ks-modify:1,ps:
uid:u::::::::John! :::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3
Z1,mdc,no-ks-modify:2,:
uat:u::::::::1 7332:::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:3,:
uat:u::::::::1 7332:::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:4,:
doesn't provide enough information to positively correlate the uid and
uat records from --list-keys with the ones displayed in --edit-key.
In the --list-keys output, the user IDs and attributes can be easily
distinguished. They all have different creation times, and the user
attributes have different hash values too. But in the --edit-key menu,
the user IDs and user attributes look identical, so there's no way to
really tell which record I'm editing.
This would be greatly helped if two additional pieces of information
were displayed in the --edit-key output: the creation date (field 6) and
the hash of the UID/UAT contents (field 8). I'm guessing it wouldn't be
too hard to output them since the code is already written for --list-keys.
What do you think?
-- Adam
From dshaw at jabberwocky.com Wed Jul 2 23:53:58 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Wed, 2 Jul 2008 17:53:58 -0400
Subject: more information desired in --edit-key list output
In-Reply-To: <486BF4ED.6080509@adammil.net>
References: <486BF4ED.6080509@adammil.net>
Message-ID: <20080702215357.GA15573@jabberwocky.com>
On Wed, Jul 02, 2008 at 02:36:45PM -0700, Adam M. wrote:
> The --with-colons --edit-key list output:
>
> (something like this)
>
> pub:u:1024:1:265CC806C45BF178:1214983729:0::u:
> fpr:::::::::C4B7E17BBFFDD6792E8CAEEA265CC806C45BF178:
> uid:u::::::::John! :::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3
> Z1,mdc,no-ks-modify:1,ps:
> uid:u::::::::John! :::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3
> Z1,mdc,no-ks-modify:2,:
> uat:u::::::::1 7332:::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:3,:
> uat:u::::::::1 7332:::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:4,:
>
> doesn't provide enough information to positively correlate the uid and
> uat records from --list-keys with the ones displayed in --edit-key.
>
> In the --list-keys output, the user IDs and attributes can be easily
> distinguished. They all have different creation times, and the user
> attributes have different hash values too. But in the --edit-key menu,
> the user IDs and user attributes look identical, so there's no way to
> really tell which record I'm editing.
You don't need to do the correlation yourself: when selecting the uid
you want to operate on in the --edit-key menu, send "uid HASH" (using
the hash from --list-keys) instead of "uid NUMBER" to select the exact
uid or uat you are interested in.
David
From bernhard at intevation.de Thu Jul 3 20:12:32 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 3 Jul 2008 20:12:32 +0200
Subject: gpgme: how to interpret signature.status / documentation problem
Message-ID: <200807032012.38302.bernhard@intevation.de>
info gpgme-1.1.6
tells me
`gpgme_error_t status'
This is the status of the signature. In particular, the
following status codes are of interest:
`GPG_ERR_NO_ERROR'
This status indicates that the signature is valid. For
the combined result this status means that all
signatures are valid.
`GPG_ERR_SIG_EXPIRED'
[..]
What I cannot find the constants defined in gpgme.
The documentation seems outdate. How to I interpret the status values?
(I would want a string representation as well, if possible.) :)
E.g. what do the following values indicate
signature 1 :
summary: 0x800 (this is GPGME_SIGSUM_SYS_ERROR)
status: 0x7000001
Thanks,
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From bernhard at intevation.de Thu Jul 3 20:13:21 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 3 Jul 2008 20:13:21 +0200
Subject: question about setting options with gpgme
In-Reply-To: <873ams1sn8.fsf@wheatstone.g10code.de>
References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com>
<873ams1sn8.fsf@wheatstone.g10code.de>
Message-ID: <200807032013.24191.bernhard@intevation.de>
On Wednesday 02 July 2008 12:34, Werner Koch wrote:
> On Wed, ?2 Jul 2008 08:12, verbal at gmail.com said:
> > i am trying to use gpgme to do something like this:
> >
> > gpg --symmetric --cipher-algo AES256 --compress-algo BZIP2
>
> There is no way to select the algorithm individually per message; you
> need to change the configuration file. ?Gpgme allow to manage several
> configuration files by changing the home directory of GnuPG per context.
I've probably missed it: Is there a possibility to do symmetric crypto
operations over gpgme?
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL:
From adam at adammil.net Fri Jul 4 00:49:06 2008
From: adam at adammil.net (Adam M.)
Date: Thu, 03 Jul 2008 15:49:06 -0700
Subject: BUG?: gpg 1.4.9 uses incorrect OpenPGP key type when creating subkeys
via --edit-key
Message-ID: <486D5762.3080102@adammil.net>
When creating RSA Encrypt-Only (type 2) or RSA Sign-Only (type 3)
subkeys using the --edit-key "addkey" command, gpg 1.4.9 seems to create
the subkey as type 1 (RSA [Encrypt or Sign]).
Either that, or --list-keys --with-colons reports the type as 1 even
when it's actually 2 or 3.
Since GPG forces the user to choose RSA Encrypt-Only or RSA Sign-Only,
you'd expect it to actually use that in the created subkey.
Is there some reason for this? Backwards compatibility maybe? Or is it
just a bug?
-- Adam
From dshaw at jabberwocky.com Fri Jul 4 01:23:13 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Thu, 3 Jul 2008 19:23:13 -0400
Subject: BUG?: gpg 1.4.9 uses incorrect OpenPGP key type when creating
subkeys via --edit-key
In-Reply-To: <486D5762.3080102@adammil.net>
References: <486D5762.3080102@adammil.net>
Message-ID: <46666A4A-E47A-4DB2-98C5-F68427AC00C9@jabberwocky.com>
On Jul 3, 2008, at 6:49 PM, Adam M. wrote:
> When creating RSA Encrypt-Only (type 2) or RSA Sign-Only (type 3)
> subkeys using the --edit-key "addkey" command, gpg 1.4.9 seems to
> create the subkey as type 1 (RSA [Encrypt or Sign]).
>
> Either that, or --list-keys --with-colons reports the type as 1 even
> when it's actually 2 or 3.
>
> Since GPG forces the user to choose RSA Encrypt-Only or RSA Sign-
> Only, you'd expect it to actually use that in the created subkey.
Not a bug. RFC-4880:
13.5. RSA
There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only
keys. These types are deprecated. The "key flags" subpacket in a
signature is a much better way to express the same idea, and
generalizes it to all algorithms. An implementation SHOULD NOT
create such a key, but MAY interpret it.
We use key flags to indicate the intended use of the key.
David
From wk at gnupg.org Fri Jul 4 10:28:28 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jul 2008 10:28:28 +0200
Subject: question about setting options with gpgme
In-Reply-To: <200807032013.24191.bernhard@intevation.de> (Bernhard Reiter's
message of "Thu, 3 Jul 2008 20:13:21 +0200")
References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com>
<873ams1sn8.fsf@wheatstone.g10code.de>
<200807032013.24191.bernhard@intevation.de>
Message-ID: <87vdzm2gur.fsf@wheatstone.g10code.de>
On Thu, 3 Jul 2008 20:13, bernhard at intevation.de said:
> I've probably missed it: Is there a possibility to do symmetric crypto
> operations over gpgme?
Pass NULL instead of an array of recipients to the encrypt function:
If @var{recp} is @code{NULL}, symmetric rather than public key
encryption is performed. Symmetrically encrypted cipher text can be
deciphered with @code{gpgme_op_decrypt}. Note that in this case the
crypto backend needs to retrieve a passphrase from the user.
Symmetric encryption is currently only supported for the OpenPGP
crypto backend.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From wk at gnupg.org Fri Jul 4 10:33:47 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jul 2008 10:33:47 +0200
Subject: gpgme: how to interpret signature.status / documentation problem
In-Reply-To: <200807032012.38302.bernhard@intevation.de> (Bernhard Reiter's
message of "Thu, 3 Jul 2008 20:12:32 +0200")
References: <200807032012.38302.bernhard@intevation.de>
Message-ID: <87r6aa2glw.fsf@wheatstone.g10code.de>
On Thu, 3 Jul 2008 20:12, bernhard at intevation.de said:
> What I cannot find the constants defined in gpgme.
> The documentation seems outdate. How to I interpret the status values?
> (I would want a string representation as well, if possible.) :)
They are provided by libgpg-error. Use
gpg_err_code (err) == GPG_ERR_FOO
to compare an error code and
printf ("%s (in module %s)\n", gpg_strerror (err), gpg_strsource (err));
to print it. The constants are in gpg-error.h and you may use the
utility gpg-error to decode and print an error code on the command line:
$ gpg-error 0x2a
42 = (0, 42) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_TRIBUTE_TO_D_A) = (Unspecified source, Tribute to D. A.)
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From wk at gnupg.org Fri Jul 4 10:35:16 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jul 2008 10:35:16 +0200
Subject: BUG: gpg 1.4.9 opens --attribute-file in text mode
In-Reply-To: <486AB9CF.10207@adammil.net> (Adam M.'s message of "Tue, 01 Jul
2008 16:12:15 -0700")
References: <486AB9CF.10207@adammil.net>
Message-ID: <87k5g22gjf.fsf@wheatstone.g10code.de>
On Wed, 2 Jul 2008 01:12, adam at adammil.net said:
> On the official Windows build of GPG 1.4.9 available from
> www.gnupg.org, GPG opens the --attribute-file in text mode, causing
> all LF characters to be converted to CR LF. Since the attribute data
> is binary, this corrupts it.
I'll fix that. Thanks.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From bernhard at intevation.de Fri Jul 4 10:45:52 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 4 Jul 2008 10:45:52 +0200
Subject: question about setting options with gpgme
In-Reply-To: <87vdzm2gur.fsf@wheatstone.g10code.de>
References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com>
<200807032013.24191.bernhard@intevation.de>
<87vdzm2gur.fsf@wheatstone.g10code.de>
Message-ID: <200807041045.55338.bernhard@intevation.de>
On Friday 04 July 2008 10:28, Werner Koch wrote:
> On Thu, ?3 Jul 2008 20:13, bernhard at intevation.de said:
> > I've probably missed it: Is there a possibility to do symmetric crypto
> > operations over gpgme?
>
> Pass NULL instead of an array of recipients to the encrypt function:
>
> ? If @var{recp} is @code{NULL}, symmetric rather than public key
> ? encryption is performed. ?Symmetrically encrypted cipher text can be
> ? deciphered with @code{gpgme_op_decrypt}. ?Note that in this case the
> ? crypto backend needs to retrieve a passphrase from the user.
> ? Symmetric encryption is currently only supported for the OpenPGP
> ? crypto backend.
Arg, I've tried to look for it in the documentation and must have fumbled (it
was very hot in the office yesterday). :(
I had looked into the section 3 Protocols and Engines as well as 4 Algorithms,
therefore I would suggest to add a small hint towards symmetric to section 4.
Thanks!
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From bernhard at intevation.de Fri Jul 4 10:48:09 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 4 Jul 2008 10:48:09 +0200
Subject: gpgme: how to interpret signature.status / documentation problem
In-Reply-To: <87r6aa2glw.fsf@wheatstone.g10code.de>
References: <200807032012.38302.bernhard@intevation.de>
<87r6aa2glw.fsf@wheatstone.g10code.de>
Message-ID: <200807041048.12505.bernhard@intevation.de>
On Friday 04 July 2008 10:33, Werner Koch wrote:
> On Thu, ?3 Jul 2008 20:12, bernhard at intevation.de said:
> > What I cannot find the constants defined in gpgme.
> > The documentation seems outdate. How to I interpret the status values?
> > (I would want a string representation as well, if possible.) :)
>
> They are provided by libgpg-error. ?Use
>
> ? ? ?gpg_err_code (err) == GPG_ERR_FOO
>
> to compare an error code and
>
> ? ? ?printf ("%s (in module %s)\n", gpg_strerror (err), gpg_strsource
> (err));
>
> to print it. ?The constants are in gpg-error.h and you may use the
> utility gpg-error to decode and print an error code on the command line:
>
> $ gpg-error ?0x2a
> 42 = (0, 42) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_TRIBUTE_TO_D_A) =
> (Unspecified source, Tribute to D. A.)
Ah, cool. So do you agree that the documentation is outdated at
this? I saw the libgpg-error as one possibility, but I've missed the hint
that I should interpret the status value of the signature in this sense,
especially because there are other constants listed in the .texi file.
Best,
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL:
From wk at gnupg.org Fri Jul 4 12:28:40 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jul 2008 12:28:40 +0200
Subject: question about setting options with gpgme
In-Reply-To: <200807041045.55338.bernhard@intevation.de> (Bernhard Reiter's
message of "Fri, 4 Jul 2008 10:45:52 +0200")
References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com>
<200807032013.24191.bernhard@intevation.de>
<87vdzm2gur.fsf@wheatstone.g10code.de>
<200807041045.55338.bernhard@intevation.de>
Message-ID: <873amq2baf.fsf@wheatstone.g10code.de>
On Fri, 4 Jul 2008 10:45, bernhard at intevation.de said:
> I had looked into the section 3 Protocols and Engines as well as 4 Algorithms,
> therefore I would suggest to add a small hint towards symmetric to section 4.
Done in my working copy.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From wk at gnupg.org Fri Jul 4 12:31:50 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jul 2008 12:31:50 +0200
Subject: gpgme: how to interpret signature.status / documentation problem
In-Reply-To: <200807041048.12505.bernhard@intevation.de> (Bernhard Reiter's
message of "Fri, 4 Jul 2008 10:48:09 +0200")
References: <200807032012.38302.bernhard@intevation.de>
<87r6aa2glw.fsf@wheatstone.g10code.de>
<200807041048.12505.bernhard@intevation.de>
Message-ID: <87y74i0wkp.fsf@wheatstone.g10code.de>
On Fri, 4 Jul 2008 10:48, bernhard at intevation.de said:
> On Friday 04 July 2008 10:33, Werner Koch wrote:
>> On Thu, ?3 Jul 2008 20:12, bernhard at intevation.de said:
>> > What I cannot find the constants defined in gpgme.
>> > The documentation seems outdate. How to I interpret the status values?
>> > (I would want a string representation as well, if possible.) :)
>>
>> They are provided by libgpg-error. ?Use
>>
>> ? ? ?gpg_err_code (err) == GPG_ERR_FOO
>>
>> to compare an error code and
>>
>> ? ? ?printf ("%s (in module %s)\n", gpg_strerror (err), gpg_strsource
>> (err));
>>
>> to print it. ?The constants are in gpg-error.h and you may use the
>> utility gpg-error to decode and print an error code on the command line:
>>
>> $ gpg-error ?0x2a
>> 42 = (0, 42) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_TRIBUTE_TO_D_A) =
>> (Unspecified source, Tribute to D. A.)
>
> Ah, cool. So do you agree that the documentation is outdated at
> this? I saw the libgpg-error as one possibility, but I've missed the hint
No, I think the manual is pretty clear about this:
@section Error Codes
@cindex error codes, list of
The library @code{libgpg-error} defines many error values. Most of
them are not used by @code{GPGME} directly, but might be returned by
@acronym{GPGME} because it received them from the crypto engine. The
below list only includes such error codes that have a specific meaning
in @code{GPGME}, or which are so common that you should know about
them.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From bernhard at intevation.de Fri Jul 4 13:14:12 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 4 Jul 2008 13:14:12 +0200
Subject: gpgme: how to interpret signature.status / documentation problem
In-Reply-To: <87y74i0wkp.fsf@wheatstone.g10code.de>
References: <200807032012.38302.bernhard@intevation.de>
<200807041048.12505.bernhard@intevation.de>
<87y74i0wkp.fsf@wheatstone.g10code.de>
Message-ID: <200807041314.15210.bernhard@intevation.de>
On Friday 04 July 2008 12:31, Werner Koch wrote:
> So do you agree that the documentation is outdated at
>
> > this? I saw the libgpg-error as one possibility, but I've missed the hint
>
> No, I think the manual is pretty clear about this:
>
> ? @section Error Codes
> ? @cindex error codes, list of
> ?
> ? The library @code{libgpg-error} defines many error values. ?Most of
> ? them are not used by @code{GPGME} directly, but might be returned by
> ? @acronym{GPGME} because it received them from the crypto engine. ?The
> ? below list only includes such error codes that have a specific meaning
> ? in @code{GPGME}, or which are so common that you should know about
> ? them.
I disagree, this section above is only instructive
if I already know that I am dealing with an error code.
That is exactely what I did not clearly understood from section Verify:
-- Data type: gpgme_signature_t
This is a pointer to a structure used to store a part of the
result of a `gpgme_op_verify' operation. The structure contains
the following members:
[..]
`gpgme_error_t status'
This is the status of the signature. In particular, the
following status codes are of interest:
`GPG_ERR_NO_ERROR'
This status indicates that the signature is valid. For
the combined result this status means that all
signatures are valid.
`GPG_ERR_SIG_EXPIRED'
This status indicate
Apart from the type "gpgme_error_t" it only talks about "status",
not about an error, which is not wrong, but having a short hint there
would allow readers to make the connection more easily.
Maybe something similiar like
`gpgme_error_t status'
This is the status of the signature,
provided by gpgme's @xref{Error Handling}.
In particular, the following status codes are of interest:
Thanks for considering,
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL:
From adam at adammil.net Sat Jul 5 00:21:42 2008
From: adam at adammil.net (Adam M.)
Date: Fri, 04 Jul 2008 15:21:42 -0700
Subject: BUG?: gpg 1.4.9 --edit-key writes preferences to TTY rather than
STDOUT
Message-ID: <486EA276.5010205@adammil.net>
Most information in the edit menu is written to STDOUT, allowing it to
be received by programs that are scripting GPG, but the
keyedit.c:show_names() and show_prefs() functions use tty_printf(),
which prevents the output from being captured, since the TTY can't be
redirected (at least on Windows).
Consequently, it seems rather difficult to do something like retrieve a
user ID's preferred keyserver.
I think only information that merely provides guidance to an interactive
user should be shown on the TTY, while all information that might be
usefully captured should be on STDOUT.
-- Adam
From adam at adammil.net Sun Jul 6 02:36:43 2008
From: adam at adammil.net (Adam Milazzo)
Date: Sat, 05 Jul 2008 17:36:43 -0700
Subject: BUG: gpg 1.4.9 --search-keys --with-colons writes strange line endings
(at least on Windows)
Message-ID: <4870139B.9020906@adammil.net>
GPG 1.4.9 --search-keys --with-colons on Windows writes CR CR LF at the
end of each line on STDOUT. This causes weird things to happen with most
text readers: like a CR character at the end of each line, an LF
character at the beginning of each line, and/or blank lines after each line.
These extra characters and/or blank lines mess up code to parse the
--search-keys output.
From nico-gnupg-dev-0 at schottelius.org Sun Jul 6 15:08:05 2008
From: nico-gnupg-dev-0 at schottelius.org (nico-gnupg-dev-0 at schottelius.org)
Date: Sun, 6 Jul 2008 15:08:05 +0200
Subject: The nightly gpgme newbie question: en- and decrypt problems
In-Reply-To: <87ej6jx49d.fsf@wheatstone.g10code.de>
References: <20080626210027.GA10453@denkbrett.schottelius.org>
<87ej6jx49d.fsf@wheatstone.g10code.de>
Message-ID: <20080706130805.GH27298@denkbrett.schottelius.org>
Yeah, found the problem!
When I use gpgme_data_new_from_file() and import the result from
my previous encryption, it works:
http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=EOF/ceofhack;a=commitdiff;h=37e753ff82232c2381e72e8c591eb1f4ce9bd962;hp=389a52942c1bb15183f747dc2902b641fe92b865
So after I removed the gpgme_data_write() call, it works:
http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=EOF/ceofhack;a=commitdiff;h=25ae82d55031ca9fc8c8fa3c98af5c135ef5c7b3;hp=37e753ff82232c2381e72e8c591eb1f4ce9bd962
Now I've only to find out, what I made wrong in that call...
Nico
ps: GPGME_DEBUG is nice, but not so helpful.
Werner Koch [Thu, Jun 26, 2008 at 11:42:06PM +0200]:
> On Thu, 26 Jun 2008 23:00, nico-gnupg-dev-0 at schottelius.org said:
>
> > But shouldn't it contain data, if gpgme_op_encrypt() before was successful?
>
> Run your test program like
>
> GPGME_DEBUG=9:/tmp/foo.log ./test
>
> and check the pretty verbose log to see the data excahnged between gpgme
> and gpg.
>
>
> Salam-Shalom,
>
> Werner
>
> --
> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
>
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From adam at adammil.net Sun Jul 6 23:51:32 2008
From: adam at adammil.net (Adam Milazzo)
Date: Sun, 06 Jul 2008 14:51:32 -0700
Subject: BUG?: gpg doesn't flush attribute stream after writing an attribute
Message-ID: <48713E64.9000000@adammil.net>
It would be very nice if GPG flushed the attribute stream after writing
an attribute, so that the number of bytes reported in the ATTRIBUTE
status message can be read reliably in response to that message.
As it is, the read often blocks because the data is sitting in GPG's
output buffer.
I think all this would require is an fflush() call at the end of
keylist.c:dump_attribs().
From nico-gnupg-dev-0 at schottelius.org Mon Jul 7 00:10:10 2008
From: nico-gnupg-dev-0 at schottelius.org (Nico Schottelius)
Date: Mon, 7 Jul 2008 00:10:10 +0200
Subject: gpgme_data_new_from_mem works, gpgme_data_write doesn't
Message-ID: <20080706221010.GC699@denkbrett.schottelius.org>
Hello!
I am testing around with gpgme and it seems I am doing something
wrong with gpgme_data_write():
If I do
gerr = gpgme_data_new(&g_test);
if(gerr != GPG_ERR_NO_ERROR) return 20;
i = strlen(b_encrypt);
/* THIS WORKS */
gerr = gpgme_data_new_from_mem(&g_encrypt_send, b_encrypt, i, 1);
if(gerr != GPG_ERR_NO_ERROR) return 24;
/* decrypt: from gpgme_data_new_from_mem() */
gerr = gpgme_op_decrypt(g_context, g_encrypt_send, g_plain_recv);
if(gerr != GPG_ERR_NO_ERROR) {
printf("gerr=%d\n",gerr);
return 19;
}
it works. If I do
gerr = gpgme_data_new(&g_test);
if(gerr != GPG_ERR_NO_ERROR) return 20;
i = strlen(b_encrypt);
printf("strlen(%s) = %d\n",b_encrypt,i);
/* THIS DOES NOT WORK */
tmp = gpgme_data_write(g_test, b_encrypt, i);
printf("gpgmedatawrite: %d\n", tmp);
/* decrypt: from gpgme_data_write() */
gerr = gpgme_op_decrypt(g_context, g_test, g_plain_recv2);
if(gerr != GPG_ERR_NO_ERROR) {
printf("gerr=%d\n",gerr);
return 41;
}
it does *NOT* work.
I created a testfile, containing both cases to show it in
commit 86f3d41a53834231eea54da750bd4564c9c13ae0 of ceofhack.
Anyone a hint, what I am doing wrong in the latter case?
Sincerly
Nico
PS: http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=EOF/ceofhack;a=summary
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From marcus.brinkmann at ruhr-uni-bochum.de Mon Jul 7 22:39:50 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon, 07 Jul 2008 22:39:50 +0200
Subject: The nightly gpgme newbie question: en- and decrypt problems
In-Reply-To: <20080706130805.GH27298@denkbrett.schottelius.org>
References: <20080626210027.GA10453@denkbrett.schottelius.org> <87ej6jx49d.fsf@wheatstone.g10code.de>
<20080706130805.GH27298@denkbrett.schottelius.org>
Message-ID: <48727F16.6000704@ruhr-uni-bochum.de>
nico-gnupg-dev-0 at schottelius.org wrote:
> Yeah, found the problem!
>
> When I use gpgme_data_new_from_file() and import the result from
> my previous encryption, it works:
>
I have limited net access right now, but here are two hints that might
help you: gpgme data objects have a file pointer that must be rewound to
read written data (gpgme_data_seek). To use the seek function make sure
you compile with large file support. See the documentation.
Thanks,
Marcus
From bernhard at intevation.de Tue Jul 8 10:11:52 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 8 Jul 2008 10:11:52 +0200
Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8
introduces interoperability problem
Message-ID: <200807081011.55193.bernhard@intevation.de>
Just followed up on an email written with mutt 1.5.18
and signed with gnupg 1.4.9 which I could verify the signature
with gpg2, but not with gpg1 from Debian Sarge and Etch
which is 1.4.1 and 1.4.6 with patches respectively.
My current hypothesis is that the default change
introduced in gnupg 1.4.8 regarding --no-rfc2440-text
causes the interoperability problems. From what I have gathered,
the new setting is --no-rfc2440-text which will not strip
trailing spaces and tabs.
So verification with at least 1.4.1 - 1.4.7 fails with default
settings, if lines with trailing spaces and tabs are left in
unquoted by the MTA.
As the email came from mutt 1.5.18, I could observe that trailing
spaces were left in, in an message/rfc822 part.
(Note that quoted-printable or base64 is forbidden in those parts.)
Mutt could have stripped the spaces in this case before calculating
the hash, but did not and this is hard to decide, because any message/rfc822
part might contain another signature.
Conclusions:
Emails send with text-mode signatures to Debian Etch users
will not be verifiable by default settings in some situations.
This is bad of course as Etch is a production system.
Possibilities:
a) refrain from using text-mode signatures?
b) Educate Debian Etch users to set --no-rfc2440-text as default?
c) Convince Debian that this is a security problem and have them
update their gpg Etch Package
d) Educate users to get rid of the gnupg 1 package, and use gnupg2?
Hmmm.....
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL:
From dshaw at jabberwocky.com Tue Jul 8 15:02:56 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 8 Jul 2008 09:02:56 -0400
Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8
introduces interoperability problem
In-Reply-To: <200807081011.55193.bernhard@intevation.de>
References: <200807081011.55193.bernhard@intevation.de>
Message-ID: <78E4916A-6E54-424D-9B90-4E9188C4D27A@jabberwocky.com>
On Jul 8, 2008, at 4:11 AM, Bernhard Reiter wrote:
> Just followed up on an email written with mutt 1.5.18
> and signed with gnupg 1.4.9 which I could verify the signature
> with gpg2, but not with gpg1 from Debian Sarge and Etch
> which is 1.4.1 and 1.4.6 with patches respectively.
>
> My current hypothesis is that the default change
> introduced in gnupg 1.4.8 regarding --no-rfc2440-text
> causes the interoperability problems. From what I have gathered,
> the new setting is --no-rfc2440-text which will not strip
> trailing spaces and tabs.
>
> So verification with at least 1.4.1 - 1.4.7 fails with default
> settings, if lines with trailing spaces and tabs are left in
> unquoted by the MTA.
> As the email came from mutt 1.5.18, I could observe that trailing
> spaces were left in, in an message/rfc822 part.
> (Note that quoted-printable or base64 is forbidden in those parts.)
> Mutt could have stripped the spaces in this case before calculating
> the hash, but did not and this is hard to decide, because any
> message/rfc822
> part might contain another signature.
Can you clarify a bit more what you are seeing? I think if there was
a general problem here we would have heard screaming from many
sources. Since you're the first person reporting it here, I wonder if
there is something more subtle going on.
Specifically:
* Are you sure the sending MUA is mutt 1.5.18? (The subject line says
"by mutt?" which suggests you're not sure).
* What is the receiving MUA? (the one which calls GPG to verify the
signature).
* Was this message sent OpenPGP/MIME or something else? Clearsigned?
An old-style armored blob containing the content plus appended
signature? There are (alas) many ways to send a signed mail.
If you can send me the message in question, that would be ideal. In
mutt, do a ":set mbox_type=mbox", save the message to a file, tar the
file to ensure that nothing will mess about with line endings in
transit, and send me the tarball. If the message is sensitive and
should not be seen by others, can you ask the sender to create another
message in the same way to send me?
David
From bernhard at intevation.de Tue Jul 8 16:52:19 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 8 Jul 2008 16:52:19 +0200
Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8
introduces interoperability problem
In-Reply-To: <78E4916A-6E54-424D-9B90-4E9188C4D27A@jabberwocky.com>
References: <200807081011.55193.bernhard@intevation.de>
<78E4916A-6E54-424D-9B90-4E9188C4D27A@jabberwocky.com>
Message-ID: <200807081652.19863.bernhard@intevation.de>
Am Dienstag, 8. Juli 2008 15:02:56 schrieb David Shaw:
> On Jul 8, 2008, at 4:11 AM, Bernhard Reiter wrote:
> > Just followed up on an email written with mutt 1.5.18
> > and signed with gnupg 1.4.9 which I could verify the signature
> > with gpg2, but not with gpg1 from Debian Sarge and Etch
> > which is 1.4.1 and 1.4.6 with patches respectively.
> >
> > My current hypothesis is that the default change
> > introduced in gnupg 1.4.8 regarding --no-rfc2440-text
> > causes the interoperability problems. From what I have gathered,
> > the new setting is --no-rfc2440-text which will not strip
> > trailing spaces and tabs.
> >
> > So verification with at least 1.4.1 - 1.4.7 fails with default
> > settings, if lines with trailing spaces and tabs are left in
> > unquoted by the MTA.
> > As the email came from mutt 1.5.18, I could observe that trailing
> > spaces were left in, in an message/rfc822 part.
> > (Note that quoted-printable or base64 is forbidden in those parts.)
> > Mutt could have stripped the spaces in this case before calculating
> > the hash, but did not and this is hard to decide, because any ?
> > message/rfc822
> > part might contain another signature.
>
> Can you clarify a bit more what you are seeing? ?I think if there was ?
> a general problem here we would have heard screaming from many ?
> sources. ?Since you're the first person reporting it here, I wonder if ?
> there is something more subtle going on.
>
> Specifically:
> * Are you sure the sending MUA is mutt 1.5.18? ?(The subject line says ?
> "by mutt?" which suggests you're not sure).
Yes, I am quite sure as the header has it
and I do not think this is manipulated.
I've used the question mark to indicate that I do not know how
much mutt contributes to the problem.
Note that you would need to have an attachment in, that already
has trailing spaces to some lines. Maybe it must be a message/rfc822
attachment, I did not verify yet.
> * What is the receiving MUA? (the one which calls GPG to verify the ?
> signature).
I've tried several e.g. mutt and used gpgparsemail as well.
Then I've disassembled this is msg and msg.sig and thus
are using gpg and gpg2 directly on these files.
gpg --verifiy msg.sig fails. gpg --no-rfc2440-text --verify msg.sig
works, as does gpg2.
(gpg is gpg 1.4.1 or 1.4.6 from Debian Sarge and Etch).
> * Was this message sent OpenPGP/MIME or something else? ?Clearsigned? ?
> An old-style armored blob containing the content plus appended ?
> signature? ?There are (alas) many ways to send a signed mail.
OpenPGP/MIME (which is clearsigned for message/rfc822).
> If you can send me the message in question, that would be ideal. ?In ?
> mutt, do a ":set mbox_type=mbox", save the message to a file, tar the ?
> file to ensure that nothing will mess about with line endings in ?
> transit, and send me the tarball. ?If the message is sensitive and ?
> should not be seen by others, can you ask the sender to create another ?
> message in the same way to send me?
I'll ask the sender, as the contents is sensitive and contains a forwarded
message and another attachment.
Best,
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
From bernhard at intevation.de Tue Jul 8 18:53:42 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 8 Jul 2008 18:53:42 +0200
Subject: pyme for debugging gpgme applications, new verifydetails.py
Message-ID: <200807081853.47886.bernhard@intevation.de>
I have attached a new verifydetails.py to
https://sourceforge.net/tracker/index.php?func=detail&aid=2013640&group_id=104883&atid=639601
It helps to debug how applications deal with gpgme result values
E.g. here is an example output
python examples/verifydetails.py ~/tmp/y.sig ~/tmp/dbgmd-00001.verify
gpgme version: 1.1.6
engines:
/usr/bin/gpg2 2.0.9
/usr/bin/gpgsm 2.0.9
OpenPGP True
CMS True
trying to verify signature /home/bernhard/tmp/y.sig for
file /home/bernhard/tmp/dbgmd-00001.verify
signature 1 :
summary: 0x800
status: 0x7000001
timestamp: 1215123456
fingerprint: XXXXXXXXXXXXX
uid: XXXXXXXXXXXXXXXXXXXXX
You can use "gpg-error" to decipher the "status" value:
$ LANG=C gpg-error 0x7000001
117440513 = (7, 1) = (GPG_ERR_SOURCE_GPGME, GPG_ERR_GENERAL) = (GPGME, General
error)
To me this has been helpful in analysing if gpgme or Kontact/KMail or both
contribute to a problematic behaviour that can be observed.
It overcomes the obstacle that "gpg2" or "gpgsm" on the command line
might behave a bit differently as compared when being called via gpgme,
e.g. here are much more return values to consider.
Best,
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL:
From dshaw at jabberwocky.com Tue Jul 8 19:26:32 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 8 Jul 2008 13:26:32 -0400
Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8
introduces interoperability problem
In-Reply-To: <200807081652.19863.bernhard@intevation.de>
References: <200807081011.55193.bernhard@intevation.de>
<78E4916A-6E54-424D-9B90-4E9188C4D27A@jabberwocky.com>
<200807081652.19863.bernhard@intevation.de>
Message-ID: <20080708172632.GA86183@jabberwocky.com>
On Tue, Jul 08, 2008 at 04:52:19PM +0200, Bernhard Reiter wrote:
> Note that you would need to have an attachment in, that already
> has trailing spaces to some lines. Maybe it must be a message/rfc822
> attachment, I did not verify yet.
This is interesting, as OpenPGP/MIME requires trailing spaces to be
quoted. ("any trailing whitespace MUST then be removed from the
signed material.") That would imply that mutt isn't generating the
OpenPGP/MIME message properly. I suppose that is possible, but it
seems odd as Mutt has always been rigorous about following the
OpenPGP/MIME spec to the letter.
Have you seen this:
http://lists.gnupg.org/pipermail/gnupg-users/2005-January/024408.html
Can you ask the sender to perform the test suggested on that page?
Specifically:
An easy way to tell if your particular mail program correctly
implements PGP/MIME signing is to set --no-rfc2440-text, and send
yourself a signed message that has a number of blank spaces at the
end of a line. Then, set --rfc2440-text and attempt to verify the
signature. If the signature does not verify correctly, you may
wish to contact the developer of your mail program for an update.
In this case, of course, have the sender construct the same sort of
message as before (message/rfc822 attachment, etc).
David
From bernhard at intevation.de Wed Jul 9 09:51:04 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 9 Jul 2008 09:51:04 +0200
Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8
introduces interoperability problem
In-Reply-To: <20080708172632.GA86183@jabberwocky.com>
References: <200807081011.55193.bernhard@intevation.de>
<200807081652.19863.bernhard@intevation.de>
<20080708172632.GA86183@jabberwocky.com>
Message-ID: <200807090951.07828.bernhard@intevation.de>
Am Dienstag, 8. Juli 2008 19:26:32 schrieb David Shaw:
> On Tue, Jul 08, 2008 at 04:52:19PM +0200, Bernhard Reiter wrote:
> > Note that you would need to have an attachment in, that already
> > has trailing spaces to some lines. Maybe it must be a message/rfc822
> > attachment, I did not verify yet.
>
> This is interesting, as OpenPGP/MIME requires trailing spaces to be
> quoted. ("any trailing whitespace MUST then be removed from the
> signed material.") That would imply that mutt isn't generating the
> OpenPGP/MIME message properly. I suppose that is possible, but it
> seems odd as Mutt has always been rigorous about following the
> OpenPGP/MIME spec to the letter.
Hmm, thinking more about this, mutt forwarded a message by
which already was signed by Gnus, looking at it again I can
see that only the header lines of the forwarded message in two cases
have one trailing space. Those are X-Spam: and X-Attachments:, so maybe
something in the email transport introduces those spaces unnecessarily.
After all it might be a mutt problem that it does not strip those trailing
spaces. Stripping those spaces would require some more involved algorithm,
so maybe issuing a strong warning would be more appropriate.
Note that mutt cannot just encode this body part because it is
message/rfc822.
> Have you seen this:
> http://lists.gnupg.org/pipermail/gnupg-users/2005-January/024408.html
>
> Can you ask the sender to perform the test suggested on that page?
> Specifically:
>
> An easy way to tell if your particular mail program correctly
> implements PGP/MIME signing is to set --no-rfc2440-text, and send
> yourself a signed message that has a number of blank spaces at the
> end of a line. Then, set --rfc2440-text and attempt to verify the
> signature. If the signature does not verify correctly, you may
> wish to contact the developer of your mail program for an update.
>
> In this case, of course, have the sender construct the same sort of
> message as before (message/rfc822 attachment, etc).
This sounds easier then trying to create test message,
thanks for the hint.
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL:
From nico-gnupg-dev-0 at schottelius.org Wed Jul 9 14:29:29 2008
From: nico-gnupg-dev-0 at schottelius.org (Nico Schottelius)
Date: Wed, 9 Jul 2008 14:29:29 +0200
Subject: The nightly gpgme newbie question: en- and decrypt problems
In-Reply-To: <48727F16.6000704@ruhr-uni-bochum.de>
References: <20080626210027.GA10453@denkbrett.schottelius.org>
<87ej6jx49d.fsf@wheatstone.g10code.de>
<20080706130805.GH27298@denkbrett.schottelius.org>
<48727F16.6000704@ruhr-uni-bochum.de>
Message-ID: <20080709122929.GC23231@denkbrett.schottelius.org>
Hello Marcus?
Marcus Brinkmann [Mon, Jul 07, 2008 at 10:39:50PM +0200]:
> nico-gnupg-dev-0 at schottelius.org wrote:
>> Yeah, found the problem!
>>
>> When I use gpgme_data_new_from_file() and import the result from
>> my previous encryption, it works:
>>
> I have limited net access right now, but here are two hints that might
> help you: gpgme data objects have a file pointer that must be rewound to
> read written data (gpgme_data_seek). To use the seek function make sure
> you compile with large file support. See the documentation.
Tried that here:
http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=EOF/ceofhack;a=commitdiff;h=bac6504f564f7da0dd8a48e28cd4a55bff88739d;hp=86f3d41a53834231eea54da750bd4564c9c13ae0
but without success. See my other posting, where it narrows down to a
function.
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From B.Candler at pobox.com Thu Jul 10 13:06:08 2008
From: B.Candler at pobox.com (Brian Candler)
Date: Thu, 10 Jul 2008 12:06:08 +0100
Subject: gpg --decrypt strips space (but not CR) from clearsigned text
Message-ID: <20080710110608.GA15301@uk.tiscali.com>
(gpg version 1.4.6, Ubuntu 8.06)
When I generate a clearsigned document, the signature is insensitive to
adding extra spaces, tabs or CR (0x0D) to the end of each line. This is all
fine and in accordance with RFC 2440.
The clearsigned document retains the extra spaces, tabs and CRs exactly as
they were in the source document.
However, if I pass this clearsigned document to "gpg --decrypt" and redirect
stdout to a file, I find that the extra spaces and tabs are stripped,
although a trailing CR is retained.
To demonstrate:
perl -e 'print "Line one\nLine two \nLine three\t\nLine four \t\r\n"' >testfile
gpg --clearsign testfile
gpg --decrypt testfile.asc >testfile2
$ hexdump -C testfile
00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw|
00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L|
00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...|
0000002c
$ cat testfile.asc | grep ^Line | hexdump -C
00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw|
00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L|
00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...|
0000002c
$ hexdump -C testfile2
00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw|
00000010 6f 0a 4c 69 6e 65 20 74 68 72 65 65 0a 4c 69 6e |o.Line three.Lin|
00000020 65 20 66 6f 75 72 0d 0a |e four..|
I was hoping to use "gpg --decrypt" as a way to simultaneously verify the
signature and to strip off the wrapping and dash-escaping. However I want to
retain trailing spaces as they were in the source, and unfortunately that's
not happening.
Now, as far as I can see this is intentional, in g10/armor.c:
/* Now handle the end-of-line canonicalization */
although I don't see a test for this behaviour in checks/clearsig.test or
checks/armor.test
What strikes me as odd is that gpg retains a CR at the end of the line, but
not tabs or spaces. Futhermore, it happens for --decrypt but not for
--clearsign. Both these strike me as inconsistent.
Apart from disabling dash-escaping entirely(*), or moving to detached
signatures, can anyone suggest another way to verify and unwrap the source
document whilst keeping it intact?
Thanks,
Brian Candler.
(*) Because this breaks if the source document contains "-----BEGIN PGP
SIGNATURE-----". gpg will happily sign it without raising an error, but the
signed document is broken.
From B.Candler at pobox.com Thu Jul 10 14:56:19 2008
From: B.Candler at pobox.com (Brian Candler)
Date: Thu, 10 Jul 2008 13:56:19 +0100
Subject: gpg --decrypt strips space (but not CR) from clearsigned text
In-Reply-To: <886529.92896.qm@web56710.mail.re3.yahoo.com>
References: <886529.92896.qm@web56710.mail.re3.yahoo.com>
Message-ID: <20080710125619.GA19442@uk.tiscali.com>
On Thu, Jul 10, 2008 at 04:59:29AM -0700, Tracy D. Bossong wrote:
> During encryption use the switches --textmode --no-rfc2440-text
> I think that will resolve your issue.
I'm clearsigning, not encrypting. But I've tried your suggestion anyway, and
it makes no difference:
perl -e 'print "Line one\nLine two \nLine three\t\nLine four \t\r\n"' >testfile
gpg --clearsign --textmode --no-rfc2440-text testfile
gpg --decrypt testfile.asc >testfile2
The results:
$ grep ^Line testfile.asc | hexdump -C
00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw|
00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L|
00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...|
0000002c
$ hexdump -C testfile2
00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw|
00000010 6f 0a 4c 69 6e 65 20 74 68 72 65 65 0a 4c 69 6e |o.Line three.Lin|
00000020 65 20 66 6f 75 72 0d 0a |e four..|
00000028
Regards,
Brian.
From dshaw at jabberwocky.com Fri Jul 11 02:22:09 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Thu, 10 Jul 2008 20:22:09 -0400
Subject: gpg --decrypt strips space (but not CR) from clearsigned text
In-Reply-To: <20080710110608.GA15301@uk.tiscali.com>
References: <20080710110608.GA15301@uk.tiscali.com>
Message-ID: <8B34FE06-173B-48D9-9040-08DEC6C66DA3@jabberwocky.com>
On Jul 10, 2008, at 7:06 AM, Brian Candler wrote:
> (gpg version 1.4.6, Ubuntu 8.06)
>
> When I generate a clearsigned document, the signature is insensitive
> to
> adding extra spaces, tabs or CR (0x0D) to the end of each line. This
> is all
> fine and in accordance with RFC 2440.
>
> The clearsigned document retains the extra spaces, tabs and CRs
> exactly as
> they were in the source document.
>
> However, if I pass this clearsigned document to "gpg --decrypt" and
> redirect
> stdout to a file, I find that the extra spaces and tabs are stripped,
> although a trailing CR is retained.
This is correct, and is as per the standard. Section 7 of RFC-4880:
"Note that this framework is not intended to be reversible."
Note that the trailing CR is not actually retained. Rather, the end-
of-line marker is made to be correct for your platform. Depending on
that platform it might be a CR, a LF, or a CRLF.
The only way to get out byte-for-byte exactly what you put in is a
regular, non-clearsigned, non-textmode, signature.
David
From B.Candler at pobox.com Fri Jul 11 08:39:58 2008
From: B.Candler at pobox.com (Brian Candler)
Date: Fri, 11 Jul 2008 07:39:58 +0100
Subject: gpg --decrypt strips space (but not CR) from clearsigned text
In-Reply-To: <8B34FE06-173B-48D9-9040-08DEC6C66DA3@jabberwocky.com>
References: <20080710110608.GA15301@uk.tiscali.com>
<8B34FE06-173B-48D9-9040-08DEC6C66DA3@jabberwocky.com>
Message-ID: <20080711063958.GA6394@uk.tiscali.com>
On Thu, Jul 10, 2008 at 08:22:09PM -0400, David Shaw wrote:
> This is correct, and is as per the standard. Section 7 of RFC-4880:
> "Note that this framework is not intended to be reversible."
True - but I'd argue it's still inconsistent that --clearsign doesn't change
the cleartext, but --decrypt does.
RFC-4880 also says "any trailing whitespace ... is removed when the
cleartext signature is generated". gpg --clearsign doesn't modify the text
body in this way, although it does do it to the version of text body which
goes into the hash calculation of course.
> Note that the trailing CR is not actually retained. Rather, the end-
> of-line marker is made to be correct for your platform. Depending on
> that platform it might be a CR, a LF, or a CRLF.
That's not the behaviour I observe. For each incoming line, if it ends with
CRLF it is passed through as CRLF; but if it ends with LF only then it is
passed through as LF only.
Demonstration:
perl -e 'print "One\nTwo\r\n"' >testfile
gpg --clearsign testfile
gpg --decrypt testfile.asc >testfile2
$ hexdump -C testfile
00000000 4f 6e 65 0a 54 77 6f 0d 0a |One.Two..|
^^ ^^^^^^
00000009
$ hexdump -C testfile2
00000000 4f 6e 65 0a 54 77 6f 0d 0a |One.Two..|
^^ ^^^^^^
00000009
I've not tried this with any platform other than Unix however, so perhaps
you observe different behaviour under Windows etc.
Regards,
Brian.
From dshaw at jabberwocky.com Fri Jul 11 14:21:52 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Fri, 11 Jul 2008 08:21:52 -0400
Subject: gpg --decrypt strips space (but not CR) from clearsigned text
In-Reply-To: <20080711063958.GA6394@uk.tiscali.com>
References: <20080710110608.GA15301@uk.tiscali.com>
<8B34FE06-173B-48D9-9040-08DEC6C66DA3@jabberwocky.com>
<20080711063958.GA6394@uk.tiscali.com>
Message-ID:
On Jul 11, 2008, at 2:39 AM, Brian Candler wrote:
> On Thu, Jul 10, 2008 at 08:22:09PM -0400, David Shaw wrote:
>> This is correct, and is as per the standard. Section 7 of RFC-4880:
>> "Note that this framework is not intended to be reversible."
>
> True - but I'd argue it's still inconsistent that --clearsign
> doesn't change
> the cleartext, but --decrypt does.
Why? --cleartext is an 'encode' operation. --decrypt is a 'decode'.
Not reversible is not reversible. It doesn't matter much where that
happens.
> RFC-4880 also says "any trailing whitespace ... is removed when the
> cleartext signature is generated". gpg --clearsign doesn't modify
> the text
> body in this way, although it does do it to the version of text body
> which
> goes into the hash calculation of course.
Yes. Any trailing whitespace is, in fact, removed when the cleartext
signature is generated. The *signature*. The standard says nothing
about removing it from the body of the message. Mind you, it would be
legal to remove it, just as it would be legal to add more of it (say,
for a system with fixed-width transmission). It's even legal (though
silly) if GPG arbitrarily added a secret mesage in morse code to each
line using space as 'dot' and tab as 'dash'. All that is required is
that the signature contains the correct information.
>> Note that the trailing CR is not actually retained. Rather, the end-
>> of-line marker is made to be correct for your platform. Depending on
>> that platform it might be a CR, a LF, or a CRLF.
>
> That's not the behaviour I observe. For each incoming line, if it
> ends with
> CRLF it is passed through as CRLF; but if it ends with LF only then
> it is
> passed through as LF only.
Sorry, my mistake. I was thinking of textmode signatures. There is
no need to fix clearsigned end-of-line markers since (by definition)
they started as a text file on your local platform.
David
From tracy.bossong at yahoo.com Thu Jul 10 13:59:29 2008
From: tracy.bossong at yahoo.com (Tracy D. Bossong)
Date: Thu, 10 Jul 2008 04:59:29 -0700 (PDT)
Subject: gpg --decrypt strips space (but not CR) from clearsigned text
Message-ID: <886529.92896.qm@web56710.mail.re3.yahoo.com>
During encryption use the switches --textmode --no-rfc2440-text
I think that will resolve your issue.
----- Original Message ----
From: Brian Candler
To: gnupg-devel at gnupg.org
Sent: Thursday, July 10, 2008 6:06:08 AM
Subject: gpg --decrypt strips space (but not CR) from clearsigned text
(gpg version 1.4.6, Ubuntu 8.06)
When I generate a clearsigned document, the signature is insensitive to
adding extra spaces, tabs or CR (0x0D) to the end of each line. This is all
fine and in accordance with RFC 2440.
The clearsigned document retains the extra spaces, tabs and CRs exactly as
they were in the source document.
However, if I pass this clearsigned document to "gpg --decrypt" and redirect
stdout to a file, I find that the extra spaces and tabs are stripped,
although a trailing CR is retained.
To demonstrate:
perl -e 'print "Line one\nLine two \nLine three\t\nLine four \t\r\n"' >testfile
gpg --clearsign testfile
gpg --decrypt testfile.asc >testfile2
$ hexdump -C testfile
00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw|
00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L|
00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...|
0000002c
$ cat testfile.asc | grep ^Line | hexdump -C
00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw|
00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L|
00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...|
0000002c
$ hexdump -C testfile2
00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw|
00000010 6f 0a 4c 69 6e 65 20 74 68 72 65 65 0a 4c 69 6e |o.Line three.Lin|
00000020 65 20 66 6f 75 72 0d 0a |e four..|
I was hoping to use "gpg --decrypt" as a way to simultaneously verify the
signature and to strip off the wrapping and dash-escaping. However I want to
retain trailing spaces as they were in the source, and unfortunately that's
not happening.
Now, as far as I can see this is intentional, in g10/armor.c:
/* Now handle the end-of-line canonicalization */
although I don't see a test for this behaviour in checks/clearsig.test or
checks/armor.test
What strikes me as odd is that gpg retains a CR at the end of the line, but
not tabs or spaces. Futhermore, it happens for --decrypt but not for
--clearsign. Both these strike me as inconsistent.
Apart from disabling dash-escaping entirely(*), or moving to detached
signatures, can anyone suggest another way to verify and unwrap the source
document whilst keeping it intact?
Thanks,
Brian Candler.
(*) Because this breaks if the source document contains "-----BEGIN PGP
SIGNATURE-----". gpg will happily sign it without raising an error, but the
signed document is broken.
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From adam at adammil.net Sat Jul 12 07:15:01 2008
From: adam at adammil.net (Adam Milazzo)
Date: Fri, 11 Jul 2008 22:15:01 -0700
Subject: BUG: gpg 1.4.9 crashes when creating ELG keys with sign and encrypt
capability in batch mode
Message-ID: <48783DD5.5020109@adammil.net>
I think you're not supposed to use ElGamal keys that can sign and
encrypt, but GPG shouldn't crash in any case. This crash happens
consistently.
C:\> gpg --batch --gen-key
Key-Type: RSA
Key-Usage: sign
Subkey-Type: ELG-E
Subkey-Usage: encrypt sign
Name-Real: Joe Blow
^Z
gpg: keysize invalid; using 1024 bits
gpg: NOTE: you should run 'diskperf -y' to enable the disk statistics
.+++++
....+++++
gpg: keysize invalid; using 1024 bits
.+++++.+++++.++++++++++++++++++++++++++++++.++++++++++..+++++++++++++
+++++++.+++++.+++++..++++++++++++++++++++++++++++++.++++++++++>+++++.
+++++++++^^^
gpg: Ohhhh jeeee: no sign() for 16
secmem usage: 2624/3584 bytes in 8/14 blocks of pool 3872/32768
From adam at adammil.net Sat Jul 12 07:49:38 2008
From: adam at adammil.net (Adam Milazzo)
Date: Fri, 11 Jul 2008 22:49:38 -0700
Subject: BUG?: gpg 1.4.9 --edit-key writes preferences to TTY rather than
STDOUT
In-Reply-To: <486EA276.5010205@adammil.net>
References: <486EA276.5010205@adammil.net>
Message-ID: <487845F2.2090706@adammil.net>
This also prevents adding a key with custom capabilities.
The list of current key flags is written to the TTY, so you can't know
what flags to turn on or off at the keygen.flags prompt.
Adam M. wrote:
> Most information in the edit menu is written to STDOUT, allowing it to
> be received by programs that are scripting GPG, but the
> keyedit.c:show_names() and show_prefs() functions use tty_printf(),
> which prevents the output from being captured, since the TTY can't be
> redirected (at least on Windows).
>
> Consequently, it seems rather difficult to do something like retrieve a
> user ID's preferred keyserver.
>
> I think only information that merely provides guidance to an interactive
> user should be shown on the TTY, while all information that might be
> usefully captured should be on STDOUT.
>
> -- Adam
From wk at gnupg.org Mon Jul 14 16:05:28 2008
From: wk at gnupg.org (Werner Koch)
Date: Mon, 14 Jul 2008 16:05:28 +0200
Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8
introduces interoperability problem
In-Reply-To: <200807081011.55193.bernhard@intevation.de> (Bernhard Reiter's
message of "Tue, 8 Jul 2008 10:11:52 +0200")
References: <200807081011.55193.bernhard@intevation.de>
Message-ID: <873amco91z.fsf@wheatstone.g10code.de>
On Tue, 8 Jul 2008 10:11, bernhard at intevation.de said:
> Just followed up on an email written with mutt 1.5.18
Are you using
set crypt_use_gpgme
in .muttrc? This enables the other crypto backend; it is important to
known which one is used (the old one or the non-default gpgme based
one).
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From bernhard at intevation.de Wed Jul 16 22:56:54 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 16 Jul 2008 22:56:54 +0200
Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8
introduces interoperability problem
In-Reply-To: <873amco91z.fsf@wheatstone.g10code.de>
References: <200807081011.55193.bernhard@intevation.de>
<873amco91z.fsf@wheatstone.g10code.de>
Message-ID: <200807162256.55028.bernhard@intevation.de>
On Monday 14 July 2008 16:05, Werner Koch wrote:
> On Tue, ?8 Jul 2008 10:11, bernhard at intevation.de said:
> > Just followed up on an email written with mutt 1.5.18
>
> Are you using
>
> ? set crypt_use_gpgme
>
> in .muttrc? ?This enables the other crypto backend; it is important to
> known which one is used (the old one or the non-default gpgme based
> one).
The email was send by someone else...
This person became less available for completely other reasons,
so it might take a while until I can follow up on this.
Thanks for the hint, it is true I should have asked this directly.
Best,
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From bernhard at intevation.de Wed Jul 16 23:08:41 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 16 Jul 2008 23:08:41 +0200
Subject: Vs Combined Method? E+S from RFC 3156 6.2
In-Reply-To: <87fxsetkba.wl%marcus.brinkmann@ruhr-uni-bochum.de>
References: <200804291414.53915.bernhard@intevation.de>
<200805151416.14925.bernhard@intevation.de>
<87fxsetkba.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <200807162308.45596.bernhard@intevation.de>
I am coming back to the discussion,
because I do not see the resolution.
According to RFC 3156 6.2 it makes sense to always use the combined
method for encryption and signature as there is a requirement
for all compliant application to support this method.
Still I am looking for arguments why this is not a good idea.
On Monday 19 May 2008 16:55, Marcus Brinkmann wrote:
> At Thu, 15 May 2008 14:16:09 +0200, Bernhard Reiter wrote:
> > On Thursday 15 May 2008 13:20, Marcus Brinkmann wrote:
> > > At Tue, 29 Apr 2008 14:14:45 +0200,
> > >
> > > Bernhard Reiter wrote:
> > > > Given the enhanced compatibility, why not do combined method whenever
> > > > you can, just getting the compatibility advantage?
> > >
> > > Compatibility with what?
> >
> > The RFC from August 2001 says "to increase compatibility
> > with non-MIME implementations of OpenPGP".
>
> I was hoping for some specific applications that are in use today.
Even if there is a tiny small number even on older machines,
this would be no reason to not use the combined method as
all the other applications also need to support it.
Also this would be an open question what the RFC writers had in mind
when they made this statement. Is there a good way to find out about this?=
> > Sure, so you are basically saying: The argument from 2001 is obsolete.
>
> I am not saying that, I am just suggesting that, after evaluation, it
> might be such a case, depending on how important compatibility is in
> the real world.
>
> > On the other hand, to ease the implementation, shouldn't we then push
> > for the removal of the combined method requirement?
> > At least make it mandadory in new implementation to not create
> > new combined method emails?
>
> I think that, if this is such a case, then that would be a sensible
> next step.
This makes your argument depend on the outcome of the analysis.
Given that Werner does not recommend the combined method,
he must have a view on the result already.
> > > So, the question is, are there significant MUAs that support only
> > > combined mode?
> >
> > As for non-MIME MUAs, I think Outlook is significant.
> > (Being one of the developers of Gpg4win, you know that until recently
> > it could not do MIME OpenPGP. And that Outlook itself it not fully
> > MIME compliant, e.g. it does not display the text part of a
> > multipart/signed email, though it MUST according to MIME standards.)
>
> Oh well, that may be a millstone around our neck for the time being.
>
> > There will be others out there as well, e.g. on older unix machines
> > which did not update software very often.
>
> Not really what you are looking for, but: Somehow I question the
> wisdom of relying on security software on such systems...
Security is orthogonal to software modernisation: you might run a very old
unix-like system which is fully supported and thus fine security wise,
but still only has old software.
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From p.tucci at gmail.com Thu Jul 17 22:23:44 2008
From: p.tucci at gmail.com (Primiano Tucci)
Date: Thu, 17 Jul 2008 22:23:44 +0200
Subject: about the OpenPGP Card
Message-ID: <487FAA50.30602@gmail.com>
Hi,
I'm an Italian o.s. developer. I've some news to share about the OpenPGP
card.
I wrote a Java driver for the OpenPGP card (details at
http://www.primianotucci.com/go/jopenpgpcard)
I think this driver has several advantages:
-Does not need any PKCS11 driver to be installed (it's build on top of
Sun's javax.smartcardio low level apis)
-Requires nothing but a Java JRE.
-Can allow access to the OpenPGP card virtually everywhere (where a
smart card reader is available)
The driver comes with a sample OpenPGPCard Editor application (it's like
a graphical gpg --card-edit)
Going on with coding, I made a concept OpenID OpenPGP Card endpoint...
http://dev.primianotucci.com/openid/
It's a (working) php OpenID service that allows to get an unique login
identity on the web using the OpenPGP Card
An applet (that I wrote using the driver discussed above) manages the
login via a Challenge/Response Digital Signature scheme (using the
Authentication key on the smartcard)... than the OpenID protocol makes
the rest (e.g. I am able to log in my sourceforge account using my
OpenPGP card)
The service, of course, is less than a beta release, it's just a
conceptual demonstration of how the driver could be implemented to do so.
I hope someone could be interested in testing the OpenID service
Feel free to write me if you have further questions/comments
Best Regards
Primiano Tucci
--
+-----------------------------------------------+
| Primiano Tucci |
| http://www.primianotucci.com |
| |
| RSA pub key (preferred) |
| http://www.primianotucci.com/pubkey.rsa.cer |
| PGP pub key [0xE8481C1B] |
| http://www.primianotucci.com/pubkey.asc |
+-----------------------------------------------+
From rdieter at math.unl.edu Fri Jul 18 02:39:59 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 17 Jul 2008 19:39:59 -0500
Subject: gnupg1 still needed?
Message-ID:
I thought I (or someone) had asked this question in the not-too-distant past, but I couldn't find it anywhere. (sorry if it has).
Is gnupg(1) still needed, where gnupg2 is available?
It's been proposed to consider dropping gnupg(1) from Fedora 10, to consolidate on gnupg2, so I am looking for any pros/cons to that.
-- Rex
From dshaw at jabberwocky.com Fri Jul 18 03:50:03 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Thu, 17 Jul 2008 21:50:03 -0400
Subject: gnupg1 still needed?
In-Reply-To:
References:
Message-ID: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
On Jul 17, 2008, at 8:39 PM, Rex Dieter wrote:
> I thought I (or someone) had asked this question in the not-too-
> distant past, but I couldn't find it anywhere. (sorry if it has).
>
> Is gnupg(1) still needed, where gnupg2 is available?
>
> It's been proposed to consider dropping gnupg(1) from Fedora 10, to
> consolidate on gnupg2, so I am looking for any pros/cons to that.
They are two different programs for two different purposes. There is
significant overlap (they both do OpenPGP), but they're not direct
replacements for each other.
gpg (1) has been built into lots of scripts and server-side gadgets.
A forced change to gpg (2) is pretty likely to break all of that.
David
From eric at debian.org Fri Jul 18 05:52:40 2008
From: eric at debian.org (Eric Dorland)
Date: Thu, 17 Jul 2008 23:52:40 -0400
Subject: gnupg1 still needed?
In-Reply-To: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
Message-ID: <20080718035240.GA30115@gambit>
* David Shaw (dshaw at jabberwocky.com) wrote:
> On Jul 17, 2008, at 8:39 PM, Rex Dieter wrote:
>
>> I thought I (or someone) had asked this question in the not-too-
>> distant past, but I couldn't find it anywhere. (sorry if it has).
>>
>> Is gnupg(1) still needed, where gnupg2 is available?
>>
>> It's been proposed to consider dropping gnupg(1) from Fedora 10, to
>> consolidate on gnupg2, so I am looking for any pros/cons to that.
>
> They are two different programs for two different purposes. There is
> significant overlap (they both do OpenPGP), but they're not direct
> replacements for each other.
>
> gpg (1) has been built into lots of scripts and server-side gadgets. A
> forced change to gpg (2) is pretty likely to break all of that.
Are there substantial differences in the command line options from 1.4
to 2.0? My cursory glance at the manpages it looked pretty similar.
--
Eric Dorland
ICQ: #61138586, Jabber: hooty at jabber.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From adam at adammil.net Fri Jul 18 09:33:27 2008
From: adam at adammil.net (Adam Milazzo)
Date: Fri, 18 Jul 2008 00:33:27 -0700
Subject: gnupg1 still needed?
In-Reply-To:
References:
Message-ID: <48804747.4010009@adammil.net>
Well for one thing, gpg2 forces the use of the gpg-agent, which seems to
prevent programs that script GPG from providing passwords themselves.
Other than that, they seem equivalent to me.
Also, gpg2 has crashed many times for me, whereas gpg rarely does.
Rex Dieter wrote:
> I thought I (or someone) had asked this question in the not-too-distant past, but I couldn't find it anywhere. (sorry if it has).
>
> Is gnupg(1) still needed, where gnupg2 is available?
>
> It's been proposed to consider dropping gnupg(1) from Fedora 10, to consolidate on gnupg2, so I am looking for any pros/cons to that.
>
> -- Rex
From wk at gnupg.org Fri Jul 18 09:31:02 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 18 Jul 2008 09:31:02 +0200
Subject: gnupg1 still needed?
In-Reply-To: <20080718035240.GA30115@gambit> (Eric Dorland's message of "Thu,
17 Jul 2008 23:52:40 -0400")
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
<20080718035240.GA30115@gambit>
Message-ID: <87iqv3myx5.fsf@wheatstone.g10code.de>
On Fri, 18 Jul 2008 05:52, eric at debian.org said:
> Are there substantial differences in the command line options from 1.4
> to 2.0? My cursory glance at the manpages it looked pretty similar.
No. The changes are only related to the fact that the gpg-agent is in
general required for gpg2.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From wk at gnupg.org Fri Jul 18 09:36:35 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 18 Jul 2008 09:36:35 +0200
Subject: gnupg1 still needed?
In-Reply-To: (Rex Dieter's message of "Thu, 17
Jul 2008 19:39:59 -0500")
References:
Message-ID: <87ej5rmynw.fsf@wheatstone.g10code.de>
On Fri, 18 Jul 2008 02:39, rdieter at math.unl.edu said:
> Is gnupg(1) still needed, where gnupg2 is available?
I guess yes. For a desktop only machine gpg2 should be sufficient. In
fact the the default installer for Windows (gpg4win) now installs gpg2
unter the name gpg in the PATH.
However for an installer you probably want at least gpgv from gnupg-1.
It is far less depencencies that gpgv2.
You should don't remove gnupg-1 from a distribution; it should be
pssible to install it for the use of existsing scripts which assume a
standalone gpg (e.g. in chroot environment or with non-standard use of
the passphrase.).
Compare the case to Bind-8/9 - both are useful.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From wk at gnupg.org Fri Jul 18 09:45:21 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 18 Jul 2008 09:45:21 +0200
Subject: about the OpenPGP Card
In-Reply-To: <487FAA50.30602@gmail.com> (Primiano Tucci's message of "Thu, 17
Jul 2008 22:23:44 +0200")
References: <487FAA50.30602@gmail.com>
Message-ID: <87abgfmy9a.fsf@wheatstone.g10code.de>
On Thu, 17 Jul 2008 22:23, p.tucci at gmail.com said:
> It's a (working) php OpenID service that allows to get an unique login
> identity on the web using the OpenPGP Card
As a shameless plug let me mention that there is also Scute
(www.scute.org). Scute is a pkcs#11 driver on top of gpg-agent. It can
also be used to login to a server using the OpenPGP card. Scute
requires a running gpg-agent though and has only be tested with Mozilla.
Primiano: Are you aware of the draft 2.0 specification for the card?
There are a couple of new things in it; for example a new DO to store a
certificiate and a way to reset the card to factory defaults:
http://g10code.com/docs/openpgp-card-2.0-rc1.pdf .
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From wk at gnupg.org Fri Jul 18 10:28:57 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 18 Jul 2008 10:28:57 +0200
Subject: gnupg1 still needed?
In-Reply-To: <48804747.4010009@adammil.net> (Adam Milazzo's message of "Fri,
18 Jul 2008 00:33:27 -0700")
References: <48804747.4010009@adammil.net>
Message-ID: <87od4vlho6.fsf@wheatstone.g10code.de>
On Fri, 18 Jul 2008 09:33, adam at adammil.net said:
> Also, gpg2 has crashed many times for me, whereas gpg rarely does.
Please report these crashes if they still happen with the current
version.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From kssingvo at suse.de Fri Jul 18 11:46:58 2008
From: kssingvo at suse.de (Klaus Singvogel)
Date: Fri, 18 Jul 2008 11:46:58 +0200
Subject: gnupg1 still needed?
In-Reply-To: <87iqv3myx5.fsf@wheatstone.g10code.de>
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
<20080718035240.GA30115@gambit>
<87iqv3myx5.fsf@wheatstone.g10code.de>
Message-ID: <20080718094658.GB23370@suse.de>
Werner Koch wrote:
> On Fri, 18 Jul 2008 05:52, eric at debian.org said:
>
> > Are there substantial differences in the command line options from 1.4
> > to 2.0? My cursory glance at the manpages it looked pretty similar.
>
> No. The changes are only related to the fact that the gpg-agent is in
> general required for gpg2.
Sorry for asking back...
But I noticed that gpg1 could support old PGP keys, if module idea is
added. On the other side gpg2 it seems that gpg2 is capable to support
modules, and therefore lacks of IDEA support.
Is there a way to support old rsa/idea keys in gpg2?
Regards,
Klaus.
--
Klaus Singvogel - Maxfeldstr. 5 - 90409 Nuernberg - Germany
Phone: +49-911-74053-0
GnuPG-Key-ID: 1024R/5068792D 1994-06-27
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
From p.tucci at gmail.com Fri Jul 18 12:18:48 2008
From: p.tucci at gmail.com (Primiano Tucci)
Date: Fri, 18 Jul 2008 12:18:48 +0200
Subject: about the OpenPGP Card
In-Reply-To: <87abgfmy9a.fsf@wheatstone.g10code.de>
References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de>
Message-ID:
On Fri, Jul 18, 2008 at 9:45 AM, Werner Koch wrote:
> On Thu, 17 Jul 2008 22:23, p.tucci at gmail.com said:
>
>> It's a (working) php OpenID service that allows to get an unique login
>> identity on the web using the OpenPGP Card
>
> As a shameless plug let me mention that there is also Scute
> (www.scute.org). Scute is a pkcs#11 driver on top of gpg-agent. It can
> also be used to login to a server using the OpenPGP card. Scute
> requires a running gpg-agent though and has only be tested with Mozilla.
Scute is a pkcs11 driver, it means that prior to make your card work
you need to have downloaded the libary, configured mozilla (and it
seems no way for IE) and have a working gpg-agent.
My driver, on the other side, does not need anything, just a java
insatllation... so if you are on another pc that has a smartcard
reader (where probably there isn't any gpg-agent nor pkcs11 library)
you can still have many chances to use your OpenPGP card (see my
openpgp openid project http://dev.primianotucci.com/openid/)
> Primiano: Are you aware of the draft 2.0 specification for the card?
> There are a couple of new things in it; for example a new DO to store a
> certificiate and a way to reset the card to factory defaults:
> http://g10code.com/docs/openpgp-card-2.0-rc1.pdf .
I haven't looked at 2.0 specifications (i'm waiting for the final
one)... I don't think there are actually OpenPGP cards that implements
such specifications (correct me if wrong)
The driver is based on the 1.1 specs.... i'll update it as soon as the
final 2.0 specs will be ready.
Honestly I think the fact that enetering 3 wrong CHV3 destroyes the
card is a simple ashame... the "reset to blank" command should be a
must! (hopes for the 2.0 card :))
>
> Salam-Shalom,
>
> Werner
Thanks for your interest,
Primiano Tucci
From wk at gnupg.org Fri Jul 18 14:21:09 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 18 Jul 2008 14:21:09 +0200
Subject: about the OpenPGP Card
In-Reply-To:
(Primiano Tucci's message of "Fri, 18 Jul 2008 12:18:48 +0200")
References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de>
Message-ID: <87sku7jscq.fsf@wheatstone.g10code.de>
On Fri, 18 Jul 2008 12:18, p.tucci at gmail.com said:
> Scute is a pkcs11 driver, it means that prior to make your card work
> you need to have downloaded the libary, configured mozilla (and it
> seems no way for IE) and have a working gpg-agent.
Mozilla uses pkcs#11 as its crypto API thus you need such a driver.
Should also work with other browsers but not tested. Windows port is
under way.
> My driver, on the other side, does not need anything, just a java
> insatllation... so if you are on another pc that has a smartcard
And you need to allow Java in your browser. Some folks hesitate to
enable this.
> you can still have many chances to use your OpenPGP card (see my
> openpgp openid project http://dev.primianotucci.com/openid/)
Interesting.
> I haven't looked at 2.0 specifications (i'm waiting for the final
> one)... I don't think there are actually OpenPGP cards that implements
> such specifications (correct me if wrong)
In a couple of months. Actually the new spec has some feature to better
support Java cards.
> The driver is based on the 1.1 specs.... i'll update it as soon as the
> final 2.0 specs will be ready.
This is a release candidate - there are just a few typos left and
possible we need to extend the size of some fields. I already started
to implemented that in GnuPG.
> Honestly I think the fact that enetering 3 wrong CHV3 destroyes the
> card is a simple ashame... the "reset to blank" command should be a
> must! (hopes for the 2.0 card :))
Included in the new spec due to great public demand. How I just need
top add a command to gpg to allow resetting the card.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From wk at gnupg.org Fri Jul 18 14:23:52 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 18 Jul 2008 14:23:52 +0200
Subject: gnupg1 still needed?
In-Reply-To: <20080718094658.GB23370@suse.de> (Klaus Singvogel's message of
"Fri, 18 Jul 2008 11:46:58 +0200")
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
<20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de>
<20080718094658.GB23370@suse.de>
Message-ID: <87od4vjs87.fsf@wheatstone.g10code.de>
On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said:
> But I noticed that gpg1 could support old PGP keys, if module idea is
> added. On the other side gpg2 it seems that gpg2 is capable to support
I wonder why you ask. It is not possible for SuSE to include any such
support for an outdated, useless and patented cipher algorithm.
> Is there a way to support old rsa/idea keys in gpg2?
There are no IDEA keys. It might be that a key has been protected with
IDEA but there exists an easy workaround to change the protection
algorithm.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From wk at gnupg.org Fri Jul 18 14:28:17 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 18 Jul 2008 14:28:17 +0200
Subject: about the OpenPGP Card
In-Reply-To:
(Primiano Tucci's message of "Fri, 18 Jul 2008 12:18:48 +0200")
References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de>
Message-ID: <87iqv3js0u.fsf@wheatstone.g10code.de>
On Fri, 18 Jul 2008 12:18, p.tucci at gmail.com said:
> openpgp openid project http://dev.primianotucci.com/openid/)
Unfortunately there is no mailing list just a web forum. Thus not
useful for me. Feel free to use this list for technical discussions
related to the OpenPGP card.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From dshaw at jabberwocky.com Fri Jul 18 14:41:56 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Fri, 18 Jul 2008 08:41:56 -0400
Subject: gnupg1 still needed?
In-Reply-To: <87od4vjs87.fsf@wheatstone.g10code.de>
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
<20080718035240.GA30115@gambit>
<87iqv3myx5.fsf@wheatstone.g10code.de>
<20080718094658.GB23370@suse.de>
<87od4vjs87.fsf@wheatstone.g10code.de>
Message-ID: <2FE58E51-2FEB-4515-9CD6-95022EAF3496@jabberwocky.com>
On Jul 18, 2008, at 8:23 AM, Werner Koch wrote:
> On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said:
>
>> But I noticed that gpg1 could support old PGP keys, if module idea is
>> added. On the other side gpg2 it seems that gpg2 is capable to
>> support
>
> I wonder why you ask. It is not possible for SuSE to include any such
> support for an outdated, useless and patented cipher algorithm.
>
>> Is there a way to support old rsa/idea keys in gpg2?
>
> There are no IDEA keys. It might be that a key has been protected
> with
> IDEA but there exists an easy workaround to change the protection
> algorithm.
I think he's referring to IDEA keys in the sense of PGP 2.x: v3 RSA
keys that always use IDEA as their cipher.
We need to let PGP 2.x stay dead. I had fond hopes that the MD5 break
would kill PGP 2.x for good, but I was - alas - mistaken.
David
From p.tucci at gmail.com Fri Jul 18 15:01:49 2008
From: p.tucci at gmail.com (Primiano Tucci)
Date: Fri, 18 Jul 2008 15:01:49 +0200
Subject: about the OpenPGP Card
In-Reply-To: <87sku7jscq.fsf@wheatstone.g10code.de>
References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de>
<87sku7jscq.fsf@wheatstone.g10code.de>
Message-ID:
On Fri, Jul 18, 2008 at 2:21 PM, Werner Koch wrote:
> On Fri, 18 Jul 2008 12:18, p.tucci at gmail.com said:
>
>> Scute is a pkcs11 driver, it means that prior to make your card work
>> you need to have downloaded the libary, configured mozilla (and it
>> seems no way for IE) and have a working gpg-agent.
>
> Mozilla uses pkcs#11 as its crypto API thus you need such a driver.
This is absolutely uncorrect.
I do NOT need mozilla crypto api, i do not need the entire pkcs#11
layer since my driver rawly communicates via the T=1 protocol with the
card (thanks to Sun's Java low level APIs).
I just need Java and the card reader drivers (but NOT the pkcs11),
that's the big point of the driver.
> Should also work with other browsers but not tested. Windows port is
> under way.
Internet explorer does not use the standard PKCS11 layer... it uses a
more sofisticated layer (CSP).
There is an open source project (actually I miss the name) that claims
to act as a wrapper between Microsoft CSP and the PKCS11 layer, but i
never tested it.
>> My driver, on the other side, does not need anything, just a java
>> insatllation... so if you are on another pc that has a smartcard
>
> And you need to allow Java in your browser. Some folks hesitate to
> enable this.
Anyone chooses his paranoid level.
There are people that do not allow Internet on their computers :)
But we're in the 2008 and the i suppose the probability to find a Java
installation in a PC is realistically high (and absolutely higher than
the probability to find a pkcs11 layer + gpg agent + pkcs11 correctly
installed )
>> you can still have many chances to use your OpenPGP card (see my
>> openpgp openid project http://dev.primianotucci.com/openid/)
>
> Interesting.
>
>> I haven't looked at 2.0 specifications (i'm waiting for the final
>> one)... I don't think there are actually OpenPGP cards that implements
>> such specifications (correct me if wrong)
>
> In a couple of months. Actually the new spec has some feature to better
> support Java cards.
>
>> The driver is based on the 1.1 specs.... i'll update it as soon as the
>> final 2.0 specs will be ready.
>
> This is a release candidate - there are just a few typos left and
> possible we need to extend the size of some fields. I already started
> to implemented that in GnuPG.
>
>> Honestly I think the fact that enetering 3 wrong CHV3 destroyes the
>> card is a simple ashame... the "reset to blank" command should be a
>> must! (hopes for the 2.0 card :))
>
> Included in the new spec due to great public demand. How I just need
> top add a command to gpg to allow resetting the card.
>
>
> Salam-Shalom,
>
> Werner
>
> --
> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
>
>
Primiano Tucci
From kssingvo at suse.de Fri Jul 18 15:18:11 2008
From: kssingvo at suse.de (Klaus Singvogel)
Date: Fri, 18 Jul 2008 15:18:11 +0200
Subject: gnupg1 still needed?
In-Reply-To: <87od4vjs87.fsf@wheatstone.g10code.de>
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
<20080718035240.GA30115@gambit>
<87iqv3myx5.fsf@wheatstone.g10code.de>
<20080718094658.GB23370@suse.de>
<87od4vjs87.fsf@wheatstone.g10code.de>
Message-ID: <20080718131811.GB7442@suse.de>
Werner Koch wrote:
> On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said:
>
> > But I noticed that gpg1 could support old PGP keys, if module idea is
> > added. On the other side gpg2 it seems that gpg2 is capable to support
>
> I wonder why you ask. It is not possible for SuSE to include any such
> support for an outdated, useless and patented cipher algorithm.
Thats our problem: we cannot support/distribute algorithms with a
patent-fee. :-)
But I think, I should have deleted my .signature, as I was speaking
out of personal interests and not for my company. Please note either
that SUSE Linux dropped the support for gpg1 since 10.3 (Oct 2007),
and is shipping gpg2 only now. Sorry for my mistake.
The reason is that people came every then and a while to me and ask me
how to use the exact algorithms, why Phil Zimmerman got accused for
their release in the Usenet. As it is still not known how to break RSA
and IDEA, people still want only to use (insist on?) algorithms the
NSA showed the only time nervousness in the past.
Hope it helps for better understanding.
Regards,
Klaus.
--
Klaus Singvogel - Maxfeldstr. 5 - 90409 Nuernberg - Germany
Phone: +49-911-74053-0
GnuPG-Key-ID: 1024R/5068792D 1994-06-27
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
From wk at gnupg.org Fri Jul 18 15:58:02 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 18 Jul 2008 15:58:02 +0200
Subject: about the OpenPGP Card
In-Reply-To:
(Primiano Tucci's message of "Fri, 18 Jul 2008 15:01:49 +0200")
References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de>
<87sku7jscq.fsf@wheatstone.g10code.de>
Message-ID: <87prpbi9at.fsf@wheatstone.g10code.de>
On Fri, 18 Jul 2008 15:01, p.tucci at gmail.com said:
>> Mozilla uses pkcs#11 as its crypto API thus you need such a driver.
>
> This is absolutely uncorrect.
PKCS#11 is the native crypto API of Mozilla. But that is irrelevant
because you do not use it ...
> I do NOT need mozilla crypto api, i do not need the entire pkcs#11
> layer since my driver rawly communicates via the T=1 protocol with the
> card (thanks to Sun's Java low level APIs).
.. sure.
>> Should also work with other browsers but not tested. Windows port is
>> under way.
>
> Internet explorer does not use the standard PKCS11 layer... it uses a
> more sofisticated layer (CSP).
"Windows port" does not necessary mean "for Internet Exploder".
> But we're in the 2008 and the i suppose the probability to find a Java
> installation in a PC is realistically high (and absolutely higher than
> the probability to find a pkcs11 layer + gpg agent + pkcs11 correctly
> installed )
Depends on whom you ask. Those people using the OpenPGP card are
probably a bit more security aware than the average Windows user. In
fact, many security policies of companies and public administrations do
not allow the use of Java on client machines.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From jmoore3rd at bellsouth.net Fri Jul 18 16:57:15 2008
From: jmoore3rd at bellsouth.net (John W. Moore III)
Date: Fri, 18 Jul 2008 10:57:15 -0400
Subject: gnupg1 still needed?
In-Reply-To: <20080718131811.GB7442@suse.de>
References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de>
<20080718131811.GB7442@suse.de>
Message-ID: <4880AF4B.1000301@bellsouth.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Klaus Singvogel wrote:
> and IDEA, people still want only to use (insist on?) algorithms the
> NSA showed the only time nervousness in the past.
FWIW; "NSA nervousness" could very well be a 'Social Engineering' tactic
explicitly designed into lulling folks into a false sense of security.
Additionally, note should be taken of the phrase "in the past" and
respect given to the fact that NSA & their ilk recruit, employ and
devote literally 1,000's of mathematicians & analysts to 'solving
problems' and if any 'solutions' are discovered they _won't_ be
advertised or published. :-\
People are responsible for determining their Own threat model and acting
accordingly. From experience I can assure You that anything that really
makes NSA nervous won't be discussed with more than a handful of folks
outside Ft. Meade.
JOHN ;)
Timestamp: Friday 18 Jul 2008, 10:56 --400 (Eastern Daylight Time)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10-svn4799: (MingW32)
Comment: Public Key at: http://tinyurl.com/8cpho
Comment: Gossamer Spider Web of Trust: https://www.gswot.org
Comment: TokBox: http://www.tokbox.com/John234
Comment: Homepage: http://tinyurl.com/yzhbhx
iQEcBAEBCgAGBQJIgK9IAAoJEBCGy9eAtCsP73oH/jZZrmtkkXyI8trbF6xUnnrw
FP3F0OynYBjdxUf3e5++5e6p2XJ9aLJ2sz9zlz9lA+yxpih5oU33/wuts2leaAQU
2lV7kJWCLMf2dGG1JVRGEecAnyOwjQ2X5Lrtgytghoj8cDhLit81qJKR+JTvA9ZY
0XUbM73frEDugSfKmVFWQ0JagNG5y2rttUQSPLH53VeQ1at1ronVa1lVxd3U/nzd
JqGNHy6pXYY29U4Fg4TnzRQmEcx5IWmn5yTiG5TAX8/qnbvk+gPmo3kbHm4m5nKH
8zEHsiAn6oczipYGfiUdH0Jt6yCT94sLIj+nLjmehJ0ZKU7ZU/U+TbglfSeMVqc=
=yHP/
-----END PGP SIGNATURE-----
From cwal989 at comcast.net Fri Jul 18 16:28:26 2008
From: cwal989 at comcast.net (Chris Walters)
Date: Fri, 18 Jul 2008 10:28:26 -0400
Subject: gnupg1 still needed?
In-Reply-To: <87od4vjs87.fsf@wheatstone.g10code.de>
References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit>
<87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de>
<87od4vjs87.fsf@wheatstone.g10code.de>
Message-ID: <4880A88A.8090602@comcast.net>
Werner Koch wrote:
> On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said:
>
>> But I noticed that gpg1 could support old PGP keys, if module idea is
>> added. On the other side gpg2 it seems that gpg2 is capable to support
>
> I wonder why you ask. It is not possible for SuSE to include any such
> support for an outdated, useless and patented cipher algorithm.
>
>> Is there a way to support old rsa/idea keys in gpg2?
>
> There are no IDEA keys. It might be that a key has been protected with
> IDEA but there exists an easy workaround to change the protection
> algorithm.
It is rather difficult to know where IDEA is still patented and where it is not
(i.e. where the patent has expired). Even so, it is more than 10 years old
(the length of a patent in the US), and there are much better symmetric
algorithms out there, so I really don't see the need to use it.
There is a way to compile in support for IDEA in both gpg and gpg2, depending
on the distribution, but with AES, I think IDEA is outdated, myself. JMHO.
Regards,
Chris
From dshaw at jabberwocky.com Fri Jul 18 17:23:45 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Fri, 18 Jul 2008 11:23:45 -0400
Subject: IDEA isn't magic (was Re: gnupg1 still needed?)
In-Reply-To: <20080718131811.GB7442@suse.de>
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
<20080718035240.GA30115@gambit>
<87iqv3myx5.fsf@wheatstone.g10code.de>
<20080718094658.GB23370@suse.de>
<87od4vjs87.fsf@wheatstone.g10code.de>
<20080718131811.GB7442@suse.de>
Message-ID: <20080718152345.GA49835@jabberwocky.com>
On Fri, Jul 18, 2008 at 03:18:11PM +0200, Klaus Singvogel wrote:
> Werner Koch wrote:
> > On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said:
> >
> > > But I noticed that gpg1 could support old PGP keys, if module idea is
> > > added. On the other side gpg2 it seems that gpg2 is capable to support
> >
> > I wonder why you ask. It is not possible for SuSE to include any such
> > support for an outdated, useless and patented cipher algorithm.
>
> Thats our problem: we cannot support/distribute algorithms with a
> patent-fee. :-)
>
> But I think, I should have deleted my .signature, as I was speaking
> out of personal interests and not for my company. Please note either
> that SUSE Linux dropped the support for gpg1 since 10.3 (Oct 2007),
> and is shipping gpg2 only now. Sorry for my mistake.
>
> The reason is that people came every then and a while to me and ask me
> how to use the exact algorithms, why Phil Zimmerman got accused for
> their release in the Usenet.
In that case, shouldn't you be pointing them to BassOmatic? ;)
http://en.wikipedia.org/wiki/BassOmatic
> As it is still not known how to break RSA and IDEA, people still
> want only to use (insist on?) algorithms the NSA showed the only
> time nervousness in the past.
This is silly. IDEA has not been broken, but then neither has 3DES.
3DES (1978) has been studied a lot longer, and withstood far more
attacks than IDEA (1991).
David
From adam at adammil.net Fri Jul 18 20:11:19 2008
From: adam at adammil.net (Adam Milazzo)
Date: Fri, 18 Jul 2008 11:11:19 -0700
Subject: sendings passwords with gpg-agent? (was Re: gnupg1 still needed?)
In-Reply-To: <20080718131811.GB7442@suse.de>
References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de>
<20080718131811.GB7442@suse.de>
Message-ID: <4880DCC7.5080801@adammil.net>
Klaus Singvogel wrote:
> Please note either
> that SUSE Linux dropped the support for gpg1 since 10.3 (Oct 2007),
> and is shipping gpg2 only now.
Well, this makes me wonder, then.
gpg1 allows programs to send passwords using --command-fd. gpg2 always
uses gpg-agent, and never asks for passwords on the --command-fd. Is
there a way to get something equivalent on gpg2, though? i.e., can a
program hook into the gpg-agent in such a way as to provide its own UI
for password entry?
From sutter at informatik.hs-furtwangen.de Sat Jul 19 17:52:48 2008
From: sutter at informatik.hs-furtwangen.de (Phil Sutter)
Date: Sat, 19 Jul 2008 17:52:48 +0200
Subject: Secret Sharing
In-Reply-To: <20080525123053.GD29955@base.freewrt>
References: <20080319212325.GB12049@nuty.freewrt>
<20080525123053.GD29955@base.freewrt>
Message-ID: <20080719155248.GA17555@nuty>
Hi!
So far I have a working daemon setting up new Secret-Sharing sessions
and/or combining given shares. It already talks assuan.
In order to improve usability (a lot in my eyes), the daemon uses a
backing store (two files for now) holding all (sharing and combining)
sessions, so it can be called multiple times inserting/generating a
share each time.
On Sun, May 25, 2008 at 02:30:53PM +0200, Phil Sutter wrote:
> using an implementation of Shamir's (t,w)-threshold scheme I want to
> share the passphrase to a secret key. At least for now the algorithm
> will operate in GF(p).
Currently I'm using an implementation of arithmetics in GF(2^8) written
by James S. Plank, so the secret can consist of an arbitrary number of
bytes and therefore hold the hole secret key.
For the user interface I think of implementing the following set of
commands:
* setup: generate a new key pair, feed the secret key into a new
Secret-Sharing session and return the pubkey
* get_share: generate and return a new share for the session identified
by given keygrip
* finalise: remove all data (including the secret key) of the session
corresponding to the given keygrip
* combine: prepare combining shares for the given keygrip
* add_share: add the given share to the interpolation for it's keygrip;
if the key is available then, return it and remove the
interpolation metadata
gpg-agent uses GNUPG_PRIVATE_KEYS_DIR to lookup secret keys (at least)
(agent_key_available()). I haven't found the code yet where any key is
being written there, is it desirable at all to write recombined secret
keys there, or should I pass them over to gpg directly?
Greetings, Phil
From info at danielnylander.se Sun Jul 20 16:15:45 2008
From: info at danielnylander.se (Daniel Nylander)
Date: Sun, 20 Jul 2008 16:15:45 +0200
Subject: Updated Swedish translations
Message-ID: <1216563345.8165.2246.camel@fatbastard.internal.lidkoping.net>
I have updated the Swedish translations for gnupg 2.x and 1.4.x.
Please commit.
http://home.danielnylander.se/translations/gnupg/gnupg-1.4.sv.po
http://home.danielnylander.se/translations/gnupg/gnupg-2.sv.po
Regards,
Daniel Nylander
Stockholm, Sweden
From lists at lina.inka.de Sun Jul 20 22:50:19 2008
From: lists at lina.inka.de (Bernd Eckenfels)
Date: Sun, 20 Jul 2008 22:50:19 +0200
Subject: Secret Sharing
In-Reply-To: <20080719155248.GA17555@nuty>
References: <20080319212325.GB12049@nuty.freewrt>
<20080525123053.GD29955@base.freewrt> <20080719155248.GA17555@nuty>
Message-ID: <20080720205019.GA21274@lina.inka.de>
On Sat, Jul 19, 2008 at 05:52:48PM +0200, Phil Sutter wrote:
> * get_share: generate and return a new share for the session identified
> by given keygrip
A nice feature would be to pass a public key to it, so you get the key-share
encrypted back. That way the secret is less exposed.
Gruss
Bernd
--
(OO) -- Bernd_Eckenfels at M?rscher_Strasse_8.76185Karlsruhe.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/
o--o 1024D/E383CD7E eckes at IRCNet v:+497211603874 f:+49721151516129
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
From sutter at informatik.hs-furtwangen.de Mon Jul 21 01:55:29 2008
From: sutter at informatik.hs-furtwangen.de (Phil Sutter)
Date: Mon, 21 Jul 2008 01:55:29 +0200
Subject: Secret Sharing
In-Reply-To: <20080720205019.GA21274@lina.inka.de>
References: <20080319212325.GB12049@nuty.freewrt>
<20080525123053.GD29955@base.freewrt> <20080719155248.GA17555@nuty>
<20080720205019.GA21274@lina.inka.de>
Message-ID: <20080720235529.GD8043@base.freewrt>
On Sun, Jul 20, 2008 at 10:50:19PM +0200, Bernd Eckenfels wrote:
> On Sat, Jul 19, 2008 at 05:52:48PM +0200, Phil Sutter wrote:
> > * get_share: generate and return a new share for the session identified
> > by given keygrip
>
> A nice feature would be to pass a public key to it, so you get the key-share
> encrypted back. That way the secret is less exposed.
Yes, that's part of the plan. ;)
Also for recombining I think of the shares being encrypted with the
combiner's public key. In case of an interactive combining process (i.e.
a user sitting there entering a password), encrypting the
secret-sharing's backing store with the combiner's public key would
increase security without increasing overhead on the user interface side.
MfG, Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From buanzo at buanzo.com.ar Mon Jul 21 01:37:22 2008
From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman)
Date: Sun, 20 Jul 2008 20:37:22 -0300
Subject: gpg under wine?
Message-ID: <4883CC32.603@buanzo.com.ar>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi, I'm attempting to run gpg4win under Wine, but I get this:
buanzo at murray:~/.wine/drive_c/Program Files/GNU/GnuPG$ wine gpg.exe --gen-key
gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
gpg: fatal: WriteConsole failed: Access denied
secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768
Any ideas? I'm on Kubuntu Linux, up-to-date, nothing from source. It's gpg4win 1.1.3.
- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIg8wxAlpOsGhXcE0RCmMhAJ4u2r0g/PKLV9K5TDOojUKVmIfjyACfYLeP
nZfP8epTuO9QPh43+PxR8Ck=
=8Lgr
-----END PGP SIGNATURE-----
From wk at gnupg.org Mon Jul 21 09:05:54 2008
From: wk at gnupg.org (Werner Koch)
Date: Mon, 21 Jul 2008 09:05:54 +0200
Subject: Updated Swedish translations
In-Reply-To: <1216563345.8165.2246.camel@fatbastard.internal.lidkoping.net>
(Daniel Nylander's message of "Sun, 20 Jul 2008 16:15:45 +0200")
References: <1216563345.8165.2246.camel@fatbastard.internal.lidkoping.net>
Message-ID: <87ej5nogx9.fsf@wheatstone.g10code.de>
On Sun, 20 Jul 2008 16:15, info at danielnylander.se said:
> I have updated the Swedish translations for gnupg 2.x and 1.4.x.
> Please commit.
Done. Many thanks.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From marcus.brinkmann at ruhr-uni-bochum.de Mon Jul 21 10:57:31 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon, 21 Jul 2008 10:57:31 +0200
Subject: gpg under wine?
In-Reply-To: <4883CC32.603@buanzo.com.ar>
References: <4883CC32.603@buanzo.com.ar>
Message-ID: <877ibf7gxw.wl%marcus.brinkmann@ruhr-uni-bochum.de>
At Sun, 20 Jul 2008 20:37:22 -0300,
Arturo 'Buanzo' Busleiman wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi, I'm attempting to run gpg4win under Wine, but I get this:
>
> buanzo at murray:~/.wine/drive_c/Program Files/GNU/GnuPG$ wine gpg.exe --gen-key
> gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc.
> This program comes with ABSOLUTELY NO WARRANTY.
> This is free software, and you are welcome to redistribute it
> under certain conditions. See the file COPYING for details.
>
> gpg: fatal: WriteConsole failed: Access denied
> secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768
>
> Any ideas? I'm on Kubuntu Linux, up-to-date, nothing from source. It's gpg4win 1.1.3.
Please use wineconsole. Some gpg operations like gen-key really want
to talk to the console directly for increased security (for example to
prevent the passphrase from appearing on the screen). So, you should
use wineconsole instead of wine, which will launch a windows console
that implements those additional features.
There are also operation modes in gpg that don't require a console,
but those are harder to use and do not provide the interactivity you
get with --gen-key.
Thanks,
Marcus
From marcus.brinkmann at ruhr-uni-bochum.de Mon Jul 21 11:05:09 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon, 21 Jul 2008 11:05:09 +0200
Subject: sendings passwords with gpg-agent? (was Re: gnupg1 still needed?)
In-Reply-To: <4880DCC7.5080801@adammil.net>
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
<20080718035240.GA30115@gambit>
<87iqv3myx5.fsf@wheatstone.g10code.de>
<20080718094658.GB23370@suse.de>
<87od4vjs87.fsf@wheatstone.g10code.de>
<20080718131811.GB7442@suse.de> <4880DCC7.5080801@adammil.net>
Message-ID: <8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de>
At Fri, 18 Jul 2008 11:11:19 -0700,
Adam Milazzo wrote:
>
> Klaus Singvogel wrote:
> > Please note either
> > that SUSE Linux dropped the support for gpg1 since 10.3 (Oct 2007),
> > and is shipping gpg2 only now.
> Well, this makes me wonder, then.
>
> gpg1 allows programs to send passwords using --command-fd. gpg2 always
> uses gpg-agent, and never asks for passwords on the --command-fd. Is
> there a way to get something equivalent on gpg2, though? i.e., can a
> program hook into the gpg-agent in such a way as to provide its own UI
> for password entry?
I am not aware of such an option with gpg2, but note that you will
never get it in all circumstances. Consider smart cards used on a
terminal with a number pad. In this case, you really do not want the
pin number to go through the application.
It is best to consider gpg2 with this use case in mind. Just forget
about secret key handling and passphrases and such. They are not the
business of applications any more with gpg2.
Now, in case you really want this, you can replace the pinentry
program. There is currently no easy way to do this (you need to set
up your own gnupghome for it). But conceptually, the pinentry program
is the component you want to replace if you want to change its GUI.
Yes, this is harder to integrate into the application. This is on
purpose, see above.
Thanks,
Marcus
From adam at adammil.net Mon Jul 21 12:03:20 2008
From: adam at adammil.net (Adam Milazzo)
Date: Mon, 21 Jul 2008 03:03:20 -0700
Subject: sendings passwords with gpg-agent? (was Re: gnupg1 still needed?)
In-Reply-To: <8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de>
References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> <20080718131811.GB7442@suse.de> <4880DCC7.5080801@adammil.net>
<8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <48845EE8.50305@adammil.net>
[Whoops. Adding list.]
> Consider smart cards used on a
> terminal with a number pad. In this case, you really do not want the
> pin number to go through the application.
Yes, I agree.
> It is best to consider gpg2 with this use case in mind. Just forget
> about secret key handling and passphrases and such. They are not the
> business of applications any more with gpg2.
The main problem I have is that the gpg-agent UI sucks. For instance,
with symmetric decryption, it just says "Enter password", which leaves
the user wondering "which password??". They'll probably enter their
secret key password, which won't work. And they won't know why it didn't
work...
Second, there's no obvious way to cache the passwords, so the user would
think he has to to type them in for every file in a multi-file
operation, for instance.
And finally, unit tests for libraries that script GPG behind the scenes
can't be run automatically. The gpg-agent dialog pops up a hundred times
during the tests.
This would be a moot point if there was a GPG library, but the official
answer seems to be to script the GPG text-mode executable, which is made
harder by gpg-agent.
From buanzo at buanzo.com.ar Mon Jul 21 14:30:40 2008
From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman)
Date: Mon, 21 Jul 2008 09:30:40 -0300
Subject: gpg under wine?
In-Reply-To: <877ibf7gxw.wl%marcus.brinkmann@ruhr-uni-bochum.de>
References: <4883CC32.603@buanzo.com.ar>
<877ibf7gxw.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <48848170.7070506@buanzo.com.ar>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Marcus Brinkmann wrote:
| Please use wineconsole. Some gpg operations like gen-key really want
Silly me. Not a real wine user here. Sorry, should've analyzed wine more thorughly. Anyway, Googling
showed nothing useful for "WriteConsole failed" gpg wine, so I guess this is good anyway for future
searches ;)
- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIhIEeAlpOsGhXcE0RCo32AJ46qXopKtGYw3BX7XprNYr64vMJWgCfQU9A
Fp8uR/SRYRbcXcFuExDcJDs=
=ZlS3
-----END PGP SIGNATURE-----
From wk at gnupg.org Mon Jul 21 17:24:03 2008
From: wk at gnupg.org (Werner Koch)
Date: Mon, 21 Jul 2008 17:24:03 +0200
Subject: sendings passwords with gpg-agent?
In-Reply-To: <48845EE8.50305@adammil.net> (Adam Milazzo's message of "Mon, 21
Jul 2008 03:03:20 -0700")
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
<20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de>
<20080718094658.GB23370@suse.de>
<87od4vjs87.fsf@wheatstone.g10code.de> <20080718131811.GB7442@suse.de>
<4880DCC7.5080801@adammil.net>
<8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de>
<48845EE8.50305@adammil.net>
Message-ID: <87k5ff45ws.fsf@wheatstone.g10code.de>
On Mon, 21 Jul 2008 12:03, adam at adammil.net said:
> The main problem I have is that the gpg-agent UI sucks. For instance,
> with symmetric decryption, it just says "Enter password", which leaves
> the user wondering "which password??". They'll probably enter their
This is for sure not good. However there is no other information
available. Symmetric only encryption is usually only used in unattended
settings and thus there is no need for a pinentry (Use --passphrase-fd).
Please suggest a wording for the prompt uside with symmteric encryption.
> Second, there's no obvious way to cache the passwords, so the user would
> think he has to to type them in for every file in a multi-file
Well these are one-off passphrases and it does not make sense to cache
them - use public-key encryption instead. To allow for passphrase
caching we would need to implement a key management for symmetric
encryption; i.e. to use a random key protected by a passphrase. This is
quite some work becuase you need to have all the code to distribute such
protected symmetric passphrases.
> And finally, unit tests for libraries that script GPG behind the scenes
> can't be run automatically. The gpg-agent dialog pops up a hundred times
> during the tests.
Hmmm, gpg2 uses quite some regression tests without any problems. On my
todo list is a loopback-pinentry which would allow to test the entire
gpg-agent/gpg[sm] passphrase system. But well, regression tests are a
lot of work and a work most people don't won't to pay for and finding
volunteers is evene harder. Yes, there should be far more regresseion
tests.
> This would be a moot point if there was a GPG library, but the official
There is one: gpgme. gpgme even has a lot rof regression tests.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From adam at adammil.net Tue Jul 22 00:03:47 2008
From: adam at adammil.net (Adam Milazzo)
Date: Mon, 21 Jul 2008 15:03:47 -0700
Subject: BUG: gpgconf --apply-defaults seems to fail if it's in a directory
with a space
Message-ID: <488507C3.9010604@adammil.net>
Looks like it's invoking the shell without quoting the program to run,
or something like that:
C:\Program Files\GNU\GnuPG>gpgconf --apply-defaults
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
gpgconf: Option gpgconf-gpg.conf, needed by backend GnuPG, was not
initialized
gpgconf: fatal error (exit status 1)
From marcus.brinkmann at ruhr-uni-bochum.de Tue Jul 22 01:21:20 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Tue, 22 Jul 2008 01:21:20 +0200
Subject: sendings passwords with gpg-agent? (was Re: gnupg1 still needed?)
In-Reply-To:
References:
<9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com>
<20080718035240.GA30115@gambit>
<87iqv3myx5.fsf@wheatstone.g10code.de>
<20080718094658.GB23370@suse.de>
<87od4vjs87.fsf@wheatstone.g10code.de>
<20080718131811.GB7442@suse.de> <4880DCC7.5080801@adammil.net>
<8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <87vdyy6cy7.wl%marcus.brinkmann@ruhr-uni-bochum.de>
At Mon, 21 Jul 2008 12:43:25 -0400 (EDT),
mskala at ansuz.sooke.bc.ca wrote:
>
> On Mon, 21 Jul 2008, Marcus Brinkmann wrote:
> > I am not aware of such an option with gpg2, but note that you will
> > never get it in all circumstances. Consider smart cards used on a
> > terminal with a number pad. In this case, you really do not want the
> > pin number to go through the application.
>
> Being able to decrypt and sign in scripts is pretty important. If gpg2
> can't do that, people will use gpg1 whether you approve or not.
gpg2 can do that. Off the cuff, I can think of about 3-5 ways to do
it. The best method depends on your environment and security needs.
Just to give you a hint, check out the various passphrase related
command line options, the GPGME test suite in SVN, and the
gpg-preset-passphrase tool.
There is nothing wrong with using gpg1. We approve fully.
Thanks,
Marcus
From petr.uzel at suse.cz Wed Jul 23 11:17:40 2008
From: petr.uzel at suse.cz (Petr Uzel)
Date: Wed, 23 Jul 2008 11:17:40 +0200
Subject: [PATCH] - pinentry uses wrong apostrophe
Message-ID: <200807231117.41190.petr.uzel@suse.cz>
Hi list,
here comes small patch that fixes wrong apostrophes in
pinentry/secmem/secmem.c.
--
Best regards / s pozdravem
Petr Uzel, Packages maintainer
---------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: petr.uzel at suse.cz
Lihovarsk? 1060/12 tel: +420 284 028 964
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pinentry-0.7.5-wrong-apostrophe.patch
Type: text/x-diff
Size: 535 bytes
Desc: not available
URL:
From wk at gnupg.org Wed Jul 23 13:18:39 2008
From: wk at gnupg.org (Werner Koch)
Date: Wed, 23 Jul 2008 13:18:39 +0200
Subject: [PATCH] - pinentry uses wrong apostrophe
In-Reply-To: <200807231117.41190.petr.uzel@suse.cz> (Petr Uzel's message of
"Wed, 23 Jul 2008 11:17:40 +0200")
References: <200807231117.41190.petr.uzel@suse.cz>
Message-ID: <87ljzsg86o.fsf@wheatstone.g10code.de>
On Wed, 23 Jul 2008 11:17, petr.uzel at suse.cz said:
> here comes small patch that fixes wrong apostrophes in
> pinentry/secmem/secmem.c.
Thanks. Committed to revision 184.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From sutter at informatik.hs-furtwangen.de Thu Jul 24 15:06:37 2008
From: sutter at informatik.hs-furtwangen.de (Phil Sutter)
Date: Thu, 24 Jul 2008 15:06:37 +0200
Subject: sending large bulk data with assuan
Message-ID: <20080724130637.GB30370@base.freewrt>
Hi!
I want to send about 3.5kBytes of bulk data using assuan_send_data() on
the server side. On client side this is triggered using
assuan_transact() and a data callback function.
The problem here is the callback function only receives the first line
of data (996 Bytes). Though when I talk assuan directly to the server
(i.e. executing it and typing the commands manually) I get four lines of
data (prefixed with "D") and then a final "OK".
The data being transfered is just a long string of (uppercase) hex
chars, so no escaping should be necessary.
Do you have any idea why this happens or what I'm doing wrong? Sadly,
the Assuan Infopage isn't too verbose about this particular topic, and
searching the GnuPG code didn't reveal any special magic when doing bulk
data transfers.
Greetings, Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From sutter at informatik.hs-furtwangen.de Fri Jul 25 16:37:08 2008
From: sutter at informatik.hs-furtwangen.de (Phil Sutter)
Date: Fri, 25 Jul 2008 16:37:08 +0200
Subject: sending large bulk data with assuan
In-Reply-To: <20080724130637.GB30370@base.freewrt>
References: <20080724130637.GB30370@base.freewrt>
Message-ID: <20080725143708.GB19168@base.freewrt>
Hi,
On Thu, Jul 24, 2008 at 03:06:37PM +0200, Phil Sutter wrote:
> The problem here is the callback function only receives the first line
> of data (996 Bytes). Though when I talk assuan directly to the server
> (i.e. executing it and typing the commands manually) I get four lines of
> data (prefixed with "D") and then a final "OK".
Ok, forget it. I already knew that the callback functions have to return
zero to indicate everything is fine. Though having a statement like
this:
| return (write(fd, buf, len) == len);
is a very bad idea.
Sorry for the traffic these mails generated. ;)
Greetings, Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From sutter at informatik.hs-furtwangen.de Mon Jul 28 16:55:13 2008
From: sutter at informatik.hs-furtwangen.de (Phil Sutter)
Date: Mon, 28 Jul 2008 16:55:13 +0200
Subject: equivalent to encrypt_filter for decryption
Message-ID: <20080728145513.GB13241@base.freewrt>
Hi!
For encrypting generated shares I had a look at sign_file() in
g10/sign.c, which uses the encrypt_filter and now have basic code
encrypting internally available data when writing it out.
The function encode_crypt() in g10/encode.c doesn't use this filter
although it's actually encrypting data, is this because of historical
reasons?
Now when searching for an appropriate method for decrypting given shares
for recombination I looked at decrypt_message() in g10/decrypt.c and it
seems to be getting really ugly now: do_proc_encryption_packets() is
quite a bunch of code, decrypting data to either opt.outfile or stdout;
But I need the decrypted data internally to send it to the combiner.
Is there any way doing this without reinventing the wheel? I mean,
before I start copying much code only to change certain bits or hacking
up the existing functions (which seems non-trivial here) I find it more
useful to leave it to the user doing the en-/decryption on commandline
(e.g. via pipe: "gpg -d share.pgp | gpg --add-share").
Greetings, Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From wk at gnupg.org Mon Jul 28 18:10:33 2008
From: wk at gnupg.org (Werner Koch)
Date: Mon, 28 Jul 2008 18:10:33 +0200
Subject: sending large bulk data with assuan
In-Reply-To: <20080725143708.GB19168@base.freewrt> (Phil Sutter's message of
"Fri, 25 Jul 2008 16:37:08 +0200")
References: <20080724130637.GB30370@base.freewrt>
<20080725143708.GB19168@base.freewrt>
Message-ID: <87zlo22dmu.fsf@wheatstone.g10code.de>
On Fri, 25 Jul 2008 16:37, sutter at informatik.hs-furtwangen.de said:
> Sorry for the traffic these mails generated. ;)
Such mails are often a good resource for people to find answers on their
questions without asking. Thus no need to be sorry about sending
questions and figuring out the answer yourself (but let the list know
the solution).
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From thijs at debian.org Tue Jul 29 13:12:49 2008
From: thijs at debian.org (Thijs Kinkhorst)
Date: Tue, 29 Jul 2008 13:12:49 +0200
Subject: revision 4603 has reverted 4547?
Message-ID: <200807291312.53537.thijs@debian.org>
Hi,
SVN revision 4547 was applied to fix bug #810:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4547&r1=4538&r2=4547
however, it seems that revision 4603 undoes the change:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4603&r1=4594&r2=4603
I'm not sure if that was intentional, but at least in 1.4.9 I'm
experiencing the bug described in #810 again: build fails when using
--enable-minimal in the exact same way.
cheers,
Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL:
From marcus.brinkmann at ruhr-uni-bochum.de Thu Jul 31 02:49:41 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Thu, 31 Jul 2008 02:49:41 +0200
Subject: gpgme_data_new_from_mem works, gpgme_data_write doesn't
In-Reply-To: <20080706221010.GC699@denkbrett.schottelius.org>
References: <20080706221010.GC699@denkbrett.schottelius.org>
Message-ID: <87abfy27yy.wl%marcus.brinkmann@ruhr-uni-bochum.de>
At Mon, 7 Jul 2008 00:10:10 +0200,
Nico Schottelius wrote:
>
> [1 ]
> [1.1 ]
> Hello!
>
> I am testing around with gpgme and it seems I am doing something
> wrong with gpgme_data_write():
>
> If I do
>
> gerr = gpgme_data_new(&g_test);
> if(gerr != GPG_ERR_NO_ERROR) return 20;
> i = strlen(b_encrypt);
>
> /* THIS WORKS */
> gerr = gpgme_data_new_from_mem(&g_encrypt_send, b_encrypt, i, 1);
> if(gerr != GPG_ERR_NO_ERROR) return 24;
>
> /* decrypt: from gpgme_data_new_from_mem() */
> gerr = gpgme_op_decrypt(g_context, g_encrypt_send, g_plain_recv);
> if(gerr != GPG_ERR_NO_ERROR) {
> printf("gerr=%d\n",gerr);
> return 19;
> }
>
>
> it works. If I do
>
> gerr = gpgme_data_new(&g_test);
> if(gerr != GPG_ERR_NO_ERROR) return 20;
> i = strlen(b_encrypt);
> printf("strlen(%s) = %d\n",b_encrypt,i);
>
> /* THIS DOES NOT WORK */
> tmp = gpgme_data_write(g_test, b_encrypt, i);
> printf("gpgmedatawrite: %d\n", tmp);
>
> /* decrypt: from gpgme_data_write() */
> gerr = gpgme_op_decrypt(g_context, g_test, g_plain_recv2);
> if(gerr != GPG_ERR_NO_ERROR) {
> printf("gerr=%d\n",gerr);
> return 41;
> }
>
> it does *NOT* work.
As I wrote before: "gpgme data objects have a file pointer that must
be rewound to read written data (gpgme_data_seek). To use the seek
function make sure you compile with large file support. See the
documentation."
The gpgme_data_write() above works just fine, but after it the file
pointer is at the end of the data, and the gpgme_op_decrypt sees an
empty data buffer:
g_test: some-data
^
| "file" pointer
You need to rewind the file pointer to the beginning after
gpgme_data_write. Please see the documentation, and take notice of
the large file support necessary when using gpgme_data_seek.
Thanks,
Marcus
From marcus.brinkmann at ruhr-uni-bochum.de Thu Jul 31 03:10:13 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Thu, 31 Jul 2008 03:10:13 +0200
Subject: BUG: gpgconf --apply-defaults seems to fail if it's in a
directory with a space
In-Reply-To: <488507C3.9010604@adammil.net>
References: <488507C3.9010604@adammil.net>
Message-ID: <878wvi270q.wl%marcus.brinkmann@ruhr-uni-bochum.de>
At Mon, 21 Jul 2008 15:03:47 -0700,
Adam Milazzo wrote:
>
> Looks like it's invoking the shell without quoting the program to run,
> or something like that:
>
> C:\Program Files\GNU\GnuPG>gpgconf --apply-defaults
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
> gpgconf: Option gpgconf-gpg.conf, needed by backend GnuPG, was not
> initialized
> gpgconf: fatal error (exit status 1)
I can not reproduce this with 2.0.10-svn4797 included in recent
gpg4win beta versions.
Thanks,
Marcus
From marcus.brinkmann at ruhr-uni-bochum.de Thu Jul 31 03:15:38 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Thu, 31 Jul 2008 03:15:38 +0200
Subject: BUG: gpg 1.4.9 crashes when creating ELG keys with sign and
encrypt capability in batch mode
In-Reply-To: <48783DD5.5020109@adammil.net>
References: <48783DD5.5020109@adammil.net>
Message-ID: <877ib226rp.wl%marcus.brinkmann@ruhr-uni-bochum.de>
At Fri, 11 Jul 2008 22:15:01 -0700,
Adam Milazzo wrote:
>
> I think you're not supposed to use ElGamal keys that can sign and
> encrypt, but GPG shouldn't crash in any case. This crash happens
> consistently.
Well, at least it is a controlled termination. I suppose the idea is
that the caller has already checked the input.
Thanks,
Marcus
From wk at gnupg.org Thu Jul 31 14:51:45 2008
From: wk at gnupg.org (Werner Koch)
Date: Thu, 31 Jul 2008 14:51:45 +0200
Subject: [Announce] Dirmngr 1.0.2 released
Message-ID: <87r69ajjxa.fsf@wheatstone.g10code.de>
Hi!
We are pleased to announce the availability of Dirmngr version 1.0.2.
Dirmngr is a server for managing and downloading certificate
revocation lists (CRLs) for X.509 certificates and for downloading the
certificates themselves. Dirmngr also handles OCSP requests as an
alternative to CRLs. Although Dirmngr can be invoked on demand, it
should in general be installed as a system daemon.
Get it from:
ftp://ftp.gnupg.org/gcrypt/dirmngr/dirmngr-1.0.2.tar.bz2 (541k)
ftp://ftp.gnupg.org/gcrypt/dirmngr/dirmngr-1.0.2.tar.bz2.sig
or as a patch against the last beta version:
ftp://ftp.gnupg.org/gcrypt/dirmngr/dirmngr-1.0.1-1.0.2.diff.bz2 (144k)
SHA-1 checksums are:
55c82f918731f142cbe26d598a97c0c08bd7d1f8 dirmngr-1.0.2.tar.bz2
8d1482be8e8189aec726e0b20d66a3bcfd43e459 dirmngr-1.0.1-1.0.2.diff.bz2
Whats new in this release
=========================
* New option --url for the LOOKUP command and dirmngr-client.
* The LOOKUP command does now also consults the local cache. New
option --cache-only for it and --local for dirmngr-client.
* Port to Windows completed.
* Improved certificate chain construction.
* Support loading of PEM encoded CRLs via HTTP.
There is now also a collection of some useful certificates in the
doc/examples directory.
Documentation
=============
Dirmngr comes with man pages and as well as with a texinfo based
manual. Run "info dirmngr" to read the manual or run
make -C doc dirmngr.pdf
to build a printable version. If you have questions on the use of
Dirmngr, feel free to ask at gnupg-users at gnupg.org.
Support
=======
Improving Dirmngr is costly, but you can help! We are looking for
organizations that find Dirmngr useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or by
donating money.
Commercial support contracts for Dirmngr are available, and they help
finance continued maintenance. g10 Code GmbH, a Duesseldorf based
company owned and headed by GnuPG's principal author, is currently
funding Dirmngr development. We are always looking for interesting
development projects.
A service directory is available at:
http://www.gnupg.org/service.html
Thanks
======
We have to thank all the people who helped with this release. The
folks at Intevation helped a lot to track down bugs and to define new
features. Marcus Brinkmann is mainly responsible for completing the
Windows port.
Happy Hacking,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 205 bytes
Desc: not available
URL:
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce
From rdieter at math.unl.edu Thu Jul 31 17:52:14 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 31 Jul 2008 10:52:14 -0500
Subject: [Announce] Dirmngr 1.0.2 released
References: <87r69ajjxa.fsf__33608.8929245763$1217510912$gmane$org@wheatstone.g10code.de>
Message-ID:
Werner Koch wrote:
> We are pleased to announce the availability of Dirmngr version 1.0.2.
build fails here (fedora 8):
...
gcc -I../jnlib -O2 -Wall -o dirmngr-client dirmngr-client.o b64enc.o
get-path.o no-libgcrypt.o ../jnlib/libjnlib.a -lassuan -lgpg-error
crlcache.o:
In function `start_sig_check':
/var/tmp/BUILD/dirmngr-1.0.2/src/crlcache.c:1448: undefined reference to
`gcry_md_debug'
I suspect there's a minimal build dep not satisfied, I'm currently using:
libassuan-1.0.4
libgcrypt-1.2.4
libgpg-error-1.5
libksba-1.0.2
-- Rex
From wk at gnupg.org Thu Jul 31 18:26:47 2008
From: wk at gnupg.org (Werner Koch)
Date: Thu, 31 Jul 2008 18:26:47 +0200
Subject: [Announce] Dirmngr 1.0.2 released
In-Reply-To: (Rex Dieter's message of "Thu, 31
Jul 2008 10:52:14 -0500")
References: <87r69ajjxa.fsf__33608.8929245763$1217510912$gmane$org@wheatstone.g10code.de>
Message-ID: <87bq0eggu0.fsf@wheatstone.g10code.de>
On Thu, 31 Jul 2008 17:52, rdieter at math.unl.edu said:
> In function `start_sig_check':
> /var/tmp/BUILD/dirmngr-1.0.2/src/crlcache.c:1448: undefined reference to
> `gcry_md_debug'
Ooops. However, this is easy to fix:
Index: src/crlcache.c
===================================================================
--- src/crlcache.c (revision 304)
+++ src/crlcache.c (working copy)
@@ -1445,7 +1445,13 @@
return err;
}
if (DBG_HASHING)
- gcry_md_debug (*md, "crl");
+ {
+#ifdef HAVE_GCRY_MD_DEBUG
+ gcry_md_debug (*md, "hash.cert");
+#else
+ gcry_md_start_debug (*md, "crl");
+#endif
+ }
ksba_crl_set_hash_function (crl, HASH_FNC, *md);
return 0;
Most developers today use libgcrypt 1.4 but I hesitated to make this a
requirement as too many installations are running 1.2.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
From sutter at informatik.hs-furtwangen.de Thu Jul 31 21:38:24 2008
From: sutter at informatik.hs-furtwangen.de (Phil Sutter)
Date: Thu, 31 Jul 2008 21:38:24 +0200
Subject: Secret-Sharing: changes to existing code
Message-ID: <20080731193824.GC11056@base.freewrt>
Hi!
After solving my "decrypt shares to internal buffer" issue my proof of
concept code now provides all the functionalities I wanted to be
available before considering it the right way to go. So with my patched
version of gpg I can:
* setup an existing secret key for being shared (N is the threshold)
| gpg --ss-setup
* generate encrypted shares for an existing session
| gpg -r -o sharefile --gen-share
* list information about a share file
| gpg --list-packets sharefile
* list information about "open" sharing/recombining sessions
| gpg --ss-info
* add a share for recombination
| gpg --ss-add-share sharefile
* clear sharing/recombining metadata
| gpg --ss-clear
for now, there is no command for explicitly solving a recombining
session, as this is done each time after adding a share. The combiner is
able to detect whether the secret is already found or not. If so, the
secret data is being sent to gpg and imported to the secret keyring.
There are more features I could think of:
* a way for participants to store shares, and a command to prepare a
share for sending it to the combiner (i.e. de- and encrypting it)
* finer grained control about what data to clear with --ss-clear
(including removal of the secret key itself from the keyring)
* maybe some way to automate recombining shares via network (perhaps a
task for gpg-server?)
* maybe usage of these key-stubs and minimising the data being shared to
only the secret key params
but as I have to finish my diploma thesis first, from now on I will
concentrate on writing. Meanwhile I start sending in code for being
reviewed. The attachment contains only the changes to the existing files
to keep it simple for now. The rest will follow in chunks after I have
fixed all your concerns with this one.
Greetings, Phil
PS: something in advance: it may well be possible that I messed up
indentation in some cases, as it actually is not very consistent
throughout the existing code.
-------------- next part --------------
Index: configure.ac
===================================================================
--- configure.ac (revision 4803)
+++ configure.ac (working copy)
@@ -132,6 +132,13 @@ AM_CONDITIONAL(GNUPG_SCDAEMON_PGM, test -n "$GNUPG
show_gnupg_scdaemon_pgm="(default)"
test -n "$GNUPG_SCDAEMON_PGM" && show_gnupg_scdaemon_pgm="$GNUPG_SCDAEMON_PGM"
+AC_ARG_WITH(ssd-pgm,
+ [ --with-ssd-pgm=PATH Use PATH as the default for ssd)],
+ GNUPG_SSD_PGM="$withval", GNUPG_SSD_PGM="" )
+AC_SUBST(GNUPG_SSD_PGM)
+AM_CONDITIONAL(GNUPG_SSD_PGM, test -n "$GNUPG_SSD_PGM")
+show_gnupg_ssd_pgm="(default)"
+test -n "$GNUPG_SSD_PGM" && show_gnupg_ssd_pgm="$GNUPG_SSD_PGM"
AC_ARG_WITH(dirmngr-pgm,
[ --with-dirmngr-pgm=PATH Use PATH as the default for the dirmngr)],
@@ -158,6 +165,14 @@ AC_ARG_ENABLE(agent-only,
AC_HELP_STRING([--enable-agent-only],[build only the gpg-agent]),
build_agent_only=$enableval)
+# Enable secret-sharing
+AC_MSG_CHECKING([whether to enable secret-sharing])
+AC_ARG_ENABLE(secret-sharing,
+ AC_HELP_STRING([--enable-secret-sharing],
+ [Enable secret-sharing and build ssd]),
+ secret_sharing=$enableval, secret_sharing=no)
+AC_MSG_RESULT($secret_sharing)
+
# SELinux support includes tracking of sensitive files to avoid
# leaking their contents through processing these files by gpg itself
AC_MSG_CHECKING([whether SELinux support is requested])
@@ -971,6 +986,12 @@ if test "$selinux_support" = yes ; then
AC_DEFINE(ENABLE_SELINUX_HACKS,1,[Define to enable SELinux support])
fi
+#
+# support for Secret-Sharing
+#
+if test "$secret_sharing" = yes ; then
+ AC_DEFINE(ENABLE_SECRET_SHARING,1,[Define to enable Secret-Sharing])
+fi
#
# Checks for header files.
@@ -1332,11 +1353,16 @@ if test "$build_scdaemon" = "yes"; then
fi
fi
+if test "$enable_secret_sharing" = "yes" ; then
+ build_ssd=yes
+fi
+
if test "$build_agent_only" = "yes" ; then
build_gpg=no
build_gpgsm=no
build_scdaemon=no
+ build_ssd=no
build_tools=no
build_doc=no
fi
@@ -1346,6 +1372,7 @@ AM_CONDITIONAL(BUILD_GPG, test "$build_gpg" = "y
AM_CONDITIONAL(BUILD_GPGSM, test "$build_gpgsm" = "yes")
AM_CONDITIONAL(BUILD_AGENT, test "$build_agent" = "yes")
AM_CONDITIONAL(BUILD_SCDAEMON, test "$build_scdaemon" = "yes")
+AM_CONDITIONAL(BUILD_SSD, test "$build_ssd" = "yes")
AM_CONDITIONAL(BUILD_TOOLS, test "$build_tools" = "yes")
AM_CONDITIONAL(BUILD_DOC, test "$build_doc" = "yes")
AM_CONDITIONAL(BUILD_SYMCRYPTRUN, test "$build_symcryptrun" = "yes")
@@ -1436,6 +1463,7 @@ g10/Makefile
sm/Makefile
agent/Makefile
scd/Makefile
+ssd/Makefile
keyserver/Makefile
keyserver/gpg2keys_mailto
keyserver/gpg2keys_test
@@ -1458,11 +1486,13 @@ echo "
S/MIME: $build_gpgsm
Agent: $build_agent $build_agent_threaded
Smartcard: $build_scdaemon $build_scdaemon_extra
+ Secret-Sharing: $enable_secret_sharing
Protect tool: $show_gnupg_protect_tool_pgm
Default agent: $show_gnupg_agent_pgm
Default pinentry: $show_gnupg_pinentry_pgm
Default scdaemon: $show_gnupg_scdaemon_pgm
+ Default ssd: $show_gnupg_ssd_pgm
Default dirmngr: $show_gnupg_dirmngr_pgm
"
if test x"$use_regex" != xyes ; then
Index: g10/encr-data.c
===================================================================
--- g10/encr-data.c (revision 4803)
+++ g10/encr-data.c (working copy)
@@ -72,7 +72,8 @@ release_dfx_context (decode_filter_ctx_t dfx)
* Decrypt the data, specified by ED with the key DEK.
*/
int
-decrypt_data( void *procctx, PKT_encrypted *ed, DEK *dek )
+decrypt_data( void *procctx, PKT_encrypted *ed,
+ DEK *dek, int (*callback)(iobuf_t, void *) )
{
decode_filter_ctx_t dfx;
byte *p;
@@ -187,7 +188,10 @@ int
else
iobuf_push_filter ( ed->buf, decode_filter, dfx );
- proc_packets ( procctx, ed->buf );
+ if ( callback )
+ callback ( ed->buf, procctx );
+ else
+ proc_packets ( procctx, ed->buf );
ed->buf = NULL;
if ( ed->mdc_method && dfx->eof_seen == 2 )
rc = gpg_error (GPG_ERR_INV_PACKET);
Index: g10/gpgv.c
===================================================================
--- g10/gpgv.c (revision 4803)
+++ g10/gpgv.c (working copy)
@@ -303,7 +303,8 @@ get_override_session_key( DEK *dek, const char *st
}
/* Stub: */
int
-decrypt_data( void *procctx, PKT_encrypted *ed, DEK *dek )
+decrypt_data( void *procctx, PKT_encrypted *ed, DEK *dek,
+ int (*callback)(iobuf_t, void *) )
{
return G10ERR_GENERAL;
}
@@ -383,3 +384,7 @@ void destroy_dotlock (DOTLOCK h) {}
int make_dotlock( DOTLOCK h, long timeout ) { return 0;}
int release_dotlock( DOTLOCK h ) {return 0;}
void remove_lockfiles(void) {}
+
+/* Stubs to avoid linking to call-ssd.c */
+int ssd_put_share(u32 *keyid, void *data, u32 len) { return 0; }
+
Index: g10/mainproc.c
===================================================================
--- g10/mainproc.c (revision 4803)
+++ g10/mainproc.c (working copy)
@@ -63,6 +63,7 @@ struct mainproc_context
md_filter_context_t mfx;
int sigs_only; /* Process only signatures and reject all other stuff. */
int encrypt_only; /* Process only encryption messages. */
+ int shares_only; /* Process only gpg shares (ignored else) */
/* Name of the file with the complete signature or the file with the
detached signature. This is currently only used to deduce the
@@ -480,7 +481,13 @@ print_pkenc_list( struct kidlist_item *list, int f
}
}
+static int
+proc_gpg_share_cb( IOBUF a, void *info )
+{
+ return proc_gpg_share_packets( info, a );
+}
+
static void
proc_encrypted( CTX c, PACKET *pkt )
{
@@ -555,8 +562,11 @@ proc_encrypted( CTX c, PACKET *pkt )
}
else if( !c->dek )
result = G10ERR_NO_SECKEY;
- if( !result )
- result = decrypt_data( c, pkt->pkt.encrypted, c->dek );
+ if( !result && c->shares_only )
+ result = decrypt_data( c, pkt->pkt.encrypted,
+ c->dek, proc_gpg_share_cb);
+ else if ( !result )
+ result = decrypt_data( c, pkt->pkt.encrypted, c->dek, NULL );
if( result == -1 )
;
@@ -767,6 +777,8 @@ proc_compressed( CTX c, PACKET *pkt )
rc = handle_compressed( c, zd, proc_compressed_cb, c );
else if( c->encrypt_only )
rc = handle_compressed( c, zd, proc_encrypt_cb, c );
+ else if( c->shares_only )
+ rc = handle_compressed( c, zd, proc_gpg_share_cb, c );
else
rc = handle_compressed( c, zd, NULL, NULL );
if( rc )
@@ -775,6 +787,16 @@ proc_compressed( CTX c, PACKET *pkt )
c->last_was_session_key = 0;
}
+static void
+proc_gpg_share( CTX c, PACKET *pkt)
+{
+ PKT_gpg_share *sh = pkt->pkt.gpg_share;
+ printf("proc_gpg_share(): handling packet of type %d\n", pkt->pkttype);
+
+ handle_share(c, sh);
+ free_packet(pkt);
+}
+
/****************
* check the signature
* Returns: 0 = valid signature or an error code
@@ -1256,6 +1278,18 @@ proc_encryption_packets( void *anchor, IOBUF a )
return rc;
}
+int
+proc_gpg_share_packets( void *anchor, IOBUF a )
+{
+ CTX c = xmalloc_clear( sizeof *c );
+ int rc;
+
+ c->anchor = anchor;
+ c->shares_only = 1;
+ rc = do_proc_packets( c, a );
+ xfree( c );
+ return rc;
+}
int
do_proc_packets( CTX c, IOBUF a )
@@ -1329,6 +1363,27 @@ do_proc_packets( CTX c, IOBUF a )
default: newpkt = 0; break;
}
}
+ else if( c->shares_only ) {
+ switch( pkt->pkttype ) {
+ case PKT_PUBLIC_KEY:
+ case PKT_SECRET_KEY:
+ case PKT_USER_ID:
+ case PKT_PLAINTEXT:
+ case PKT_SIGNATURE:
+ case PKT_SYMKEY_ENC:
+ case PKT_ONEPASS_SIG:
+ case PKT_GPG_CONTROL:
+ write_status_text( STATUS_UNEXPECTED, "0" );
+ rc = G10ERR_UNEXPECTED;
+ goto leave;
+ case PKT_PUBKEY_ENC: proc_pubkey_enc( c, pkt ); break;
+ case PKT_ENCRYPTED:
+ case PKT_ENCRYPTED_MDC: proc_encrypted( c, pkt ); break;
+ case PKT_COMPRESSED: proc_compressed( c, pkt ); break;
+ case PKT_GPG_SHARE: proc_gpg_share(c, pkt); break;
+ default: newpkt = 0; break;
+ }
+ }
else {
switch( pkt->pkttype ) {
case PKT_PUBLIC_KEY:
Index: g10/build-packet.c
===================================================================
--- g10/build-packet.c (revision 4803)
+++ g10/build-packet.c (working copy)
@@ -41,6 +41,7 @@ static int do_symkey_enc( IOBUF out, int ctb, PKT_
static int do_pubkey_enc( IOBUF out, int ctb, PKT_pubkey_enc *enc );
static u32 calc_plaintext( PKT_plaintext *pt );
static int do_plaintext( IOBUF out, int ctb, PKT_plaintext *pt );
+static int do_gpg_share( IOBUF out, int ctb, PKT_gpg_share *sh );
static int do_encrypted( IOBUF out, int ctb, PKT_encrypted *ed );
static int do_encrypted_mdc( IOBUF out, int ctb, PKT_encrypted *ed );
static int do_compressed( IOBUF out, int ctb, PKT_compressed *cd );
@@ -122,6 +123,9 @@ build_packet( IOBUF out, PACKET *pkt )
case PKT_PLAINTEXT:
rc = do_plaintext( out, ctb, pkt->pkt.plaintext );
break;
+ case PKT_GPG_SHARE:
+ rc = do_gpg_share( out, ctb, pkt->pkt.gpg_share );
+ break;
case PKT_ENCRYPTED:
rc = do_encrypted( out, ctb, pkt->pkt.encrypted );
break;
@@ -549,6 +553,17 @@ do_plaintext( IOBUF out, int ctb, PKT_plaintext *p
return rc;
}
+static int
+do_gpg_share( IOBUF out, int ctb, PKT_gpg_share *sh )
+{
+ int rc;
+
+ write_header(out, ctb, calc_gpg_share_len(sh));
+ if ((rc = write_gpg_share_pkt(out, sh)))
+ log_error("do_gpg_share(): could not write share packet: %s\n",
+ gpg_strerror(rc));
+ return rc;
+}
static int
Index: g10/parse-packet.c
===================================================================
--- g10/parse-packet.c (revision 4803)
+++ g10/parse-packet.c (working copy)
@@ -77,6 +77,8 @@ static int parse_mdc( IOBUF inp, int pkttype, uns
PACKET *packet, int new_ctb);
static int parse_gpg_control( IOBUF inp, int pkttype, unsigned long pktlen,
PACKET *packet, int partial );
+static int parse_gpg_share( IOBUF inp, int pkttype, unsigned long pktlen,
+ PACKET *packet, int partial );
static unsigned short
read_16(IOBUF inp)
@@ -578,6 +580,9 @@ parse( IOBUF inp, PACKET *pkt, int onlykeypkts, of
case PKT_GPG_CONTROL:
rc = parse_gpg_control(inp, pkttype, pktlen, pkt, partial );
break;
+ case PKT_GPG_SHARE:
+ rc = parse_gpg_share( inp, pkttype, pktlen, pkt, partial );
+ break;
case PKT_MARKER:
rc = parse_marker(inp,pkttype,pktlen);
break;
@@ -2425,6 +2430,25 @@ parse_mdc( IOBUF inp, int pkttype, unsigned long p
return rc;
}
+static int
+parse_gpg_share(iobuf_t inp, int pkttype,
+ unsigned long pktlen, PACKET *packet, int partial)
+{
+ PKT_gpg_share *sh;
+
+ packet->pkt.gpg_share = read_gpg_share_pkt(inp, pktlen);
+ if ((sh = packet->pkt.gpg_share) == NULL) {
+ log_error("reading share packet failed\n");
+ return gpg_error(GPG_ERR_INV_PACKET);
+ }
+
+ if (list_mode) {
+ fprintf(listfp, ":gpg share:\n\tkeyid: %08x%08x\n\tshare "
+ "number: %u\n\tlength: %u\n", sh->keyid[0],
+ sh->keyid[1], sh->id, sh->len);
+ }
+ return 0;
+}
/*
* This packet is internally generated by PGG (by armor.c) to
Index: g10/packet.h
===================================================================
--- g10/packet.h (revision 4803)
+++ g10/packet.h (working copy)
@@ -318,6 +318,13 @@ typedef struct {
} PKT_plaintext;
typedef struct {
+ u32 len; /* length of share data */
+ u32 keyid[2]; /* ID of shared key */
+ unsigned char id; /* session internal ID of share */
+ char data[1]; /* share data */
+} PKT_gpg_share;
+
+typedef struct {
int control;
size_t datalen;
char data[1];
@@ -341,6 +348,7 @@ struct packet_struct {
PKT_mdc *mdc; /* PKT_MDC */
PKT_ring_trust *ring_trust; /* PKT_RING_TRUST */
PKT_plaintext *plaintext; /* PKT_PLAINTEXT */
+ PKT_gpg_share *gpg_share; /* PKT_GPG_SHARE */
PKT_gpg_control *gpg_control; /* PKT_GPG_CONTROL */
} pkt;
};
@@ -372,6 +380,7 @@ int proc_signature_packets( void *ctx, iobuf_t a,
strlist_t signedfiles, const char *sigfile );
int proc_signature_packets_by_fd ( void *anchor, IOBUF a, int signed_data_fd );
int proc_encryption_packets( void *ctx, iobuf_t a );
+int proc_gpg_share_packets( void *ctx, iobuf_t a );
int list_packets( iobuf_t a );
/*-- parse-packet.c --*/
@@ -484,7 +493,8 @@ int handle_compressed( void *ctx, PKT_compressed *
int (*callback)(iobuf_t, void *), void *passthru );
/*-- encr-data.c --*/
-int decrypt_data( void *ctx, PKT_encrypted *ed, DEK *dek );
+int decrypt_data( void *ctx, PKT_encrypted *ed, DEK *dek,
+ int (*callback)(iobuf_t, void *));
/*-- plaintext.c --*/
int handle_plaintext( PKT_plaintext *pt, md_filter_context_t *mfx,
@@ -511,4 +521,10 @@ int update_keysig_packet( PKT_signature **ret_sig,
/*-- keygen.c --*/
PKT_user_id *generate_user_id(void);
+/*-- share.c --*/
+u32 calc_gpg_share_len(PKT_gpg_share *);
+void handle_share(void *, PKT_gpg_share *);
+int write_gpg_share_pkt(iobuf_t, PKT_gpg_share *);
+PKT_gpg_share *read_gpg_share_pkt(iobuf_t, unsigned long);
+
#endif /*G10_PACKET_H*/
Index: g10/gpg.c
===================================================================
--- g10/gpg.c (revision 4803)
+++ g10/gpg.c (working copy)
@@ -53,6 +53,7 @@
#include "keyserver-internal.h"
#include "exec.h"
#include "gc-opt-flags.h"
+#include "secret-sharing.h"
#if defined(HAVE_DOSISH_SYSTEM) || defined(__CYGWIN__)
#define MY_O_BINARY O_BINARY
@@ -147,6 +148,11 @@ enum cmd_and_opt_values
aCardEdit,
aChangePIN,
aServer,
+ aSSSetup,
+ aSSInfo,
+ aSSAddShare,
+ aSSGenShare,
+ aSSClear,
oTextmode,
oNoTextmode,
@@ -431,6 +437,11 @@ static ARGPARSE_OPTS opts[] = {
{ aPrimegen, "gen-prime" , 256, "@" },
{ aGenRandom, "gen-random", 256, "@" },
{ aServer, "server", 256, N_("run in server mode")},
+ { aSSSetup, "ss-setup", 0, N_("setup a new secret-sharing")},
+ { aSSInfo, "ss-info", 0, N_("retrieve info about secret-sharing")},
+ { aSSAddShare, "ss-add-share", 0, N_("add a share to the combiner")},
+ { aSSGenShare, "ss-gen-share", 0, N_("generate a new share")},
+ { aSSClear, "ss-clear", 0, N_("clear secret-sharing metadata for a key")},
{ 301, NULL, 0, N_("@\nOptions:\n ") },
@@ -2158,6 +2169,21 @@ main (int argc, char **argv)
set_cmd (&cmd, pargs.r_opt);
opt.batch = 1;
break;
+ case aSSSetup:
+ set_cmd (&cmd, pargs.r_opt);
+ break;
+ case aSSInfo:
+ set_cmd (&cmd, pargs.r_opt);
+ break;
+ case aSSAddShare:
+ set_cmd (&cmd, pargs.r_opt);
+ break;
+ case aSSGenShare:
+ set_cmd (&cmd, pargs.r_opt);
+ break;
+ case aSSClear:
+ set_cmd (&cmd, pargs.r_opt);
+ break;
case oArmor: opt.armor = 1; opt.no_armor=0; break;
case oOutput: opt.outfile = pargs.r.ret_str; break;
@@ -3937,6 +3963,47 @@ main (int argc, char **argv)
xfree(str);
}
break;
+ case aSSSetup:
+ if (argc != 2)
+ wrong_args("--ss-setup Threshold KeyID");
+ {
+ int thold;
+ char *endptr;
+ thold = strtol(*argv, &endptr, 10);
+ if (strlen(endptr) || thold < 2)
+ log_error("Threshold needs to be >= 2\n");
+ else
+ ss_setup(thold, *(argv + 1));
+ }
+ //printf("would now setup Secret Sharing for %s\n", *argv);
+ break;
+ case aSSInfo:
+ if (argc > 1)
+ wrong_args("--ss-info [KeyID]");
+ if (argc)
+ ss_info(*argv);
+ else
+ ss_info(NULL);
+ break;
+ case aSSAddShare:
+ if (!argc)
+ wrong_args("--ss-add-share filename [filename ...]");
+ {
+ int i;
+ for (i = 0; i < argc; i++)
+ ss_put_share(argv[i]);
+ }
+ break;
+ case aSSGenShare:
+ if (argc != 1)
+ wrong_args("--ss-gen-share KeyID");
+ ss_gen_share(*argv, remusr, opt.outfile);
+ break;
+ case aSSClear:
+ if (argc != 1)
+ wrong_args("--ss-clear KeyID");
+ ss_clear(*argv);
+ break;
case aListPackets:
opt.list_packets=2;
Index: g10/Makefile.am
===================================================================
--- g10/Makefile.am (revision 4803)
+++ g10/Makefile.am (working copy)
@@ -64,6 +64,7 @@ common_source = \
parse-packet.c \
cpr.c \
plaintext.c \
+ share.c \
sig-check.c \
keylist.c \
pkglue.c pkglue.h
@@ -100,7 +101,9 @@ gpg2_SOURCES = gpg.c \
photoid.c photoid.h \
call-agent.c call-agent.h \
card-util.c \
- exec.c exec.h
+ exec.c exec.h \
+ secret-sharing.c secret-sharing.h \
+ call-ssd.c call-ssd.h
gpgv2_SOURCES = gpgv.c \
$(common_source) \
Index: common/openpgpdefs.h
===================================================================
--- common/openpgpdefs.h (revision 4803)
+++ common/openpgpdefs.h (working copy)
@@ -43,6 +43,7 @@ typedef enum
PKT_ENCRYPTED_MDC = 18, /* Integrity protected encrypted data. */
PKT_MDC = 19, /* Manipulation detection code packet. */
PKT_COMMENT = 61, /* new comment packet (GnuPG specific). */
+ PKT_GPG_SHARE = 62, /* internal packet for transfering a share */
PKT_GPG_CONTROL = 63 /* internal control packet (GnuPG specific). */
}
pkttype_t;
Index: am/cmacros.am
===================================================================
--- am/cmacros.am (revision 4803)
+++ am/cmacros.am (working copy)
@@ -41,6 +41,9 @@ endif
if GNUPG_SCDAEMON_PGM
AM_CPPFLAGS += -DGNUPG_DEFAULT_SCDAEMON="\"@GNUPG_SCDAEMON_PGM@\""
endif
+if GNUPG_SSD_PGM
+AM_CPPFLAGS += -DGNUPG_DEFAULT_SSD="\"@GNUPG_SSD_PGM@\""
+endif
if GNUPG_DIRMNGR_PGM
AM_CPPFLAGS += -DGNUPG_DEFAULT_DIRMNGR="\"@GNUPG_DIRMNGR_PGM@\""
endif
Index: Makefile.am
===================================================================
--- Makefile.am (revision 4803)
+++ Makefile.am (working copy)
@@ -54,6 +54,11 @@ scd = scd
else
scd =
endif
+if BUILD_SSD
+ssd = ssd
+else
+ssd =
+endif
if BUILD_TOOLS
tools = tools
else
@@ -72,7 +77,7 @@ tests = tests
endif
SUBDIRS = m4 gl include jnlib common ${kbx} \
- ${gpg} ${keyserver} ${sm} ${agent} ${scd} ${tools} po ${doc} ${tests}
+ ${gpg} ${keyserver} ${sm} ${agent} ${scd} ${ssd} ${tools} po ${doc} ${tests}
dist_doc_DATA = README
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
From thijs at debian.org Mon Jul 28 17:31:06 2008
From: thijs at debian.org (Thijs Kinkhorst)
Date: Mon, 28 Jul 2008 15:31:06 -0000
Subject: revision 4603 has reverted 4547?
Message-ID: <30af9d3f364b174243b52041408ceb65.squirrel@wm.kinkhorst.nl>
Hi,
SVN revision 4547 was applied to fix bug #810:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4547&r1=4538&r2=4547
however, it seems that revision 4603 undoes the change:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4603&r1=4594&r2=4603
I'm not sure if that was intentional, but at least in 1.4.9 I'm
experiencing the bug described in #810 again: build fails when using
--enable-minimal in the exact same way.
cheers,
Thijs
From thijs at debian.org Mon Jul 28 17:33:57 2008
From: thijs at debian.org (Thijs Kinkhorst)
Date: Mon, 28 Jul 2008 15:33:57 -0000
Subject: revision 4603 has reverted 4547?
Message-ID: <200807281406.33074.thijs@debian.org>
Hi,
SVN revision 4547 was applied to fix bug #810:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4547&r1=4538&r2=4547
however, it seems that revision 4603 undoes the change:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4603&r1=4594&r2=4603
I'm not sure if that was intentional, but at least in 1.4.9 I'm
experiencing the bug described in #810 again: build fails when using
--enable-minimal in the exact same way.
cheers,
Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL: