macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Peter Maydell]

My Big Sur/Apple Silicon system fails "make check" in
test-crypto-tlscredsx509:

MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
G_TEST_SRCDIR=/Users/pm215/qemu/tests
G_TEST_BUILDDIR=/Users/pm215/qemu/build/all/tests
tests/test-crypto-tlscredsx509 --tap -k

** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
Failed to sign certificate ASN1 parser: Value is not valid.
ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
sign certificate ASN1 parser: Value is not valid.
make: *** [run-test-70] Error 1


Does this failure ring any bells for anybody?

Here's the crypto part of the meson-log:

  Crypto
                     TLS priority: "NORMAL"
                   GNUTLS support: YES
                        libgcrypt: NO
                           nettle: YES
                              XTS: YES
                     crypto afalg: NO
                         rng-none: NO
                    Linux keyring: NO


thanks
-- PMM

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Daniel P. Berrangé]

On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote:
> My Big Sur/Apple Silicon system fails "make check" in
> test-crypto-tlscredsx509:
> 
> MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
> G_TEST_SRCDIR=/Users/pm215/qemu/tests
> G_TEST_BUILDDIR=/Users/pm215/qemu/build/all/tests
> tests/test-crypto-tlscredsx509 --tap -k
> 
> ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
> Failed to sign certificate ASN1 parser: Value is not valid.
> ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
> sign certificate ASN1 parser: Value is not valid.
> make: *** [run-test-70] Error 1
> 
> 
> Does this failure ring any bells for anybody?

Not seen it before.

Is this using a gnutls from homebrew, or one that apple
ship themselves ?  Any idea what version it is ?


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Peter Maydell]

On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote:
> > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
> > Failed to sign certificate ASN1 parser: Value is not valid.
> > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
> > sign certificate ASN1 parser: Value is not valid.
> > make: *** [run-test-70] Error 1
> >
> >
> > Does this failure ring any bells for anybody?
>
> Not seen it before.
>
> Is this using a gnutls from homebrew, or one that apple
> ship themselves ?  Any idea what version it is ?

Homebrew gnutls, 3.6.15.

thanks
-- PMM

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Daniel P. Berrangé]

On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote:
> On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote:
> > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
> > > Failed to sign certificate ASN1 parser: Value is not valid.
> > > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
> > > sign certificate ASN1 parser: Value is not valid.
> > > make: *** [run-test-70] Error 1
> > >
> > >
> > > Does this failure ring any bells for anybody?
> >
> > Not seen it before.
> >
> > Is this using a gnutls from homebrew, or one that apple
> > ship themselves ?  Any idea what version it is ?
> 
> Homebrew gnutls, 3.6.15.

On further investigation it seems the error comes from libtasn1,
but unfortunately there are 100's of scenarios it could arise
so difficult one to debug.

In the test_tls_generate_cert method in QEMU tests/crypto-tls-x509-helpers.c

There are conditional lines like

    if (req->country) {

    if (req->altname1) {
    ...etc...

I guess one, or more of those, is writing data that libtasn1 is not happy
with.

Some one with easy access to this apple silicon will likely need to start
by incrementally disabling each of those conditionals eg.  if (req->country
&& 0)

until we find out which one (might be more than one) make the 

   Failed to sign certificate ASN1 parser: Value is not valid.

error message go away. NB, once that ASN1 error goes away, the QEMU test
suite will likely give its own error because the certs will no longer
have the data it is expecting. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Christian Schoenebeck]

On Mittwoch, 27. Januar 2021 13:17:23 CET Daniel P. Berrangé wrote:
> On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote:
> > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> 
wrote:
> > > On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote:
> > > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
> > > > Failed to sign certificate ASN1 parser: Value is not valid.
> > > > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
> > > > sign certificate ASN1 parser: Value is not valid.
> > > > make: *** [run-test-70] Error 1
> > > > 
> > > > 
> > > > Does this failure ring any bells for anybody?
> > > 
> > > Not seen it before.
> > > 
> > > Is this using a gnutls from homebrew, or one that apple
> > > ship themselves ?  Any idea what version it is ?
> > 
> > Homebrew gnutls, 3.6.15.
> 
> On further investigation it seems the error comes from libtasn1,
> but unfortunately there are 100's of scenarios it could arise
> so difficult one to debug.

I haven't looked into the relevant code of this discussion, but is the failing 
code dealing with Apple certificates? Because Apple just announced a switch of 
one of their intermediate certificates, so just in case this might be related.

Best regards,
Christian Schoenebeck

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Daniel P. Berrangé]

On Wed, Jan 27, 2021 at 01:35:37PM +0100, Christian Schoenebeck wrote:
> On Mittwoch, 27. Januar 2021 13:17:23 CET Daniel P. Berrangé wrote:
> > On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote:
> > > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> 
> wrote:
> > > > On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote:
> > > > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
> > > > > Failed to sign certificate ASN1 parser: Value is not valid.
> > > > > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
> > > > > sign certificate ASN1 parser: Value is not valid.
> > > > > make: *** [run-test-70] Error 1
> > > > > 
> > > > > 
> > > > > Does this failure ring any bells for anybody?
> > > > 
> > > > Not seen it before.
> > > > 
> > > > Is this using a gnutls from homebrew, or one that apple
> > > > ship themselves ?  Any idea what version it is ?
> > > 
> > > Homebrew gnutls, 3.6.15.
> > 
> > On further investigation it seems the error comes from libtasn1,
> > but unfortunately there are 100's of scenarios it could arise
> > so difficult one to debug.
> 
> I haven't looked into the relevant code of this discussion, but is the failing 
> code dealing with Apple certificates? Because Apple just announced a switch of 
> one of their intermediate certificates, so just in case this might be related.

It shouldn't be affected. The test suite is creating its own self-signed
root CA, and cert tree under that, so everything should be self contained.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Stefan Weil]

