Please explain in detail (step by step), what you did. What OS are you using?
Thanks.

Done for master (f1e1387).

Done for 2.1

Should be fixed with 2.0.18.

Fixed for 2.0.19 (88633bf3).

Thanks.

Please re-open if you still see this problem.

This is an old one, but we may want to get a new dirmngr release out anyway.

Fixed for 2.0.19 (8b9fb19).

Fixed in GIT master (0ad03d2). Will go into future releases of all branches.

D152: 342_gnupg-2.0.18_show-session-trunc.diff

Backport to 2.0 done (f772757e)

1.4.12 has been released.

Released with 1.4.12.

Thank you both for a very swift and sensible change.

The changes are now commited to all active branches.

I think this makes sense. It's not a hard change. Way back when, I did something similar for trust_model -
it's stored in the version record and if gpg detects that the current model does not match what is encoded in
the header, it marks the trustdb as pending_rebuild.

Backport to 1.4. done (cfb193a1).

This seems to be a pcsc-lite mismatch.

I'd also like to ask, if you please could explain in depth your

comment in line 1499: "Better add 1 for safety reasons." - what is the
actual benefit of this code +1?

There are even 3 other reserved bytes available.

There are even 3 other reserved bytes available.

We would need to store the new level in the version record of the trustdb.
There is a reserved 4 byte field in the version record. We could use one byte
of it to record the level (using bit 7 to indicate that a value has been stored).

Fixed for 2.0 and 2.1. Thanks.

(Understood there are no immediate plans for a release, but if/when we do have
one, the change will be ready)

Change committed to 1.4, 2.0, and master.

Ok, fixed on 1.4, 2.0, and master.

I just fixed a couple of card reader problems in GIT master. I assume that
theses fixes will also solve your problem.

I ran a test and it returned 65534.

We need to look into Pth to find a portable way for finding the used values for
--with=fdsetsize and use that as an upper limit.

I think the long loop in "t-exechelp" where it is uses the hard limit of
2147483647 in AIX 6.1 might be addressed so that it uses a reasonable
number (i.e. FD_SETSIZE) as a maximum. I don't know if using NPTH would
address that.

I am not sure whether I want to fix that. The problem is a Pth problem and we
will soon drop the requirement for Pth in favor of our new NPTH. NPTH uses
native threads (e.g. pthreads) but provides an API and semantics simialar to Pth.

I am currently working on the DNS code in master. I changed the default buffer
size to cope with that large keys. For the other branches the option

Ooops. The key is there but it is longer than the limit we use. I will check
whether we can return a proper error code in this case.

One of the problems is that there is no such key in the DNS anymore. Simon has a
preferred keyserver attribute in his key which points to a DNS record. I'll ask
him what happened to this DNS record.