Pushed your patch to master and 2.0. Thanks.

And the testscript I used to test this.

D289: 587_0001-gpgtar-Fix-extracting-files-with-size-512.patch

In gpgtar-extract.c extract_regular

  for (n=0; n < hdr->nrecords;)
    {
      err = read_record (stream, record);
      if (err)
        goto leave;
      n++;
      nbytes = (n < hdr->nrecords)? RECORDSIZE : (hdr->size % RECORDSIZE);

^ this does not work for the last header if hdr->size size is a multiple of 512.
In that case the last record will not be written.

Please check my attached patch which fixes the problem.

To further minimize the test case:

dd if=/dev/urandom of=testfile count=1024 bs=1024
./gpgtar --encrypt --skip-crypto -- testfile > test.tar
./gpgtar --decrypt --skip-crypto -- test.tar
diff ./test.tar_1_/testfile ./testfile

Binary files ./test.tar_1_/testfile and ./testfile differ

last 512 bytes of testfile are missing after extracting it with gpgtar.

Further tracked this problem down to be a gpgtar extraction issue.

Calling gpgtar on the decrypted archive with the same command kleopatra uses:

C:\Users\aheinecke\Desktop>type gpg-archive.tar |"c:\Program
Files\GNU\GnuPG\gpgtar.exe" --openpgp --skip-crypto --set-filename
C:/Users/aheinecke/Desktop/gpg-archive.tar.gpg --decrypt -- -

Produces the corrupted binary. Copying this archive to a GNU/Linux system and
extracting the tarball with GNU Tar produces a valid binary.

Next test on GNU/Linux with:

./gpgtar --version

gpgtar (GnuPG) 2.1.3-beta4

./gpgtar --openpgp --skip-crypto \

--set-filename /home/aheinecke/arbeit/gpg4win/gpg-archive.tar.gpg \
--decrypt -- /home/aheinecke/arbeit/gpg4win/gpg-archive.tar

sha1sum gpg-archive.tar_1_/gpg2.exe

2d387c8fb53d105c31e4cc2ec186e70a365b0c65 gpg-archive.tar_1_/gpg2.exe

tar -fx /home/aheinecke/arbeit/gpg4win/gpg-archive.tar
sha1sum gpg2.exe

54c8c2ec1083943e556255f76ff8f58e623c5b27 gpg2.exe

The second one is correct.

The problem was with protected private keys - I've got my own tool for
decrypting them, and that's how I found the problem in the first place.

I've attached two keypairs which exhibit the issue, both in keyring and in
keybox+key formats (password is "password") - both use NIST P-256, and the
encryption key on Test2 (4e86073a308aa22e) has the extra leading zero byte on
its 'd' value.

[Sorry, I didn't found your mail anymore.]

I fixed two bug related to the encoding of MPI created by ECC operations.
ab17f7b gpg: Create all MPIs with RFC-4880 correct length headers.
8bc1deb gpg: Fix broken write of opaque MPI length header.

However your problem was with private keys. Protected private keys or
non-protected? Can you add an example file.

Duplicate of T739

Was fixed with commit fe85638284880805b80778fe87ae551d3de0ca32 for 2.0 which is
a forwardport for the fix in 1.4 (see T739).

Was fixed with commit 6b1f71055ebab36989e2089cfde319d2ba40ada7 for 2.0.
Was fixed with commit 5c557a51cdf37d9f50b3d5d7e11d17e6ea6bb2b8 for 1.4.

Fixed with commit ba9e974f1fd85b3dbbfb5e26d7a14f71d07c7cf2 for 2.0
Fixed with commit f2f12f41efe5a476833295dc6c44fcd887d0abe6 for 1.4

This shows up elsewhere too:

http://forum.yubico.com/viewtopic.php?f=26&t=1171

says:

For some inexplicable reason, GnuPG cannot extract the public key from a
smartcard except during generation. That means that to use the key from
another computer, you either have to copy the public key from the original
computer's GnuPG keyring, or you need to set the URL attribute to a file
which contains the PGP public key block. Otherwise, the token is effectively
locked to a single computer, and unuseable if you happen to trash your
keyring unless you regenerate a key.

It would be nice to streamline this case.

GPG_AGENT_INFO is a private property of GnuPG and no other software may use it.
In fact gnome-keyring does worse things to the IPC between gpg and gpg-agent.
There is a even detection code in gpg to print a warning when gkr has hijacked
the IPC. cf. the long discussions at many MLS.

BTW, A socket has always been used.

That is a matter of your OS and not of GnuPG.

Except the for doubled listing, is there any other potential drawback?

Done with commit 14af2be

$ gpg --with-colons --list-config curve
cfg:curve:ed25519;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1

Please stop using this severely broken analyzer. It does not overflow anything.
Checkout the allocation of the bufgfger 3 lines earlier!

No c+p of warnings please! Use gnupg-devel for such things.

Plesase discuss on gnupg-devel. Thanks.

Please ask on gnupg-devel!

The first warning: The function is pretty short:

  void
  http_start_data (http_t hd)
  {
    if (!hd->in_data)
      {
        es_fputs ("\r\n", hd->fp_write);
        es_fflush (hd->fp_write);
        hd->in_data = 1;
      }
    else
      es_fflush (hd->fp_write);
  }

I do not understand how your analzyer gets to the conclusion that hd == NULL?

On the second warning:

Please view that in context:

  /* Append a new header. */
  h = xtrymalloc (sizeof *h + strlen (line));
  if (!h)
    return gpg_err_code_from_syserror ();
  strcpy (h->name, line);

How should that overflow a buffer? It has just been allocated - also check the
definition of the struct used for h.

Patch still needs to be applied upstream but this is tracked in another issue.
-> Resolved

Changed status to 'unread'. I'm not chatting.

I was able to duplicate Bug 1862: Building static GnuPG 2.1.2 fails due to
multiply defined symbols.

/home/jwalton/Desktop/gcrypt-2.0-analyze/libgpg-error-1.18/src/visibility.c:46:
multiple definition of `gpg_err_code_from_errno'
t-support.o:/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common/t-support.c:137:
first defined here
/home/jwalton/gpg-analyze/lib/libgpg-error.a(libgpg_error_la-visibility.o): In
function `gpg_err_code_from_syserror':
/home/jwalton/Desktop/gcrypt-2.0-analyze/libgpg-error-1.18/src/visibility.c:58:
multiple definition of `gpg_err_code_from_syserror'
t-support.o:/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common/t-support.c:151:
first defined here
collect2: error: ld returned 1 exit status
make[3]: * [t-stringhelp] Error 1
make[3]: Leaving directory
`/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common'
make[2]: * [all] Error 2
make[2]: Leaving directory
`/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory `/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2'
make: * [all] Error 2

LIBRARY=gnupg
VERSION=2.1.2
FILE="$LIBRARY-$VERSION"

export PREFIX=/usr/local

cd "$FILE"
./configure --enable-static --disable-shared
--with-libgpg-error-prefix="$PREFIX" --with-libassuan-prefix="$PREFIX"
--with-ksba-prefix="$PREFIX" --with-npth-prefix="$PREFIX"
--with-libgcrypt-prefix="$PREFIX" --prefix="$PREFIX"

make

Platform: Red Hat Enterprise Linux 5.11

ldconfig: I did not (assuming that make install does it if necessary)

Running "sudo ldconfig" after each "sudo make install" does not help.

What platform? Did you run ldconfig after installing a library?

I really want to try, but I cannot compile 2.1.2 due to T1862.

Duplicate of T1644

Okay, I changed your role so that you can comment on T1644.

It is very unlikely that we are going to fix that in 2.0, thus be prepared to
move to 2.1.

Thanks. It might be related to a left overPGP-2 key in the trustdb. I need to
investigate that closer.