Am 27.01.21 um 13:17 schrieb Daniel P. Berrangé:

> On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote:
>> On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>> On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote:
>>>> ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
>>>> Failed to sign certificate ASN1 parser: Value is not valid.
>>>> ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
>>>> sign certificate ASN1 parser: Value is not valid.
>>>> make: *** [run-test-70] Error 1
>>>>
>>>>
>>>> Does this failure ring any bells for anybody?
>>> Not seen it before.
>>>
>>> Is this using a gnutls from homebrew, or one that apple
>>> ship themselves ?  Any idea what version it is ?
>> Homebrew gnutls, 3.6.15.
> On further investigation it seems the error comes from libtasn1,
> but unfortunately there are 100's of scenarios it could arise
> so difficult one to debug.
>
> In the test_tls_generate_cert method in QEMU tests/crypto-tls-x509-helpers.c
>
> There are conditional lines like
>
>      if (req->country) {
>
>      if (req->altname1) {
>      ...etc...
>
> I guess one, or more of those, is writing data that libtasn1 is not happy
> with.
>
> Some one with easy access to this apple silicon will likely need to start
> by incrementally disabling each of those conditionals eg.  if (req->country
> && 0)
>
> until we find out which one (might be more than one) make the
>
>     Failed to sign certificate ASN1 parser: Value is not valid.
>
> error message go away. NB, once that ASN1 error goes away, the QEMU test
> suite will likely give its own error because the certs will no longer
> have the data it is expecting.
>
> Regards,
> Daniel


I could debug into gnutls_x509_crt_sign2. gnutls_x509_crt_privkey_sign 
seems to fail.

Disabling the conditionals mentioned above did not help.

And I also have another problem when running "make check-tcg":

% make check-tcg
   BUILD   TCG tests for aarch64-softmmu
   BUILD   aarch64-softmmu guest-tests with cc
/qemu/tests/tcg/aarch64/system/boot.S:81:18: error: unexpected token in 
'.section' directive
  .section .rodata
                  ^

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Daniel P. Berrangé]

On Wed, Jan 27, 2021 at 05:44:59PM +0100, Stefan Weil wrote:
> Am 27.01.21 um 13:17 schrieb Daniel P. Berrangé:
> 
> > On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote:
> > > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > > On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote:
> > > > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
> > > > > Failed to sign certificate ASN1 parser: Value is not valid.
> > > > > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
> > > > > sign certificate ASN1 parser: Value is not valid.
> > > > > make: *** [run-test-70] Error 1
> > > > > 
> > > > > 
> > > > > Does this failure ring any bells for anybody?
> > > > Not seen it before.
> > > > 
> > > > Is this using a gnutls from homebrew, or one that apple
> > > > ship themselves ?  Any idea what version it is ?
> > > Homebrew gnutls, 3.6.15.
> > On further investigation it seems the error comes from libtasn1,
> > but unfortunately there are 100's of scenarios it could arise
> > so difficult one to debug.
> > 
> > In the test_tls_generate_cert method in QEMU tests/crypto-tls-x509-helpers.c
> > 
> > There are conditional lines like
> > 
> >      if (req->country) {
> > 
> >      if (req->altname1) {
> >      ...etc...
> > 
> > I guess one, or more of those, is writing data that libtasn1 is not happy
> > with.
> > 
> > Some one with easy access to this apple silicon will likely need to start
> > by incrementally disabling each of those conditionals eg.  if (req->country
> > && 0)
> > 
> > until we find out which one (might be more than one) make the
> > 
> >     Failed to sign certificate ASN1 parser: Value is not valid.
> > 
> > error message go away. NB, once that ASN1 error goes away, the QEMU test
> > suite will likely give its own error because the certs will no longer
> > have the data it is expecting.
> > 
> > Regards,
> > Daniel
> 
> 
> I could debug into gnutls_x509_crt_sign2. gnutls_x509_crt_privkey_sign seems
> to fail.
> 
> Disabling the conditionals mentioned above did not help.

In $QEMU.git/crypto/init.c can you uncomment  the "#define DEBUG_GNUTLS"
line and then re-build and re-run the test case.

There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign
that might give us useful info.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Stefan Weil]

Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé:

> In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS"
> line and then re-build and re-run the test case.
>
> There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign
> that might give us useful info.
>
> Regards,
> Daniel


% LANG=C.UTF-8 tests/test-crypto-tlscredsx509
# random seed: R02S9b95072a368ad370cdd4c780b8074596
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: common.c[_gnutls_x509_der_encode]:855
3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174
3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834
3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152
Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value 
is not valid.

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Daniel P. Berrangé]

On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote:
> Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé:
> 
> > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS"
> > line and then re-build and re-run the test case.
> > 
> > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign
> > that might give us useful info.
> > 
> > Regards,
> > Daniel
> 
> 
> % LANG=C.UTF-8 tests/test-crypto-tlscredsx509
> # random seed: R02S9b95072a368ad370cdd4c780b8074596
> 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> 2: signing structure using RSA-SHA256
> 3: ASSERT: common.c[_gnutls_x509_der_encode]:855
> 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174
> 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834
> 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152
> Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is
> not valid.

So it shows its failing inside a asn1_der_coding call, but I can't see
why it would fail, especially if the same test suite passes fine on
macOS x86_64 hosts.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Stefan Weil]

Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé:

> On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote:
>> Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé:
>>
>>> In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS"
>>> line and then re-build and re-run the test case.
>>>
>>> There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign
>>> that might give us useful info.
>>>
>>> Regards,
>>> Daniel
>>
>> % LANG=C.UTF-8 tests/test-crypto-tlscredsx509
>> # random seed: R02S9b95072a368ad370cdd4c780b8074596
>> 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
>> 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
>> 2: signing structure using RSA-SHA256
>> 3: ASSERT: common.c[_gnutls_x509_der_encode]:855
>> 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174
>> 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834
>> 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152
>> Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is
>> not valid.
> So it shows its failing inside a asn1_der_coding call, but I can't see
> why it would fail, especially if the same test suite passes fine on
> macOS x86_64 hosts.


