Thanks for the explanation.

If the ASN.1 is not from an RFC, then the AUTHORS file should not claim that it is from an RFC.

As I want to keep this tracker clean I would say this is a Wontfix at least until someone (DKG?) provides an argument what would be gained and why we should do this.

That is not a functional feature request and I see no value in chnaging data structures just for being up to the latest RFC. Actually the ASN.1 is not from an RFC but from a specific X.509 profile. For CMS most parsing is anyway done with handcrafted code.

We also need to fix for encryption and signature in CSR.

Applied.

Done for gpgme.

Done for libgcrypt.

I give this normal priority to move it out of the "Needs Triage" queue.

Done for libgpg-error.

Topic branch of libgpg-error is not good to show changes (for other libraries).
So, I made D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH.
Appliying to libgpg-error.

For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html

My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/

My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.

Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.

For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).

New gpg-error.m4 detects gpgrt-config, too.
And configure supplies --libdir when it invokes gpgrt-config.
For other *.m4 (libassuan, ksba, libgcrypt, ntbtls), it is possible for them to check GPGRT_CONFIG to use gpgrt-config if any.
For npth.m4, it can do that too, with no hard dependency to libgpg-error.

A bit tricky, but this would be good to use gpgrt-config by gpg-error.m4.
I say "tricky", because its name is gpg-error.m4 but it configure GPGRT_CONFIG to access to GPG_ERROR_CONFIG.

It might be good idea to provide libgcrypt.pc in libgcrypt 1.8.x for forward compatibility with libgpg-error 1.33.

Well, I changed my mind. Use of new gpgrt-config requires software update to introduce gpgrt.m4 and update of configure.ac to switch gpgrt from gpg-error, in standard way.
That's too much this time. It's good to defer this change.

OK, I'll change to use gpgrt-config, along with requiring newer version of libgpg-error.

May I suggest to use a (new) gpgrt-config instead of the current name libgpg-error-config. The long term plan is to change the name of the library.

This is the dependency graph:

Thanks.

Thanks. That code is from 2001 and whne I changed to another time representaion in 2003 (due certs with 40 years expiration time) I missed to changed that condition.

I was not aware that you could do this at all. You are right in that to start supporting this we first need to update libksba.

Please ignore them.

Fixed in a1d9b046aec8cedda16a9e24eb8d2ed021f68d5d

It is fine to close this. Reworking the parser is not going to happen anytime soon.

