| Message ID | 20210317110512.583747-3-thuth@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | Fix atomic test in "configure" + bump FreeBSD CI to 12.2 | expand |
On Wed, 17 Mar 2021 at 11:09, Thomas Huth <thuth@redhat.com> wrote: > > FreeBSD version 12.1 is out of service now, and the task in the > Cirrus-CI is failing. Update to 12.2 to get it working again. > Unfortunately, there is a bug in libtasn1 that triggers with the > new version of Clang that is used there (see this thread for details: > https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00739.html ), > so we have to disable gnutls for now to make it work again. We can > enable it later again once libtasn1 has been fixed in FreeBSD. > > Signed-off-by: Thomas Huth <thuth@redhat.com> Is it feasible to make configure check for "is libtasn1 broken"? I guess since it only shows up as "when you try to use it it fails" that would be a runtime check rather than compile time, which isn't really possible :-( thanks -- PMM
On 17/03/2021 12.16, Peter Maydell wrote: > On Wed, 17 Mar 2021 at 11:09, Thomas Huth <thuth@redhat.com> wrote: >> >> FreeBSD version 12.1 is out of service now, and the task in the >> Cirrus-CI is failing. Update to 12.2 to get it working again. >> Unfortunately, there is a bug in libtasn1 that triggers with the >> new version of Clang that is used there (see this thread for details: >> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00739.html ), >> so we have to disable gnutls for now to make it work again. We can >> enable it later again once libtasn1 has been fixed in FreeBSD. >> >> Signed-off-by: Thomas Huth <thuth@redhat.com> > > Is it feasible to make configure check for "is libtasn1 broken"? > I guess since it only shows up as "when you try to use it > it fails" that would be a runtime check rather than compile > time, which isn't really possible :-( I don't really have a clue about this crypto stuff... Daniel, Stefan, Roman, Christian, Eric ... you debugged the original problem on macOS, do you think it's possible to add a check for this libtasn1 problem to our "configure" (or meson.build file)? Thomas
On Wed, Mar 17, 2021 at 01:44:05PM +0100, Thomas Huth wrote: > On 17/03/2021 12.16, Peter Maydell wrote: > > On Wed, 17 Mar 2021 at 11:09, Thomas Huth <thuth@redhat.com> wrote: > > > > > > FreeBSD version 12.1 is out of service now, and the task in the > > > Cirrus-CI is failing. Update to 12.2 to get it working again. > > > Unfortunately, there is a bug in libtasn1 that triggers with the > > > new version of Clang that is used there (see this thread for details: > > > https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00739.html ), > > > so we have to disable gnutls for now to make it work again. We can > > > enable it later again once libtasn1 has been fixed in FreeBSD. > > > > > > Signed-off-by: Thomas Huth <thuth@redhat.com> > > > > Is it feasible to make configure check for "is libtasn1 broken"? > > I guess since it only shows up as "when you try to use it > > it fails" that would be a runtime check rather than compile > > time, which isn't really possible :-( > > I don't really have a clue about this crypto stuff... Daniel, Stefan, Roman, > Christian, Eric ... you debugged the original problem on macOS, do you think > it's possible to add a check for this libtasn1 problem to our "configure" > (or meson.build file)? It is tricky because the flaw is not specific to the version of tasn1, rather to the combination of tasn1 and the compiler used, so there's no simple way to detect it statically from configure. If don't want the big hammer of disabling gnutls, perhaps adding a flag to disable tasn1 would be simpler, as that would only disable test suite, and no actual QEMU core functionality (which is all working fine) Regards, Daniel
On Wed, Mar 17, 2021 at 01:44:05PM +0100, Thomas Huth wrote: > On 17/03/2021 12.16, Peter Maydell wrote: > > On Wed, 17 Mar 2021 at 11:09, Thomas Huth <thuth@redhat.com> wrote: > > > > > > FreeBSD version 12.1 is out of service now, and the task in the > > > Cirrus-CI is failing. Update to 12.2 to get it working again. > > > Unfortunately, there is a bug in libtasn1 that triggers with the > > > new version of Clang that is used there (see this thread for details: > > > https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00739.html ), > > > so we have to disable gnutls for now to make it work again. We can > > > enable it later again once libtasn1 has been fixed in FreeBSD. > > > > > > Signed-off-by: Thomas Huth <thuth@redhat.com> > > > > Is it feasible to make configure check for "is libtasn1 broken"? > > I guess since it only shows up as "when you try to use it > > it fails" that would be a runtime check rather than compile > > time, which isn't really possible :-( > > I don't really have a clue about this crypto stuff... Daniel, Stefan, Roman, > Christian, Eric ... you debugged the original problem on macOS, do you think > it's possible to add a check for this libtasn1 problem to our "configure" > (or meson.build file)? > Hi, We need to define an ASN.1 object https://gitlab.com/gnutls/libtasn1/-/blob/master/tests/Test_tree.c#L230 {ACT_CREATE, "TEST_TREE.OidAndTimeTest", 0, 0, ASN1_SUCCESS, __LINE__}, The object is: OidAndTimeTest ::= SEQUENCE{ set SET OF INTEGER, oid OBJECT IDENTIFIER, time2 GeneralizedTime, bol BOOLEAN, oct OCTET STRING, bit BIT STRING OPTIONAL, bol2 BOOLEAN DEFAULT TRUE, enum ENUMERATED {v1(1),v2(2)} DEFAULT v1, any [1] ANY OPTIONAL, gen GeneralString OPTIONAL, time1 UTCTime } Create it with: asn1_create_element (definitions, "TEST.OidAndTimeTest", &asn1_element); and try to get it's DER length to mimic the part of the failing test: https://gitlab.com/gnutls/libtasn1/-/blob/master/tests/Test_tree.c#L254 result = asn1_der_coding (asn1_element, "", NULL, &der_len, errorDescription); The result should be ASN1_MEM_ERROR. Something like this should work as configure-time test. Thanks, Roman
On Wed, 17 Mar 2021 at 13:16, Roman Bolshakov <r.bolshakov@yadro.com> wrote: > result = asn1_der_coding (asn1_element, "", NULL, &der_len, errorDescription); > > The result should be ASN1_MEM_ERROR. > > Something like this should work as configure-time test. Unfortunately at configure time you can't run code, only compile and link it, because you might be cross-compiling. So a test that needs us to actually look at return values from function calls won't work for configure. thanks -- PMM
Daniel P. Berrangé <berrange@redhat.com> writes: > On Wed, Mar 17, 2021 at 01:44:05PM +0100, Thomas Huth wrote: >> On 17/03/2021 12.16, Peter Maydell wrote: >> > On Wed, 17 Mar 2021 at 11:09, Thomas Huth <thuth@redhat.com> wrote: >> > > >> > > FreeBSD version 12.1 is out of service now, and the task in the >> > > Cirrus-CI is failing. Update to 12.2 to get it working again. >> > > Unfortunately, there is a bug in libtasn1 that triggers with the >> > > new version of Clang that is used there (see this thread for details: >> > > https://lists.gnu.org/archive/html/qemu-dove/2021-02/msg00739.html ), >> > > so we have to disable gnutls for now to make it work again. We can >> > > enable it later again once libtasn1 has been fixed in FreeBSD. >> > > >> > > Signed-off-by: Thomas Huth <thuth@redhat.com> >> > >> > Is it feasible to make configure check for "is libtasn1 broken"? >> > I guess since it only shows up as "when you try to use it >> > it fails" that would be a runtime check rather than compile >> > time, which isn't really possible :-( >> >> I don't really have a clue about this crypto stuff... Daniel, Stefan, Roman, >> Christian, Eric ... you debugged the original problem on macOS, do you think >> it's possible to add a check for this libtasn1 problem to our "configure" >> (or meson.build file)? > > It is tricky because the flaw is not specific to the version of > tasn1, rather to the combination of tasn1 and the compiler used, > so there's no simple way to detect it statically from configure. > > If don't want the big hammer of disabling gnutls, perhaps adding > a flag to disable tasn1 would be simpler, as that would only > disable test suite, and no actual QEMU core functionality (which > is all working fine) I suspect we'll forget to remove this flag as well when the time comes. Without adding new things I think this patch would be fine with an additional comments: # --disable-gnutls until libtasn1 is fixed in FreeBSD (#ref?) > > Regards, > Daniel
diff --git a/.cirrus.yml b/.cirrus.yml index bc40a0550d..af118a5a74 100644 --- a/.cirrus.yml +++ b/.cirrus.yml @@ -3,7 +3,7 @@ env: freebsd_12_task: freebsd_instance: - image_family: freebsd-12-1 + image_family: freebsd-12-2 cpu: 8 memory: 8G install_script: @@ -13,7 +13,8 @@ freebsd_12_task: script: - mkdir build - cd build - - ../configure --enable-werror || { cat config.log meson-logs/meson-log.txt; exit 1; } + - ../configure --enable-werror --disable-gnutls + || { cat config.log meson-logs/meson-log.txt; exit 1; } - gmake -j$(sysctl -n hw.ncpu) - gmake -j$(sysctl -n hw.ncpu) check V=1
FreeBSD version 12.1 is out of service now, and the task in the Cirrus-CI is failing. Update to 12.2 to get it working again. Unfortunately, there is a bug in libtasn1 that triggers with the new version of Clang that is used there (see this thread for details: https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00739.html ), so we have to disable gnutls for now to make it work again. We can enable it later again once libtasn1 has been fixed in FreeBSD. Signed-off-by: Thomas Huth <thuth@redhat.com> --- .cirrus.yml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)