It returns ASN1_MEM_ERROR, so the input vector is too small.

Stefan

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Daniel P. Berrangé]

On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote:
> Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé:
> 
> > On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote:
> > > Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé:
> > > 
> > > > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS"
> > > > line and then re-build and re-run the test case.
> > > > 
> > > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign
> > > > that might give us useful info.
> > > > 
> > > > Regards,
> > > > Daniel
> > > 
> > > % LANG=C.UTF-8 tests/test-crypto-tlscredsx509
> > > # random seed: R02S9b95072a368ad370cdd4c780b8074596
> > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> > > 2: signing structure using RSA-SHA256
> > > 3: ASSERT: common.c[_gnutls_x509_der_encode]:855
> > > 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174
> > > 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834
> > > 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152
> > > Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is
> > > not valid.
> > So it shows its failing inside a asn1_der_coding call, but I can't see
> > why it would fail, especially if the same test suite passes fine on
> > macOS x86_64 hosts.
> 
> 
> It returns ASN1_MEM_ERROR, so the input vector is too small.

Hmm, that's odd - "Value is not valid" corresponds to
ASN1_VALUE_NOT_VALID error code.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Stefan Weil]

Am 27.01.21 um 19:59 schrieb Daniel P. Berrangé:

> On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote:
>> It returns ASN1_MEM_ERROR, so the input vector is too small.
> Hmm, that's odd - "Value is not valid" corresponds to
> ASN1_VALUE_NOT_VALID error code.


I now have built libtasn1 with debug information and -O0 and can confirm 
that asn1_der_coding returns ASN1_MEM_ERROR.

That's not surprising because it is called with *len == 0, while it 
requires at least 398.

Stefan

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Stefan Weil]

Am 27.01.21 um 20:42 schrieb Stefan Weil:

> Am 27.01.21 um 19:59 schrieb Daniel P. Berrangé:
>
>> On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote:
>>> It returns ASN1_MEM_ERROR, so the input vector is too small.
>> Hmm, that's odd - "Value is not valid" corresponds to
>> ASN1_VALUE_NOT_VALID error code.
>
>
> I now have built libtasn1 with debug information and -O0 and can 
> confirm that asn1_der_coding returns ASN1_MEM_ERROR.
>
> That's not surprising because it is called with *len == 0, while it 
> requires at least 398.


My previous report was incomplete.

It's a normal pattern that asn1_der_coding is first called with vector 
length 0, then returns ASN1_MEM_ERROR and the required length which is 
used to allocate memory for the following call, so that was a false track.

The debug libtasn1 gives a different output:

% LANG=C tests/test-crypto-tlscredsx509
# random seed: R02S478dda7333f4b9f0f84d8d2a7da7eb08
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: Disabling X.509 extensions.
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
2: signing structure using RSA-SHA256
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_export]:2961
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_export]:2961
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_export]:2961
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_export]:2961
1..39
# Start of qcrypto tests
# Start of tlscredsx509 tests
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 1 /qcrypto/tlscredsx509/perfectserver
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 2 /qcrypto/tlscredsx509/perfectclient
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 3 /qcrypto/tlscredsx509/goodca1
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 4 /qcrypto/tlscredsx509/goodca2
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 5 /qcrypto/tlscredsx509/goodca3
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: verify.c[verify_crt]:758
3: ASSERT: verify.c[verify_crt]:824
3: ASSERT: verify.c[verify_crt]:831
3: ASSERT: verify.c[_gnutls_verify_crt_status]:1023
ok 6 /qcrypto/tlscredsx509/badca1
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
ok 7 /qcrypto/tlscredsx509/badca2
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
ok 8 /qcrypto/tlscredsx509/badca3
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 9 /qcrypto/tlscredsx509/goodserver1
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 10 /qcrypto/tlscredsx509/goodserver2
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 11 /qcrypto/tlscredsx509/goodserver3
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 12 /qcrypto/tlscredsx509/goodserver4
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 13 /qcrypto/tlscredsx509/goodserver5
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 14 /qcrypto/tlscredsx509/goodserver6
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 15 /qcrypto/tlscredsx509/goodserver7
ok 16 /qcrypto/tlscredsx509/badserver1
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
ok 17 /qcrypto/tlscredsx509/badserver2
ok 18 /qcrypto/tlscredsx509/badserver3
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 19 /qcrypto/tlscredsx509/goodclient1
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 20 /qcrypto/tlscredsx509/goodclient2
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 21 /qcrypto/tlscredsx509/goodclient3
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 22 /qcrypto/tlscredsx509/goodclient4
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 23 /qcrypto/tlscredsx509/goodclient5
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 24 /qcrypto/tlscredsx509/goodclient6
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
ok 25 /qcrypto/tlscredsx509/goodclient7
ok 26 /qcrypto/tlscredsx509/badclient1
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
ok 27 /qcrypto/tlscredsx509/badclient2
ok 28 /qcrypto/tlscredsx509/badclient3
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
ok 29 /qcrypto/tlscredsx509/expired1
ok 30 /qcrypto/tlscredsx509/expired2
ok 31 /qcrypto/tlscredsx509/expired3
3: ASSERT: common.c[_gnutls_copy_string]:1571
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465
3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040
3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459
3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524
3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469
3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110
3: ASSERT: x509.c[get_alt_name]:1854
3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
**
ERROR:../../../tests/test-crypto-tlscredsx509.c:119:test_tls_creds: 
assertion failed: (creds == NULL)
Bail out! 
ERROR:../../../tests/test-crypto-tlscredsx509.c:119:test_tls_creds: 
assertion failed: (creds == NULL)
zsh: abort      LANG=C tests/test-crypto-tlscredsx509

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Roman Bolshakov]

