The manual is not maintained anymore and thus we don't apply fixes, sorry.

No DCO received, no review, won't apply. Sorry.

c) Run gpg-agent under gdb
d) Run a modified gpg-agent (rm ~/S.gpg-agent; my-gpg-agent --daemon)
e) Hook into the tty and use pinentry-curses
f) scp ~/.gnupg/private-keys-v1.d/* mybox: and sniff the passphrase.

so far, the proposed mechanisms for getting at gpg-agent's memory from a peer
process running as the same user are:

a) ptrace (e.g. via /usr/bin/gcore or /usr/bin/strace)
b) /proc/$PID/mem, which is owned by the user and mode 0600

DarkStarSword's patch effectively closes (a) (by rejecting ptrace connections)
and appears on my GNU/Linux system to close (b) as well: /proc/$PID/mem is
root-owned when the patch is applied instead of being user-owned.

Are there other channels for per-process memory access that we should be
thinking about?

I agree with Werner and Neal that the UNIX model is probably insufficient to
close all the holes easily, but i also don't think that's a good reason to avoid
closing those holes we can close.

If there are other ways that another process by the same user can get at the
RAM, please point them out and i'll look into ways to address them too.

In the meantime, i'll also look into ways to facilitate running the process as a
separate user account entirely.

1.4 won't handle such a redirection because it does not use libassuan.

2.0 should follow such a redirection but the 2.0 agent is not able to setup a
socket in this way. If there is a real need it can be backported.

So the implication here is that users who want to use XDG_RUNTIME_DIR can do:

echo '%Assuan%' > ~/.gnupg/S.gpg-agent
echo '${XDG_RUNTIME_DIR}/S.gpg-agent' >> ~/.gnupg/S.gpg-agent

and it will Just Work for those with an NFS homedir?

Even on non-NFS volumes, this has the nice property that gpg-agent's
"check-own-socket" feature should be able to close down the gpg-agent process
when it's no longer needed by an active session.

What would the failure conditions be if that variable isn't actually set,
though? I guess it would be the same as specifying /S.gpg-agent, which should
result in permission denied, which means a failed gpg-agent. Is that right?

Will 1.4.x or 2.0.x respect such a redirection if they find it in the socket
they're trying to talk to, or is this a 2.1.x-only feature?

Thr redirect feature has not yet been documented. You can create a regular file
with the name of the socket file using this format

   %Assuan%
   socket=NAME

   where NAME is the actual socket to use.  No white spaces are
   allowed, both lines must be terminated by a single LF, extra lines
   are not allowed.  Environment variables are interpreted in NAME if
   given in "${VAR} notation; no escape characters are defined, if
   "${" shall be used verbatim, you need to use an environment
   variable with that content.

   The use of an absolute NAME is strongly suggested.  The length of
   the file is limited to 511 bytes which is more than sufficient for
   that common value of 107 for sun_path.

and to be clear, I'm not suggesting not using ~/.gnupg at all anymore. I'm only
saying that using that as a default location for gpg-agent socket is bad for some
use-cases (like nfs $HOME)

what is this "redirect feature" you mention? how would that help a user logging
into multiple computers using the same (nfs) $HOME ?

Oh well, resizing the buttons to a new fixed size would be a job in the source
of 10 minutes or so. However, this makes an very ugly Pinentry for every day's
use (i.e. entering a passphrase for an existing key). So, sorry, I won't take
that patch.

With native Windows code I mean native Windows code for GUIs instead of relying
on MFC or whatever is the latest GUI framework MS uses. This is similar to xlib
programm vs. GTK+ programming

Anyway, thanks for looking into this. I will retitle the bug to keep it open.
Maybe eventually someone starts to hack on it.

Well, here's my fix. Using this neat little program I downloaded called
Resource Hacker, I edited the buttons on the dialog box so that they would
be big enough to display the messages needed. Realizing that pinentry.exe
and pinentry-w32.exe were identical files (checking them in a hex editor
with file comparison function showed them to be exactly the same), I just
copied my edited version of pinentry.exe and renamed the copy as
pinentry-w32.exe. I have put both of them in a zip file called
pinentry.zip, and have attached this zip file to this email. Feel free to
distribute this on the official GPG4Win website. Note that the file name of
the attachment is "piz" not "zip", so before you extract its contents (for
use, or posting on your website) you will need to rename it from "piz" back
to "zip". I had to rename it from "zip" to "piz" because otherwise Gmail's
mail server scans inside the zip file and then for blocks it because it
detects exe files (and exe files are a format that can potentially harbor
malware). Even though this has no malware (as you can see by scanning it
with a virus scanner), Google's mail server takes extra precautions by
refusing to allow sending of executable files or even archive files that
contain executable files.

As far as I know, GPG4Win is a compiling/linking of GPG to be Windows
compatible, which means that the code was already altered to work with
Windows. Therefore native Windows code is already in use in the GPG4Win
variant of GPG. Therefore it should work correctly in every respect in
Windows (including correctly sized buttons).

In 1.6.3, libgcrypt now work with automake >= 1.14.

See the commit: c123e313e90a6ffb14c9be3ddaab3ad44a44f2b6

I just verified that it is not a problem in 2.1.

I am not sure whether it makes sense to fix it in 1.4 given that it is easier to
change it with 2.1, export and import it then to 1.4. I feel it is better to
use my time to fix some missing export options in 2.1

It is known that the secret keyrings easily gets out of sync. Thus do not rely
on that information. Always use the public key ring for such info.

We won't fix that in < 2.1

MD5 is not used bu OpenPGP. It is allowed for backward compatibility but even
that has been dropped for GnuPG 2.1.

The use of SHA-1 fingerprints is hardwired into OpenPGP and to change this a
complete new key format needs to be specified. In any case the fingerprints
are not a problem right now.

Using Base64 fingerprints are actually a bad idea because they are to hard to
compare for a human.

P.S.
SHA512 probably would be the right thing. If someone's too lazy to compare such
a long fingerprint, he can still choose just to compare just one half of it.

Sure, a standard for that would be great.

MD5 is pretty much broken for security purposes and I would wonder, if that's
not also true in the context of OpenPGP.

You're probably much closer to the people responsible for the OpenPGP standard.
Are there any efforts to introduce SHA512-BASE64 fingerprints? (or at least SHA256)

OpenPGP does not specify this. It is actually not easy to add another format
becuase that opens the path for all kind of attacks. Like with ELF comment
section you can do the same for any other data format. No, there is no ELF
parser in gpg and there won't be one for any other language.

Please take this to the gnupg-users ML or to the OpenPGP WG. Thanks.

FYI, just adding a "Type ? for help." after "Invalid selection." would improve
the situation massively.

Really, which prompts are those?

$ sh
$ ?
sh: 1: ?: not found
$
127

$ ed
?
?
1

$ bash
$ ?
bash: ?: command not found
127

$ zsh
% ?
zsh: no matches found: ?
%
1

$ man man
?
Pattern not found (press RETURN)

$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
?
(standard_in) 1: illegal character: ?

$ gdb
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) ?
Undefined command: "". Try "help".
(gdb) quit

Fuck, even vi tells me "type :help<Enter> or <F1> for on-line help"

$ python
Python 2.7.8 (default, Sep 9 2014, 22:08:43)
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.

?

File "<stdin>", line 1
  ?
  ^

SyntaxError: invalid syntax

$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
λ: ?

<interactive>:2:1: parse error on input `?'
λ:
Leaving GHCi.

If you order such a docuemntation I'll be glad to add it. Contact me at my
company address.

You responded to my previous suggestions, and this is my next iteration, with me
trying to take into account your comments.

I find that making related options visually related, helps the user to better
intuitively understand what they do. The current options don't do this.

You also had a comment along the lines of "sign is not accurate because there's
also certify and authenticate", but a few current options also have this flaw. I
think it's OK, but it's better to do this consistently.

If "a complete documentation is not possible", then it is not fit for purpose as
an API to be scripted, and you should stop advertising that functionality in public.

If you do not have time to do this documentation, the correct response is to say
"I do not have time to do this", but leave the bug open, because it is something
to be resolved in the future.

An exposed public interface that you expressly suggested me to use in a script,
is *supposed* to have documentation associated with it. That is basic standard
software engineering. You don't see standard library authors respond with "just
try out the function to see what happens", when someone points out missing
documentation.

Nope. We discussed this already at the ML.

That is exactly the idea. Walk it through manually and you see what you need to
type. Adding docs bearks the risk that the docs is not in sync with the code
and thus we would need to run tests to make sure this is the case. The order of
the prompts depends on so many factors that a complete documentation si not
possible.

There are no known attacks on SHA-1. MD5 is disabled anyway in recent versions.
But please continue at gnupg-users - if you like.

Thank you for the prompt response.

I am familiar with the standard. The only violation of a MUST I'm aware of is that
recipient and personal digest preferences are ignored for hashes with known attacks;
perhaps some of these changes cause GnuPG to behave badly in other cases?

Won't happen. Please read the FAQ. IF you need to discuss this, please do that
at gnupg-users@

A user shall not use automake to build libgrypt.

I am very well aware of all the problems with newer automake versions. I try to
eventually mitigate the problems and the extra rules we have in some projects
might be helpful but a proper solution for automake would be to reverse the
default tests method to serial-tests. There are only a few projects with lots
of regression tests which benefit from the new default - those could easily
switch on parallel-tests. But I have seen no signs that they will revert it.

Eventually we need to add our own test driver - IIRC, recent automakes allow to
enable a custom test driver while still having build support by automake.

the tarball is OK, however, we must patch the autoconf[1], so we also use the
automake installed at user site which may be newer than 1.13.

it seems that this expression has no effect to 1.13 and damage the 1.14...

bench-slope.log: benchmark.log
hashtest-256g.log: bench-slope.log

you can close this issue, but know that it does exist in newer versions of
automake. if there is no real need for the above statements then removing them
resolves the issue.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-uscore.patch?revision=1.1&view=markup

I am confused:

Do you say that you have problems to build the tarball release? In that case I
can replicate the problem. FWIW, the 1.6.1 release has been build with automake
1.11 and I am pretty sure that this was also the case for 1.6.0.
From the top Makefile.in:

Makefile.in generated by automake 1.11.6 from Makefile.am.

So, why do you need autoreconf to fix a problem with parallel tests? automake
1.11 does not generate such test rules.

That was added because we have it in master.

Have 'it'? I see it in the tarball of 1.6.

Again: If you do not use the tarball release do not expect that pacthes will

be included. You should never do autoreconf.

We do use the tarball release, and we must patch it to resolve issues you do not
handle as I presented in previous comment.

That was added because we have it in master.

Again: If you do not use the tarball release do not expect that pacthes will be
included. You should never do autoreconf.