Because werner says he fixed the memory access, I am closing here. werner, if you want to keep track of the invalid encoding issue with the asn.1 parser, please open a new task with some details. pascal, if you find anything missing, please open new tickets (as you said, it's easier to keep track of issues in separate tickets).

Can you add a description?

Weel, required if you cange an .y file.

Bison is required.
I pushed a change which prints a note if yacc is not Bison.

I was unaware that the released version does not require it.

In that case it's no bug imo. because otherwise we would also need to work with
older autotools versions etc.

Bison is a maintainer tool and regualr builds do not require it.
I am also surprised that you can build it with a regular(?) yacc.

btw. reason for this report is a setup of WKS where you require most recent
modern gnupg on long time distro running servers.

You are right. Fixed with commit 68fba3d.

commit 2a9fc56 fixes the access to uninitialized buffers. Given that GnuPG puts
all senstive data into a special memory area which is cleared before a free, I
don't see a problem with a possible data leak.

What is left is the problem that the parser does not always detect invalid
encodings. This can be improved but I am not anymore convinced about that table
driven parser.

Thanks. I would actually prefer to handle this by mail because this makes
communication easier and faster. It would also be useful to known on what you
are working or plan to work on, so that we do not need to rush out releases
while there are other obvious things to fix.

Now I regret reporting so many different problems as a single ticket. Note that if possible
information leaks are the only thing we are concerned with, all the issues in this ticket can be
solved by systematically initializing dynamically allocated memory, so they have that in common.

This won't solve the problems that several inconsistent .crt files are in fact accepted as valid,
showing contents of the freshly initialized allocated memory in place of information that should have
come from the .crt file. I would much prefer fixing these logic errors individually so that use of
uninitialized memory can remain a useful symptom of other logic errors, but ultimately, this is your
choice to make.

Here is a fourth instance of use of uninitialized memory (uninitialized4.crt).

The tis-interpreter diagnostic is:

Certificate in `t.crt':

  serial....:

02

3A

83

  issuer....:

`CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US'

  subject...:

`CN=Google Internet Authority G2,O=Google Inc,C=US'

  notBefore.:

2013-04-05 15:15:56

  notAfter..:

2016-12-31 23:59:59

  hash algo.: (null)

Extn: 2.5.29.35 at 517 with length 24

SubjectKeyIdentifier:

none
src/ber-help.c:213:[kernel] warning: accessing uninitialized left-value:

assert \initialized(buf);                  
stack: _ksba_ber_parse_tl :: src/cert.c:1836 <-
       _ksba_cert_get_auth_key_id :: src/visibility.c:280 <-
       ksba_cert_get_auth_key_id :: tests/cert-basic.c:190 <-
       list_extensions :: tests/cert-basic.c:546 <-
       one_file :: tests/cert-basic.c:593 <-
       main

src/ber-help.c:213:[kernel] warning: completely indeterminate value in mallocksba_malloc_l130_935 with offsets 4152 bits.

In order to make the use of uninitialized memory visible, apply the following patch:

~/instrumented/libksba-1.3.4$ diff -u src/ber-
ber-decoder.c ber-decoder.lo ber-dump ber-help.c ber-help.h ber-help.o
ber-decoder.h ber-decoder.o ber-dump.c ber-help.c~ ber-help.lo
pascal@TrustInSoft-Box-VII:~/instrumented/libksba-1.3.4$ diff -u src/ber-help.c{~,}

• src/ber-help.c~ 2016-05-03 18:12:09.000000000 +0200

+++ src/ber-help.c 2016-05-11 03:04:34.361037076 +0200
@@ -210,7 +210,7 @@

/* Get the tag */
if (!length)
  return premature_eof (ti);

• c = *buf++; length--;

+ c = *buf++; printf("|%02hhX|\n", c); length--;

   ti->buf[ti->nhdr++] = c;
   ti->class = (c & 0xc0) >> 6;

With the above instrumentation in place, the command "./tests/cert-basic uninitialized4.crt" shows:

Certificate in `uninitialized4.crt':

serial....: (#023A83#)
issuer....: `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US'
subject...: `CN=Google Internet Authority G2,O=Google Inc,C=US'
notBefore.: 2013-04-05 15:15:56
notAfter..: 2016-12-31 23:59:59
hash algo.: (null)

Extn: 2.5.29.35 at 517 with length 24
SubjectKeyIdentifier: none

cert-basic.c:219: ksba_cert_get_auth_key_id: Invalid certificate object
KeyUsage: Not specified
ExtKeyUsages: none
CertificatePolicies: none
cert-basic.c:557: expected EOF but got: BER error

The line |3E| indicates access to uninitialized memory.

Here is a third instance, much like the second one. As the read from uninitialized memory happens in append_ucs2_value(),
the uninitialized memory is harder to recognize in the output.

tis-interpreter information:

Certificate in `t.crt':

  serial....:

02

3A

83
src/dn.c:522:[kernel] warning: accessing uninitialized left-value:

assert \initialized(tmp_1);
(tmp_1 from s++)
stack: append_ucs2_value :: src/dn.c:619 <-
       append_atv :: src/dn.c:667 <-
       dn_to_str :: src/dn.c:692 <-
       _ksba_dn_to_str :: src/cert.c:609 <-
       get_name :: src/cert.c:744 <-
       _ksba_cert_get_issuer :: src/visibility.c:190 <-
       ksba_cert_get_issuer :: tests/cert-basic.c:424 <-
       one_file :: tests/cert-basic.c:593 <-
       main

src/dn.c:522:[kernel] warning: completely indeterminate value in mallocksba_malloc_l130_935 with offset 1384 bits.

1.3.4 has been released.

1.3.4 has been released