On Wed, Jan 27, 2021 at 06:59:17PM +0000, Daniel P. Berrangé wrote:
> On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote:
> > Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé:
> > 
> > > On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote:
> > > > Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé:
> > > > 
> > > > > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS"
> > > > > line and then re-build and re-run the test case.
> > > > > 
> > > > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign
> > > > > that might give us useful info.
> > > > > 
> > > > > Regards,
> > > > > Daniel
> > > > 
> > > > % LANG=C.UTF-8 tests/test-crypto-tlscredsx509
> > > > # random seed: R02S9b95072a368ad370cdd4c780b8074596
> > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> > > > 2: signing structure using RSA-SHA256
> > > > 3: ASSERT: common.c[_gnutls_x509_der_encode]:855
> > > > 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174
> > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834
> > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152
> > > > Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is
> > > > not valid.
> > > So it shows its failing inside a asn1_der_coding call, but I can't see
> > > why it would fail, especially if the same test suite passes fine on
> > > macOS x86_64 hosts.
> > 
> > 
> > It returns ASN1_MEM_ERROR, so the input vector is too small.
> 
> Hmm, that's odd - "Value is not valid" corresponds to
> ASN1_VALUE_NOT_VALID error code.
> 

Hi Daniel, Stefan,

It's interesting that "make check" of libtasn1 fails with three tests
and two of them produce VALUE_NOT_VALID error.

The failing tests are:
  FAIL: Test_parser
  FAIL: Test_tree
  FAIL: copynode

Full test log:
===============================================
   GNU Libtasn1 4.16.0: tests/test-suite.log
===============================================

# TOTAL: 30
# PASS:  27
# SKIP:  0
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: Test_parser
=================

ERROR N. 1:
  Line 5 - TEST_PARSER2 { } DEFINITIONS IMPLICIT TAGS ::= BEGIN int1 ::= INTEGER END
  Error expected: SYNTAX_ERROR - Test_parser_ERROR.asn:6: Error: syntax error, unexpected IDENTIFIER, expecting $end near 'TEST_PARSER'
  Error detected: SYNTAX_ERROR - Test_parser_ERROR.asn:6: Error: syntax error, unexpected IDENTIFIER, expecting end of file near 'TEST_PARSER'

FAIL Test_parser (exit status: 1)

FAIL: Test_tree
===============

./Test_tree.asn:121: Warning: VisibleString is a built-in ASN.1 type.
./Test_tree.asn:123: Warning: NumericString is a built-in ASN.1 type.
./Test_tree.asn:125: Warning: IA5String is a built-in ASN.1 type.
./Test_tree.asn:127: Warning: TeletexString is a built-in ASN.1 type.
./Test_tree.asn:129: Warning: PrintableString is a built-in ASN.1 type.
./Test_tree.asn:131: Warning: UniversalString is a built-in ASN.1 type.
./Test_tree.asn:134: Warning: BMPString is a built-in ASN.1 type.
./Test_tree.asn:138: Warning: UTF8String is a built-in ASN.1 type.
Error at line 707
ERROR in 254:
  Action 18 - 
  Error expected: MEM_ERROR - 79
  Error detected: VALUE_NOT_VALID - 0

FAIL Test_tree (exit status: 1)

FAIL: copynode
==============

./pkix.asn:332: Warning: VisibleString is a built-in ASN.1 type.
./pkix.asn:334: Warning: NumericString is a built-in ASN.1 type.
./pkix.asn:336: Warning: IA5String is a built-in ASN.1 type.
./pkix.asn:338: Warning: TeletexString is a built-in ASN.1 type.
./pkix.asn:340: Warning: PrintableString is a built-in ASN.1 type.
./pkix.asn:342: Warning: UniversalString is a built-in ASN.1 type.
./pkix.asn:345: Warning: BMPString is a built-in ASN.1 type.
./pkix.asn:349: Warning: UTF8String is a built-in ASN.1 type.
LIBTASN1 ERROR: VALUE_NOT_VALID
Cannot copy node
FAIL copynode (exit status: 1)

Regards,
Roman

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Daniel P. Berrangé]

On Fri, Jan 29, 2021 at 11:43:32AM +0300, Roman Bolshakov wrote:
> On Wed, Jan 27, 2021 at 06:59:17PM +0000, Daniel P. Berrangé wrote:
> > On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote:
> > > Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé:
> > > 
> > > > On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote:
> > > > > Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé:
> > > > > 
> > > > > > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS"
> > > > > > line and then re-build and re-run the test case.
> > > > > > 
> > > > > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign
> > > > > > that might give us useful info.
> > > > > > 
> > > > > > Regards,
> > > > > > Daniel
> > > > > 
> > > > > % LANG=C.UTF-8 tests/test-crypto-tlscredsx509
> > > > > # random seed: R02S9b95072a368ad370cdd4c780b8074596
> > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> > > > > 2: signing structure using RSA-SHA256
> > > > > 3: ASSERT: common.c[_gnutls_x509_der_encode]:855
> > > > > 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174
> > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834
> > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152
> > > > > Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is
> > > > > not valid.
> > > > So it shows its failing inside a asn1_der_coding call, but I can't see
> > > > why it would fail, especially if the same test suite passes fine on
> > > > macOS x86_64 hosts.
> > > 
> > > 
> > > It returns ASN1_MEM_ERROR, so the input vector is too small.
> > 
> > Hmm, that's odd - "Value is not valid" corresponds to
> > ASN1_VALUE_NOT_VALID error code.
> > 
> 
> Hi Daniel, Stefan,
> 
> It's interesting that "make check" of libtasn1 fails with three tests
> and two of them produce VALUE_NOT_VALID error.
> 
> The failing tests are:
>   FAIL: Test_parser
>   FAIL: Test_tree
>   FAIL: copynode

That's interesting. Assuming 'make check' for libtasn1 succeeeds on
x86_64 macOS, then I'm inclined to blame this whole problem on
libtasn1 not QEMU.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Roman Bolshakov]

