Using GPGME should solve most of the problems.

Thanks for the info. I'll look more deeply into the --status-fd approach as
well as gpgme. I understand the desire to stay away from maintaining
application-specific error tables and serializing conditions into meaningful
return values, but to the shell script writer, the bread-and-butter of UNIX
environments, it is invaluable. Again, thanks for your info.

Return codes are not a good way to return non-boolean status information. In
particular not with a complicated tool like gpg. There are often several things
to consider when deciding whether a verification worked out. Packing this all
into an 8 bit (or well better just 7 bit) vector is not easy.

Solved by applying an exception to the ldap and curl helpers.

I have released 1.9.90 today. This includes the new features.

Thinking again about it I figured that most options are already available. The
--enable-agent-only is just a shortcut for --disable-gpg --disable-gpgsm
--disable-scdaemon. I have added new options --disable-tools and --disable-doc
to make them also configurable.

We currently work on a solution.

A possible feature would be to tag requests with the name of the process (e.g.
mutt). However, this is hard to implement as we need to change it at many
places and extra arguments are required.

groups are just a hack and have several problems as well. It is not gpg's task
to implement an addressbook or alike. If this is needed write a frontend to gpg
to do that.

Makes sense to me.

Supposedly fix. Otherwise, we need a new report stating where the link is.

Moved to
http://wald.intevation.org/tracker/index.php?func=detail&aid=166&group_id=13&atid=134

Moved to
http://wald.intevation.org/tracker/index.php?func=detail&aid=165&group_id=13&atid=134

There is a new key now.

There are intermittent problems with the ftp server at times. Sorry for the
inconvenience. It works today.

The ftp site seems to be up to date as of today.

Iconv is available in the same directory as the w32 binary package:
ftp://ftp.gnupg.org/gcrypt/binary/libiconv-1.9.1.dll.zip

This does not work. Under a standard GNU/Linux OS you don't have means
for a finer permission granularity that the one based on the UID.

This has been fixed in 1.9.21

We have by now created the gpg4win project, which contains binaries not only for gnupg and gpgme, but also for a couple of other packages. Please see www.gpg4win.org. Unfortunately, it is not easy to extract just the gpgme DLL from the package, but it is automatically installed if you install gpa or sylpheed. Not sure if this is sufficient for you.

I gave it a shot and spent half a day on it. No way, I can't update the preview window without updating the actual text of the message. Chaning all messages to "This is a PGP/MIME message" is probably not a good idea. Code is in the new version 0.9.9 but deactivated.

Can't be done.

Turns out that this is a lot of work. we need to add an
extra code path to check for PGP/MIME mails does not try to
decrypt/verify anything. Will take a day or so.

We tested gpg with a couple of readers but the state of the art is that despite the pc/sc specs man cominations of host software, drivers, readers and smart cards have problems. Pleae try a differnt driver for your reader or change the reader.

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.

The policy of the GNU project is not to link to any
proprietary software. GPGShell is proprietary.

Most issues are related to Enigmail. However we should see
whether we can provide error codes

Use the option
--use-embedded-filename
if you really want this. This has security implications,
though.

Done

From: Simon Richter <Simon.Richter@hogyros.de>
To: bugs@trithemius.gnupg.org
Cc: gnupg-hackers@gnupg.org, gnats-admin@trithemius.gnupg.org,
wk@gnupg.org
Subject: Re: gnupg/421
Date: Tue, 15 Mar 2005 23:07:38 +0100

Won't be implemented because there is no way to handle this
in gpgme.

Not sure whether this is a really a good idea. With gnupg
1.9 exporting a secret key will only be possible using a
special tool.

No bug and no reponse anymore

Cool idea.

I am not sure what you want to tellus with this bug report.
If you feel that the current translation is not correct,
please contact the author of that translation and discuss it
with him. We won't replace a translation without agreement
of the orginal translator. If you want to discuss this with
a wider community, please do so at the gnupg-i18n@gnupg.org ML.

We won't do that for security reasons and due to other ways
of providing a passphrase (cf. gpg-agent,
gpg-preset-passphrase). No reponse for 3 months either.

Another way to use make use of an environment variable is by wrtinig an appropriate passpharse callback for gpgme.