D170: 372_gpl.patch

new version with end enumerate a little earlier.

D171: 371_gpl.patch

Marking as resolved, as this seems to work fine now as far as I can tell (I'm
certainly happy).

scrypt has now been implemented.

This bug is fixed for 2.0.

http://git.gnupg.org/cgi-bin/gitweb.cgi?
p=gnupg.git;a=commit;h=ae22d629b6028aa994ff09f012e1cb029575eeae

Following the calling chain, we eventually call the OS itself using select(2).
This happens twice. The first call works. The 2nd call hangs in a loop, with
select(2) returning <0 and errno set to EINTR (call was interrupted).

D167: 370_scrypt.diff

Done in master.

If you use --textmode during encryption the native line endings on the
decryption system are used. Adding an extra option to for arbitrary conversions
is IMHO not a good idea beause it violates the Unix principle of having
dedicated tools which work together. tr(1) does what you want.

Ah yes, that Serpent case again. We have a fix for that but a brief inspection
made me believe that it will only happen if the serpent.c code is used outside
of the Libgcrypt. It is an alignment problem. Please give me a few days to
prepare an updated patch.

I just verified that the issue only appears on 64 bit sparc, all others like 32
bit i386, 32 bit sparc and 64 bit amd64 work fine, so it is most likely a byte-
order issue.

Argh, I did quite some fixes for the 1.5.1 release and assumed that I applied
this one as well. Now pushed but too late for 1.5.1 :-(. However, there is no
need to use automake for a released version.

You are using version 1.4.5 and not 1.5.0.

Two hints: Your are using the Solaris as and ld - better try with a native GNU
toolchain. You have some global CLFAGS set which add a lot of extra and useless
include paths. Please remove them.

I close the bug because it is pretty old. Feel free to re-open it if you have
newer info and tried with 1.5.0.

Done in commit d3132553 for 1.5. Needs to be fixed in master.

1.6 (current master) now has a feature to switch to a pure /dev/random based RNG.

We still have a copyright assignment policy in effect. Thus I can't accept your
patch right now. This will change in 2 weeks.

Ok, no problem.

Patches should be send to gnupg-devel and not to the bug tracker.

Thanks for information, next time I'll send patches directly there. Should I
send also this one to be reviewed on mailing list?

BTW, HEAD of branch?

master, forgot to mention, sorry about that.

Milan

We still have a copyright assignment policy in effect. Thus I can't accept your
patch right now. This will change in 2 weeks.

Patches should be send to gnupg-devel and not to the bug tracker. BTW, HEAD of
which branch?

Still have this issue. Here is an updated patch against 2.0.19. Please
consider including it, or provide some feedback if this is a bad idea / should
be done a different way.

Marking this as a bug since it restores useful functionality that was lost.

D151: 369_gnupg-2.0.19-showsession-trunc.patch

Am able to reliably trigger the flaw, by using a curl-shim gpg from another
machine on the same network as the keyserver. Close network proximity without
being the exact same machine makes it much easier to trigger the race.

D168: 368_libassuan-2.1.0-solaris-configure.ac-inet_pton.patch

The error still shows up in 2.1.0, again amd64 only.

As I said, gpg does not mess around with the encoding. The content is an opaque
data for gpg. Your problem is outside of GnuPG.

Do not use an outdated version of GnuPG.

1.2 has long reached end of life.

Anyway, your problem is corrupted input data. Newer version may give a sensible
error message but neityer woulde abale to decrypt your data.

Thank You for your email.

Do you mean the file name or the content of the file? gpg does not care about
the content and the file name is used verbatim. However, for display purposes
shown meta data (e.g. the informational only file name in the encrypted data) is
converted to the used character set. For any non-attended use you should use
--status-fd to get the meta data which is either UTF-8 (if gpg generated) or
whatever the sending party used.

We are having issues decryting an encrypted file with gpg (algorithm RSA 2048
encryption) when the file has special international characters. The decrypted
file has special characted decoded incorrectly for example
Sadurní as Sadurní and García as García. The gpg (GnuPG) 1.4.5 is installed on
the LUNIX RHEL 5.6 server.
Please let me know if there is patch/version that supports international
characters.

D164: 367_gnupg-2.0.17-gpgsm-gencert.patch

D165: 366_gpgsm-gencert.sh.diff

Ooops.