As I wrote to #712744, distribution nowadays is conservative enough for its
default kernel settings, and it doesn't require each application to have special
settings.

I think that we will be able to close this soon.

Thanks. Fixed with commit dc10d46.

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

Should be fixed by commit 017c6f8fba9ae141a46084d6961ba60c4230f97a
on 2014-06-24.

D281: 541_0001-Fix-a-problem-with-select-and-high-fds.patch

Given that it seems not easy to reproduce this bug can you please test
commit 8adb5ff or the attsched patch to see whether this helps.

If it does not help, can you do a gpg build with debug symbols and run your case
again. If possible attach a debugger for a backtrace or produce it with a dump file.

Well, that is quite possible. I have seen other reports about this. I have not
yet come around to look at the hkps bugs.

Yes, this is the case for a very long time. I also won't call this a
bug.

There is no way to protect an update by a lock without having write
permissions to the same directory. Well, one could setup a second
file system hierarchy below /var/run and use that for the locking
file. However, this assume that all process accessing the files are
on the local machine. One of the reasons why we can't use a locking
API are remotely mounted file systems. See the comments in
common/dotlock.c .

And yes, we need lock the file even if the local process as no write
permissions to the directory - other processes may have and the
reading process may thus read garbage.

By using --lock-never you assert that there is no other processing
writing to the gpg data files. Thus using this is the Right Thing.

I assume this is related to T1630 which has been fixed

oh, and this appears to be the case for 1.4.x, 2.0.x, and 2.1.x

That link to the debian bts is a little wacky, somehow roundup is attaching the
comma to the end of it. it should be: https://bugs.debian.org/771976

dkg developed a reasonsable patch which will be included in the next 1.4 version.

No bug and I already set this bug to resolved.

Judging by the lack of reply, I assume that this bug won't be fixed, correct?

I read that. It says that RSA-2048 keys are going to be safe until 2030. Doesn't
sound like a lot to me... Considering the average human lifespan, I could be
around until 2070. So, nope, not enough.
If all the emails I sent till now have been intercepted and stored (which seems
to be the case according to Snowden), using a RSA-2048 key simply means that all
my private correspondence is going to be public (or at least accessible) in 16
years time. Now, the only thing I'm asking is to raise the amount of secure
memory allocated by GnuPG to 128k to let people use key sizes up to 16384,
something that was even allowed by the keygen itself.

Please read the FAQ starting with
https://gnupg.org/faq/gnupg-faq.html#default_rsa2048

By the way, is this all bullshit?
AES-256 == RSA-15360 / DSA-15360 (NIST)
http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2006-03/E_Barker-
March2006-ISPAB.pdf

AES=256 == RSA-15424 / DSA-15424 (ECRYPT2)
http://www.ecrypt.eu.org/documents/D.SPA.20.pdf

Ok, got it. So I can just throw away my key and make a new one?
Fantastic. Thanks a lot.
Sounds a lot like "640K ought to be enough for anybody".
So long, and thanks for all the good work on GnuPG (seriously).

No.

Please read the FAQ on key sizes and if you have a lot of time the countless
discussions on gnupg-users. No, you are not paranoid but you are tuning the
wrong parameters. IT will never be a standard. There will never be any keys
larger than 4k RSA in real use.

Yes, I know how to change the code and make it work on _my_ machine.
There is the tiny problem that everyone else has to do it, too.
Can we make that change the default? I don't see a big problem in using 64k or
128k instead of 32k of secure memory.
By the way, 16k of key size is ridiculous now, but it's going to be kind of
standard in the not so distant future. Or am I too paranoid? :)
Just trying to have a GnuPG key which is future-proof, also taking in
consideration the possible use of quantum computers in the future.

Sorry, there is a limit on the size of secret keys which depends on
several factors. We allow for way longer keys than can be generated
by gpg to take the fuzziness in account, but only up to some limit.
You are on your own if you want to use ridiculous long keys.

Hint: You may increase the size of the secure memory my changing the
line

    /* initialize the secure memory. */
    got_secmem=secmem_init( 32768 );

in g10/gpg.c. Use a larger value there and it will work.

also fixed in 2.0

Done for 2.1 with commit 03018ef

Also applied to master.

Fixed with commit 23191d7.
This should be the same patch as used by Debian.

Done for 1.4.15 and 2.0.22.

Will do so.

D169: 384_verify_doc.patch

I'm reading in your response that you're not eager to change the behaviour of
--verify in this regard, right?

If that's the case, perhaps you can consider this patch to add a note to the
documentation, making it clear what is expected when using --verify on inline
signed files with auxiliary data. Afterall, we've seen several places where
--verify was used insecurely in the wild, so some warning may be in order.

Hm. The process disappears after some time. Maybe it just needs some time to
finish. Maybe not a bug anymore. Please take a look at it yourself.

Can you please take a look at it again? If I compile long_genkey.c and run it
via ./long_genkey async it leaves a process behind, which should better be killed:

ps aux | grep gpg
dl 7577 7.0 0.0 24416 1924 pts/2 SL 22:05 0:00 gpg
--enable-special-filenames --use-agent --batch --no-sk-comment --lc-messages
de_DE.utf8 --lc-ctype de_DE.utf8 --status-fd 4 --no-tty --charset utf8
--enable-progress-filter --display :0 --ttyname /dev/pts/2 --ttytype xterm
--gen-key -- -&5

What is the threat model for this? If you are able to ptrace a process you can
do all other kind of stuff, like replacing gpg with your own code. If the box
has been taken over, we are in game-over state.

Disabling core dumps is a different issue because a core dump leaves traces of
the process on the disk.

I think that original reporter's intention is to prevent attaching by ptrace.
By PR_SET_DUMPABLE disabled, ptrace PTRACE_ATTACH won't work any more.
This would be better if we care about kernel compatibility.
In http://bugs.debian.org/714107, I found that setrlimit64 doesn't work reliably
for 2.6.34 or older. PR_SET_DUMPABLE seems to work for even 2.4.x.

Yes. I think we're in agreement that MIME and detached signatures are the best way.

However, the functionality in gpg to check cleartext messages is there. If gpg
is confronted with a cleartext file containing auxilliary data, wouldn't it
better refrain from giving a positive return code when checking that file?

Hello Werner,

GnuPG uses setrlimit do disable core dumps. It has always done so. See
common/sysutils.c:disable_core_dumps. Do you have a test case which shows that
it does not work?

1.0.2 is more than 8 years old. The code chnaged a lot in the meantime. Feel
free to re-open if the problems persists with 1.4.x?

Pending for a long time; should be considered for 2.1

Fixed in master

This is an application problem. For example KMail renders the signed parts in a
frame with a different color so to visible explain what has been signed. Mutt
has a similar feature. We can't do anything about this in gpg than to emit
certain status lines and to output the signed data.

This is long known problem with signatures and not even the worst. MUAs
introduced ways to mitigate the problems 2 decades ago. The best working
solutions is to use PGP/MIME for mail and detached signatures for other data.