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):
>
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
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
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
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
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:
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):
>
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
>
> static int func2(char *foo) {
>
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()
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
Is this related?
On Wed, Jan 27, 2021 at
On Fri, Jan 29, 2021 at 09:53:27AM +, 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 +, Daniel P. Berrangé wrote:
> > > On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote:
> > > > Am 27.01.21 um
On Fri, Jan 29, 2021 at 11:43:32AM +0300, Roman Bolshakov wrote:
> On Wed, Jan 27, 2021 at 06:59:17PM +, 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
On Wed, Jan 27, 2021 at 06:59:17PM +, 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
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
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
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
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
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
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,
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 +, Peter Maydell wrote:
> > > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé
> > > wrote:
> > > > On Tue, Jan 26, 2021 at 04:32:08PM
Am 27.01.21 um 13:17 schrieb Daniel P. Berrangé:
On Tue, Jan 26, 2021 at 04:41:13PM +, Peter Maydell wrote:
On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé wrote:
On Tue, Jan 26, 2021 at 04:32:08PM +, Peter Maydell wrote:
** (tests/test-crypto-tlscredsx509:35180): CRITICAL **:
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 +, Peter Maydell wrote:
> > > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé
> wrote:
> > > > On Tue, Jan 26,
On Mittwoch, 27. Januar 2021 13:17:23 CET Daniel P. Berrangé wrote:
> On Tue, Jan 26, 2021 at 04:41:13PM +, Peter Maydell wrote:
> > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé
wrote:
> > > On Tue, Jan 26, 2021 at 04:32:08PM +, Peter Maydell wrote:
> > > > **
On Tue, Jan 26, 2021 at 04:41:13PM +, Peter Maydell wrote:
> On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé wrote:
> >
> > On Tue, Jan 26, 2021 at 04:32:08PM +, Peter Maydell wrote:
> > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590:
> > > Failed to sign
On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé wrote:
>
> On Tue, Jan 26, 2021 at 04:32:08PM +, 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 -
On Tue, Jan 26, 2021 at 04:32:08PM +, 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
>
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
**
27 matches
Mail list logo