On Fri, Jan 29, 2021 at 09:53:27AM +0000, Daniel P. Berrangé wrote:
> On Fri, Jan 29, 2021 at 11:43:32AM +0300, Roman Bolshakov wrote:
> > On Wed, Jan 27, 2021 at 06:59:17PM +0000, Daniel P. Berrangé wrote:
> > > On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote:
> > > > Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé:
> > > > 
> > > > > On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote:
> > > > > > Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé:
> > > > > > 
> > > > > > > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS"
> > > > > > > line and then re-build and re-run the test case.
> > > > > > > 
> > > > > > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign
> > > > > > > that might give us useful info.
> > > > > > > 
> > > > > > > Regards,
> > > > > > > Daniel
> > > > > > 
> > > > > > % LANG=C.UTF-8 tests/test-crypto-tlscredsx509
> > > > > > # random seed: R02S9b95072a368ad370cdd4c780b8074596
> > > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> > > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60
> > > > > > 2: signing structure using RSA-SHA256
> > > > > > 3: ASSERT: common.c[_gnutls_x509_der_encode]:855
> > > > > > 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174
> > > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834
> > > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152
> > > > > > Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is
> > > > > > not valid.
> > > > > So it shows its failing inside a asn1_der_coding call, but I can't see
> > > > > why it would fail, especially if the same test suite passes fine on
> > > > > macOS x86_64 hosts.
> > > > 
> > > > 
> > > > It returns ASN1_MEM_ERROR, so the input vector is too small.
> > > 
> > > Hmm, that's odd - "Value is not valid" corresponds to
> > > ASN1_VALUE_NOT_VALID error code.
> > > 
> > 
> > Hi Daniel, Stefan,
> > 
> > It's interesting that "make check" of libtasn1 fails with three tests
> > and two of them produce VALUE_NOT_VALID error.
> > 
> > The failing tests are:
> >   FAIL: Test_parser
> >   FAIL: Test_tree
> >   FAIL: copynode
> 
> That's interesting. Assuming 'make check' for libtasn1 succeeeds on
> x86_64 macOS, then I'm inclined to blame this whole problem on
> libtasn1 not QEMU.
> 

'make check' of libtasn1 doesn't succeed on x86_64 either.

After a session of debugging I believe there's an issue with Clang 12.
Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID
from _asn1_time_der() in libtasn1):

#include <stdio.h>

static int func2(char *foo) {
        fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
        if (foo == NULL) {
                fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
                return 1;
        }
        return 0;
}

int func1(char *foo) {
        int counter = 0;
        if (fprintf(stderr, "IO\n") > 0)
                counter += 10;
        fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, counter);
        if(!func2(foo + counter)) {
                fprintf(stderr, "good\n");
                return 0;
        } else {
                fprintf(stderr, "broken\n");
                return 1;
        }
}

int main() {
        char *foo = NULL;
        return func1(foo);
}


What return value would you expect from the program?

If the program is compiled with -O0/O1 it returns zero exit code.
Here's the output:
IO
func1:16 foo: 0x0 counter 10
func2:4 foo: 0xa
good

If it is compiled with -O2 it returns 1:
IO
func1:16 foo: 0x0 counter 10
func2:4 foo: 0xa
func2:6 foo: 0x0
broken

That happens because clang uses register behind foo from func1 (it has zero
pointer) inside inlined func2 (it should have non zero pointer).

So, immediate workaround would be to downgrade optimization level of libtasn1
to -O1 in homebrew.

I've submitted the issue to Apple bugtracker:
FB8986815

Best regards,
Roman

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[qemu_oss--- via]

On Dienstag, 2. Februar 2021 06:19:42 CET Roman Bolshakov wrote:
> 'make check' of libtasn1 doesn't succeed on x86_64 either.
> 
> After a session of debugging I believe there's an issue with Clang 12.
> Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID
> from _asn1_time_der() in libtasn1):
> 
> #include <stdio.h>
> 
> static int func2(char *foo) {
>         fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
>         if (foo == NULL) {
>                 fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
> return 1;
>         }
>         return 0;
> }
> 
> int func1(char *foo) {
>         int counter = 0;
>         if (fprintf(stderr, "IO\n") > 0)
>                 counter += 10;
>         fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__,
> foo, counter); if(!func2(foo + counter)) {
>                 fprintf(stderr, "good\n");
>                 return 0;
>         } else {
>                 fprintf(stderr, "broken\n");
>                 return 1;
>         }
> }
> 
> int main() {
>         char *foo = NULL;
>         return func1(foo);
> }
> 
> 
> What return value would you expect from the program?
> 
> If the program is compiled with -O0/O1 it returns zero exit code.
> Here's the output:
> IO
> func1:16 foo: 0x0 counter 10
> func2:4 foo: 0xa
> good
> 
> If it is compiled with -O2 it returns 1:
> IO
> func1:16 foo: 0x0 counter 10
> func2:4 foo: 0xa
> func2:6 foo: 0x0
> broken
> 
> That happens because clang uses register behind foo from func1 (it has zero
> pointer) inside inlined func2 (it should have non zero pointer).
> 
> So, immediate workaround would be to downgrade optimization level of
> libtasn1 to -O1 in homebrew.

Hu, confirmed.

clang 12.0.0 on x86_64 Mac fails on that demo with -O2,-O3,-Os, but works with
-O0,-O1.

clang 11.0.3 in contrast works with any optimization level.

It only fails BTW if that test uses exactly a NULL pointer, any other memory 
address (e.g. just (void*)1) works:

#include <stdio.h>

#define FLOOR_VALUE ((void*)1)

static int func2(char *foo) {
        fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
        if (foo == FLOOR_VALUE) {
                fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
                return 1;
        }
        return 0;
}

