Please send usage questions to the gnupg-users mailing list.
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Please send usage questions to the gnupg-users mailing list.
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Please send usage questions to the gnupg-users mailing list.
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Please send questions to the gnupg-users mailing list.
The answer, to your question, though, is no. GPG
implements OpenPGP, not PEM.

Done.

This is not a GnuPG bug, but a keyserver bug. GnuPG just
displays what the keyserver returns, and the keyserver is
returning the wrong thing.

Problem was resolved.

Done, thanks for the suggestion.
I also added better support for linking to libusb so people
can use the SCR335 readers (like me).
SCM does claim seem to have a 335 OS X driver, but I haven't
had any success using it.

This is not a bug. The EOF is required to terminate stdin
just like any file or pipe. If it didn't, then handling
large files would be impossible. GPG prompts for the
passphrase early on - but could continue reading gigabytes
of data before EOF.

No bug report.

What fascinates me about this is that some of the keyservers
have a robots.txt file that explicitly disallows indexing,
but yet Google is still indexing them. For example, pgp.nic.ad.jp

What does 'grep -i curl config.h' in the main gpg build directory show?

Fixed for 1.4.3.

I will look at this for a future version. In the meantime,
note that if you set the environment variable HOME, tilde
expansion will work properly.

Compiler issue.

I'm afraid I don't see a bug here. You added 5 years to an
expired key, which made the 'next check' date 5 years from
that day. Were you expecting something else to happen?

I think there isn't much that can be done there without an ANSI C compiler. It looks like the HPUX bundled compiler just doesn't speak modern C.

From: "LANNY TAYLOR" <ltaylor@salliemae.com>
To: <dshaw@jabberwocky.com>
Cc: <bug-any@bugs.gnupg.org>, <gnupg-hackers@gnupg.org>,

<gnats-admin@trithemius.gnupg.org>

Subject: Re: gnupg/516
Date: Fri, 05 Aug 2005 14:43:15 -0500

This looks like a problem in gettext, rather than GnuPG. If
you don't need the translations (GnuPG will then be english
language only), try "configure --disable-nls"

1.4.3 has gpg-zip

Dupe of 508

See http://enigmail.mozdev.org/

Oddly enough, already fixed this morning. Patch sent to bug
reporter in email.

When PGP came out with this feature (it's actually a ported feature from their command line product),
I actually looked around for a tar library that we might use. Nothing was usable or portable enough. One of these days, I'll write a shell script that does "tar -xxxxx | gpg -xxxxx" with appropriate options.

This is the "make sure we've dropped root privs" assert.

This is a bug, but not a GPG bug. The keyserver is
returning garbage in its key listing. GPG doesn't do
anything to the garbage aside from quoting it so it doesn't
blow up the terminal. This is a known SKS keyserver bug
that has been fixed already.

From: Holger Hartmann <Holger_Hartmann@gmx.de>
To: bug-any@bugs.gnupg.org
Cc: gnupg-hackers@gnupg.org,
gnats-admin@trithemius.gnupg.org,
wk@gnupg.org
Subject: Re: gnupg/487
Date: Wed, 20 Jul 2005 19:18:20 +0200

From: David Shaw <dshaw@jabberwocky.com>
To: bug-any@bugs.gnupg.org
Cc: gnupg-hackers@gnupg.org, gnats-admin@trithemius.gnupg.org, wk@gnupg.org,

ms419@freezone.co.uk

Subject: Re: gnupg/458
Date: Thu, 2 Jun 2005 20:26:38 -0400

This is done.

It's not clear from the original mail if this is what he is referring to, but PGP Zip is a new feature in PGP that is an encrypted compressed archive.

Dupe of 491

Use --with-colons --list-config XXXXXX
Use "pubkey", "cipher", "digest", or "compress" for XXXXXX

The problem with this is that we don't have an auto-key-retrieve for key signatures. It's not even clear what such an option would do - fetch all signatures during a trust rebuild? I'm not sure we want such a thing.

The spamassassin folks are making --textmode signatures.
Since a tarball is not text, this isn't going to work too
well. I've sent them a note about it.

Yes, lets close it.

I've made a workaround for 1.4.1 - since PGP will try and
encrypt to the most recent subkey (regardless of the key
flags that tell it not to), I've arranged to put the
authentication subkey before the encryption subkey. This is
at best a workaround and does not fully fix the problem
(say, if the encryption subkey expires). The card does not
allow decrypting using the auth key, and it does not seem
practical or wise to extract the auth key material from the
card to decrypt such messages. It's up to the PGP folks now
. This is the same bug I reported to them back in 2003.

Amusingly enough, PGP will also quite happily encrypt to a RSA sign-only key.

This is a PGP bug - even the latest version will happily
encrypt to an authentication-only key. I will notify the
PGP people, and ponder some workarounds. I don't like the
idea to not export the auth key since it makes two different
exports (one for gpg users, one for pgp users) and that will
confuse people.

Known bug. Already fixed in 1.4.1. It's not completely
true that the keyserver preference is not updated - rather,
the new keyserver URL is added to the existing one so that
both are tried. This violates expectations, so it was changed.

This is an Enigmail problem. GnuPG does not deal with email
headers (indeed, it not even aware of email headers).

Please add a copy of the key exported from the 64-bit
machine and another copy of the key exported from the 32-bit
machine.

This is correct behavior. Use --s2k-digest to set the S2K
digest for both symmetric and asymmetric encryption.
--digest-algo is not meaningful for -c/--symmetric unless
you are using --symmetric --sign to make a signed symmetric
message.

Fixed.

Neil noted to me that this is 1.3.90, not 1.9.

Done

Done. I used 30 seconds by default.

This is what I was thinking as well (the alarm solution). It is different for each keyserver type since LDAP does in fact have a notion of a timeout already. In the other cases, just calling alarm() will do nicely. Do you know how portable this is to windows?

This is how RPM is supposed to remove the files. Not sure
why you had a problem.

Fixed in 1.2.3

Done.

GnuPG doesn't do any particular magic to archives. It's
just a binary blob, so it doesn't matter how many times you
compressed it first.

No further comments.

This fix is part of 1.4.

No further comments.

Most likely you copied the binary from somewhere else. You
don't have one of the libraries you need. If you compile it
locally, the build process will arrange for the missing
functions to be supplied.