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.

Patch and commentary uploaded to T1792, where it really belongs.

The attached patch fixes hkps: hostname verification and makes
hkps: use SNI correctly.

The patch is against GnuPG 2.1.2. It has been tested successfully against
hkps://hkps.pool.sks-keyservers.net on FreeBSD 10.1 using GnuTLS 3.2.21 and the
2.1 setup instructions at https://sks-keyservers.net/overview-of-pools.php#pool_hkps

D275: 586_poolname_and_SNI.patch

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

D288: 584_poolname_and_SNI.patch

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.

FWIW: libgpg-error.so.0: no version information available"
is a harmless diagnostic issued for example by Debian to help detecting broken
ABIs. It is a non-issue here. We can't do anthing about it. With some
libgpg-error we introduced symbol versioning to assist the loader and to hide
internal symbols from other ELF objects.

Unaligned memory accesses are enabled on only architectures that can handle
those. The buf_xor function that you copy-pasted partially to stackoverflow
actually has alignment checks:

#if defined(i386) || defined(x86_64) || \

defined(__powerpc__) || defined(__powerpc64__) || \
(defined(__arm__) && defined(__ARM_FEATURE_UNALIGNED)) || \
defined(__aarch64__)

/* These architectures are able of unaligned memory accesses and can

  handle those fast.
*/

1. define BUFHELP_FAST_UNALIGNED_ACCESS 1 #endif ... /* Optimized function for buffer xoring */ static inline void buf_xor(void *_dst, const void *_src1, const void *_src2, size_t len) { byte *dst = _dst; const byte *src1 = _src1; const byte *src2 = _src2; uintptr_t *ldst; const uintptr_t *lsrc1, *lsrc2; #ifndef BUFHELP_FAST_UNALIGNED_ACCESS const unsigned int longmask = sizeof(uintptr_t) - 1; /* Skip fast processing if buffers are unaligned. */ if (((uintptr_t)dst | (uintptr_t)src1 | (uintptr_t)src2) & longmask) goto do_bytes; #endif ldst = (uintptr_t *)(void *)dst; lsrc1 = (const uintptr_t *)(const void *)src1; lsrc2 = (const uintptr_t *)(const void *)src2; for (; len >= sizeof(uintptr_t); len -= sizeof(uintptr_t)) *ldst++ = *lsrc1++ ^ *lsrc2++; dst = (byte *)ldst; src1 = (const byte *)lsrc1; src2 = (const byte *)lsrc2; #ifndef BUFHELP_FAST_UNALIGNED_ACCESS do_bytes: #endif /* Handle tail. */ for (; len; len--) *dst++ = *src1++ ^ *src2++; }

So, yes, we use unaligned memory accesses but only when it is known that they work.

Now, solution (with same code generation, without undefined behaviour) to this
issue is to tell the compiler that we really want to do unaligned accesses. For
that we need to change the accesses to happen through type that has proper
one-byte alignment, but generates the same code (unaligned word-size memory
accesses) on the few architectures that enable 'BUFHELP_FAST_UNALIGNED_ACCESS':

#ifdef BUFHELP_FAST_UNALIGNED_ACCESS
/* Define type with one-byte alignment on architectures with fast unaligned

  memory accesses.
*/

typedef struct bufhelp_int_s
{

uintptr_t a;

} attribute((packed, aligned(1))) bufhelp_int_t;
#else
/* Define type with default alignment for other architectures (unaligned

  accessed handled in per byte loops).
*/

typedef struct bufhelp_int_s
{

uintptr_t a;

} bufhelp_int_t;
#endif

Ofcourse, BUFHELP_FAST_UNALIGNED_ACCESS now need to be limited to compiler that
support GCC style attributes.

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?

That is used for an experimental tool of Libgcrypt (src/gcryptrnd). It is not
clear whether this will be ported to npth or removed.

Done with commit 14af2be

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

Please build libgcrypt directly and read README(cross-compiling).
I assume you are using libgpg-error 1.18, right?

Since then we did a lot of work on Libgcrypt so that the AES-NI code is
different from May 2012. It is possible that we accidently clobbered a register
which might have been the reason for the VirtualBox failure.

I can't remember the test case, but any use of AES should have hit it. Just use
gpg where AES is the default anyway. I suggest to revert that patch an see what
happens.

BTW: Anyone using -DNDEBUG should be punished by having to read BIND 4 code for
the next 3 months.

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

Sure it used and thus read! You only need to look at the code for 5 seconds!
And no, it is not a lock. Read the comment at the var definition.

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

clang seems to be weak in a lot of areas ;-)

Yes it is not for a reason - checkout the comments to see why.

Given all the other faulty warnings I have seen meanwhile I have severe doubts
on the quality of that tool! Please distcuss on gnupg-devel.

Sure it does not. This is C! What a plain silly warning.

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

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

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