int func1(char *foo) {
        int counter = 0;
        if (fprintf(stderr, "IO\n") > 0)
                counter += 1;
        fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, 
counter);
        if(!func2(foo + counter)) {
                fprintf(stderr, "good\n");
                return 0;
        } else {
                fprintf(stderr, "broken\n");
                return 1;
        }
}

int main() {
        char *foo = FLOOR_VALUE;
        return func1(foo);
}

Maybe that's some sort of new security feature in clang 12, in the sense of 
something like this:

	VeryLargeStruct *p = NULL;
	p->farMember = value;

to segfault always reliably and exactly with address zero, instead of pure 
luck as of NULL + veryLargeSize.

> I've submitted the issue to Apple bugtracker:
> FB8986815
> 
> Best regards,
> Roman

They could argue that operating on a NULL pointer is undefined behaviour.

Best regards,
Christian Schoenebeck

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Eric Blake]

On 2/1/21 11:19 PM, Roman Bolshakov wrote:

> After a session of debugging I believe there's an issue with Clang 12.
> Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID
> from _asn1_time_der() in libtasn1):
> 
> #include <stdio.h>
> 
> static int func2(char *foo) {
>         fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
>         if (foo == NULL) {
>                 fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
>                 return 1;
>         }
>         return 0;
> }
> 
> int func1(char *foo) {
>         int counter = 0;
>         if (fprintf(stderr, "IO\n") > 0)
>                 counter += 10;
>         fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, counter);
>         if(!func2(foo + counter)) {

This line has unspecified behavior in the C standard.  Adding an integer
to a pointer is only well-specified if the pointer is to an array and
the integer is within the bounds or the slot just past the array.  But
since you called func1(NULL), foo is NOT pointing to an array, and
therefore foo+counter points to garbage, and the compiler is free to
optimize it at will.

>                 fprintf(stderr, "good\n");
>                 return 0;
>         } else {
>                 fprintf(stderr, "broken\n");
>                 return 1;
>         }
> }
> 
> int main() {
>         char *foo = NULL;
>         return func1(foo);
> }
> 
> 
> What return value would you expect from the program?

Because the code is not strictly compliant to the C standard, I'm not
sure what to expect.

> 
> If the program is compiled with -O0/O1 it returns zero exit code.
> Here's the output:
> IO
> func1:16 foo: 0x0 counter 10
> func2:4 foo: 0xa
> good
> 
> If it is compiled with -O2 it returns 1:
> IO
> func1:16 foo: 0x0 counter 10
> func2:4 foo: 0xa
> func2:6 foo: 0x0

And this proves the point that the compiler was able to exploit the
undefined behavior in your program.

> broken
> 
> That happens because clang uses register behind foo from func1 (it has zero
> pointer) inside inlined func2 (it should have non zero pointer).
> 
> So, immediate workaround would be to downgrade optimization level of libtasn1
> to -O1 in homebrew.
> 
> I've submitted the issue to Apple bugtracker:
> FB8986815

Yes, it's annoying that as compilers get smarter, it exposes the
presence of unspecified code in weird ways.  But I don't see this as a
bug in clang, but as a bug in libtasn1 for assuming undefined behavior
produces a sane result.

> 
> Best regards,
> Roman
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[qemu_oss--- via]

On Dienstag, 2. Februar 2021 15:50:24 CET Eric Blake wrote:
> > If the program is compiled with -O0/O1 it returns zero exit code.
> > Here's the output:
> > IO
> > func1:16 foo: 0x0 counter 10
> > func2:4 foo: 0xa
> > good
> > 
> > If it is compiled with -O2 it returns 1:
> > IO
> > func1:16 foo: 0x0 counter 10
> > func2:4 foo: 0xa
> > func2:6 foo: 0x0
> 
> And this proves the point that the compiler was able to exploit the
> undefined behavior in your program.
> 
> > broken
> > 
> > That happens because clang uses register behind foo from func1 (it has
> > zero
> > pointer) inside inlined func2 (it should have non zero pointer).
> > 
> > So, immediate workaround would be to downgrade optimization level of
> > libtasn1 to -O1 in homebrew.
> > 
> > I've submitted the issue to Apple bugtracker:
> > FB8986815
> 
> Yes, it's annoying that as compilers get smarter, it exposes the
> presence of unspecified code in weird ways.  But I don't see this as a
> bug in clang, but as a bug in libtasn1 for assuming undefined behavior
> produces a sane result.

You are right Eric, but nevertheless it's a very aggressive behaviour change 
being introduced way too silent, especially regarding backward compatibility 
like this case proofs.

Personally I find the new semantic NULL + n == NULL makes sense, as it adds 
safety, but I do consider it a bug that clang did not even throw a warning. 
Even when I add -Wnull-pointer-arithmetic it does not complain to me at all.

Best regards,
Christian Schoenebeck

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Eric Blake]

On 2/2/21 10:35 AM, Christian Schoenebeck wrote:

>>> I've submitted the issue to Apple bugtracker:
>>> FB8986815
>>
>> Yes, it's annoying that as compilers get smarter, it exposes the
>> presence of unspecified code in weird ways.  But I don't see this as a
>> bug in clang, but as a bug in libtasn1 for assuming undefined behavior
>> produces a sane result.
> 
> You are right Eric, but nevertheless it's a very aggressive behaviour change 
> being introduced way too silent, especially regarding backward compatibility 
> like this case proofs.
> 
> Personally I find the new semantic NULL + n == NULL makes sense, as it adds 
> safety, but I do consider it a bug that clang did not even throw a warning. 
> Even when I add -Wnull-pointer-arithmetic it does not complain to me at all.

Yes, you do have a valid argument: any compiler that is going to
optimize on our undefined behavior, but fails to give us a -Wxyz option
to ferret out those spots in our code in order to avoid them in the
first place, has a poor QoI, and it is worth filing a bug against that
compiler to have it not be so silent.  Or put another way, there is a
subtle difference between arguing that "the compiler is miscompiling my
program" (which is demonstrably false per the standard's permission for
the compiler to do whatever it wants on undefined code, but if true
would represent a regression) and "the compiler is not helping me
eradicate undefined behavior from my dusty-deck code" (which is
demonstrably true), and the latter is definitely worthy of being
designated a clang bug (but not regression, rather, you just got lucky
that your code previously did what you wanted in spite of its
undefinedness).  And that applies whether or not we also pursue the
parallel course of action of fixing the actual undefined-code bug in
libtasn1 that triggered this discussion.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Stefan Weil]

Am 02.02.21 um 18:14 schrieb Eric Blake:

> Yes, you do have a valid argument: any compiler that is going to
> optimize on our undefined behavior, but fails to give us a -Wxyz option
> to ferret out those spots in our code in order to avoid them in the
> first place, has a poor QoI, and it is worth filing a bug against that
> compiler to have it not be so silent.  Or put another way, there is a
> subtle difference between arguing that "the compiler is miscompiling my
> program" (which is demonstrably false per the standard's permission for
> the compiler to do whatever it wants on undefined code, but if true
> would represent a regression) and "the compiler is not helping me
> eradicate undefined behavior from my dusty-deck code" (which is
> demonstrably true), and the latter is definitely worthy of being
> designated a clang bug (but not regression, rather, you just got lucky
> that your code previously did what you wanted in spite of its
> undefinedness).  And that applies whether or not we also pursue the
> parallel course of action of fixing the actual undefined-code bug in
> libtasn1 that triggered this discussion.


I agree that the compiler should have given a warning. It did not even 
with -Weverything.

The code uses NULL + offset constructs, so requires a fix.

https://gitlab.com/gnutls/libtasn1/-/merge_requests/71 fixes the unit 
tests of libtasn1 for me, maybe also the test for QEMU which I still 
have to check.

Regards,

Stefan

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Stefan Weil]

Am 02.02.21 um 21:31 schrieb Stefan Weil:

> The code uses NULL + offset constructs, so requires a fix.
>
> https://gitlab.com/gnutls/libtasn1/-/merge_requests/71 fixes the unit 
> tests of libtasn1 for me, maybe also the test for QEMU which I still 
> have to check.
>

The QEMU test passes with the patch for libtasn1:

stefan@mini clang % tests/test-crypto-tlscredsx509
# random seed: R02S0b9c3f2459ee914a95bb1f9e28441dd9
1..39
# Start of qcrypto tests
# Start of tlscredsx509 tests
ok 1 /qcrypto/tlscredsx509/perfectserver
ok 2 /qcrypto/tlscredsx509/perfectclient
ok 3 /qcrypto/tlscredsx509/goodca1
ok 4 /qcrypto/tlscredsx509/goodca2
ok 5 /qcrypto/tlscredsx509/goodca3
ok 6 /qcrypto/tlscredsx509/badca1
ok 7 /qcrypto/tlscredsx509/badca2
ok 8 /qcrypto/tlscredsx509/badca3
ok 9 /qcrypto/tlscredsx509/goodserver1
ok 10 /qcrypto/tlscredsx509/goodserver2
ok 11 /qcrypto/tlscredsx509/goodserver3
ok 12 /qcrypto/tlscredsx509/goodserver4
ok 13 /qcrypto/tlscredsx509/goodserver5
ok 14 /qcrypto/tlscredsx509/goodserver6
ok 15 /qcrypto/tlscredsx509/goodserver7
ok 16 /qcrypto/tlscredsx509/badserver1
ok 17 /qcrypto/tlscredsx509/badserver2
ok 18 /qcrypto/tlscredsx509/badserver3
ok 19 /qcrypto/tlscredsx509/goodclient1
ok 20 /qcrypto/tlscredsx509/goodclient2
ok 21 /qcrypto/tlscredsx509/goodclient3
ok 22 /qcrypto/tlscredsx509/goodclient4
ok 23 /qcrypto/tlscredsx509/goodclient5
ok 24 /qcrypto/tlscredsx509/goodclient6
ok 25 /qcrypto/tlscredsx509/goodclient7
ok 26 /qcrypto/tlscredsx509/badclient1
ok 27 /qcrypto/tlscredsx509/badclient2
ok 28 /qcrypto/tlscredsx509/badclient3
ok 29 /qcrypto/tlscredsx509/expired1
ok 30 /qcrypto/tlscredsx509/expired2
ok 31 /qcrypto/tlscredsx509/expired3
ok 32 /qcrypto/tlscredsx509/inactive1
ok 33 /qcrypto/tlscredsx509/inactive2
ok 34 /qcrypto/tlscredsx509/inactive3
ok 35 /qcrypto/tlscredsx509/chain1
ok 36 /qcrypto/tlscredsx509/chain2
ok 37 /qcrypto/tlscredsx509/missingca
ok 38 /qcrypto/tlscredsx509/missingserver
ok 39 /qcrypto/tlscredsx509/missingclient
# End of tlscredsx509 tests
# End of qcrypto tests

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Daniel P. Berrangé]

On Tue, Feb 02, 2021 at 09:50:39PM +0100, Stefan Weil wrote:
> Am 02.02.21 um 21:31 schrieb Stefan Weil:
> 
> > The code uses NULL + offset constructs, so requires a fix.
> > 
> > https://gitlab.com/gnutls/libtasn1/-/merge_requests/71 fixes the unit
> > tests of libtasn1 for me, maybe also the test for QEMU which I still
> > have to check.
> > 
> 
> The QEMU test passes with the patch for libtasn1:

That's great, thanks for chasing this problem.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Daniel P. Berrangé]

On Tue, Feb 02, 2021 at 08:50:24AM -0600, Eric Blake wrote:
> On 2/1/21 11:19 PM, Roman Bolshakov wrote:
> 
> > After a session of debugging I believe there's an issue with Clang 12.
> > Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID
> > from _asn1_time_der() in libtasn1):
> > 
> > #include <stdio.h>
> > 
> > static int func2(char *foo) {
> >         fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
> >         if (foo == NULL) {
> >                 fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
> >                 return 1;
> >         }
> >         return 0;
> > }
> > 
> > int func1(char *foo) {
> >         int counter = 0;
> >         if (fprintf(stderr, "IO\n") > 0)
> >                 counter += 10;
> >         fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, counter);
> >         if(!func2(foo + counter)) {
> 
> This line has unspecified behavior in the C standard.  Adding an integer
> to a pointer is only well-specified if the pointer is to an array and
> the integer is within the bounds or the slot just past the array.  But
> since you called func1(NULL), foo is NOT pointing to an array, and
> therefore foo+counter points to garbage, and the compiler is free to
> optimize it at will.
> 
> >                 fprintf(stderr, "good\n");
> >                 return 0;
> >         } else {
> >                 fprintf(stderr, "broken\n");
> >                 return 1;
> >         }
> > }
> > 
> > int main() {
> >         char *foo = NULL;
> >         return func1(foo);
> > }
> > 
> > 
> > What return value would you expect from the program?
> 
> Because the code is not strictly compliant to the C standard, I'm not
> sure what to expect.

Roman invented this example to illustrate the problem with libtasn1,
so I wonder if this suggests that libtasn1 is relying on undefined
C behaviour too.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[Roman Bolshakov]

On Tue, Feb 02, 2021 at 08:50:24AM -0600, Eric Blake wrote:
> On 2/1/21 11:19 PM, Roman Bolshakov wrote:
> 
> > After a session of debugging I believe there's an issue with Clang 12.
> > Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID
> > from _asn1_time_der() in libtasn1):
> > 
> > #include <stdio.h>
> > 
> > static int func2(char *foo) {
> >         fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
> >         if (foo == NULL) {
> >                 fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo);
> >                 return 1;
> >         }
> >         return 0;
> > }
> > 
> > int func1(char *foo) {
> >         int counter = 0;
> >         if (fprintf(stderr, "IO\n") > 0)
> >                 counter += 10;
> >         fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, counter);
> >         if(!func2(foo + counter)) {
> 
> This line has unspecified behavior in the C standard.  Adding an integer
> to a pointer is only well-specified if the pointer is to an array and
> the integer is within the bounds or the slot just past the array.  But
> since you called func1(NULL), foo is NOT pointing to an array, and
> therefore foo+counter points to garbage, and the compiler is free to
> optimize it at will.

Hi Eric,

Thanks a lot for pointing out this. It was surprising to me but
interesting:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2012.htm#clarifying-the-c-memory-object-model-out-of-bounds-pointer-arithmetic
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2222.htm#pointer-arithmetic

As far as I understand wording in the standard, null pointer doesn't
point to an object (6.3.2.3p3). Therefore pointer arithmetic exception
for non-array objects (6.5.6p7) doesn't apply to null pointers but it
does apply to valid object pointers:

"For the purposes of these operators, a pointer to an object that is not
an element of an array behaves the same as a pointer to the first
element of an array of length one with the type of the object as its
element type."

So I was curious how clang would behave if we pass NULL conditionally.
We could do that by changing main() in the example above to:

int main(int argc, char *argv[]) {
        int ret;
        char *foo;

        if (argc > 1)
                foo = malloc(90 * sizeof(char));
        else
                foo = NULL;

        ret = func1(foo);

        if (argc > 1)
                free(foo);

        return ret;
}

And it returns "good" for specified behaviour (if foo points to malloc'd
memory):
 $ ./a.out f
 IO
 func1:17 foo: 0x14be06790 counter 10
 func2:5 foo: 0x14be0679a
 good

The behaviour is different if foo is initialized to NULL.
 $ ./a.out
 IO
 func1:17 foo: 0x0 counter 10
 func2:5 foo: 0xa
 func2:7 foo: 0x0
 broken

> > 
> > So, immediate workaround would be to downgrade optimization level of libtasn1
> > to -O1 in homebrew.
> > 
> > I've submitted the issue to Apple bugtracker:
> > FB8986815
> 
> Yes, it's annoying that as compilers get smarter, it exposes the
> presence of unspecified code in weird ways.  But I don't see this as a
> bug in clang, but as a bug in libtasn1 for assuming undefined behavior
> produces a sane result.
> 

Yes, strictly speaking the compiler is compliant. Given the example
libtasn1 should likely introduce a second variable for an integer
offset instead of relying on null pointer arithmetic.

It'd also be good if clang would print an error or a warning for null
pointer arithmetic.

Thanks,
Roman

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

SHA-1: 94c13c1048378cbffe552b6fe5c960dc04eaefb2

* gcrypt: test_tls_psk_init should write binary file instead text file.

On windows, if open file with "w", it's will automatically convert
"\n" to "\r\n" when writing to file.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Is this related?

On Wed, Jan 27, 2021 at 12:37 AM Peter Maydell <peter.maydell@linaro.org>
wrote:

> My Big Sur/Apple Silicon system fails "make check" in
> test-crypto-tlscredsx509:
>
> MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
> G_TEST_SRCDIR=/Users/pm215/qemu/tests
> G_TEST_BUILDDIR=/Users/pm215/qemu/build/all/tests
> tests/test-crypto-tlscredsx509 --tap -k
>
> ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
> Failed to sign certificate ASN1 parser: Value is not valid.
> ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
> sign certificate ASN1 parser: Value is not valid.
> make: *** [run-test-70] Error 1
>
>
> Does this failure ring any bells for anybody?
>
> Here's the crypto part of the meson-log:
>
>   Crypto
>                      TLS priority: "NORMAL"
>                    GNUTLS support: YES
>                         libgcrypt: NO
>                            nettle: YES
>                               XTS: YES
>                      crypto afalg: NO
>                          rng-none: NO
>                     Linux keyring: NO
>
>
> thanks
> -- PMM
>
>

-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[-- Attachment #2: Type: text/html, Size: 2225 bytes --]