For x86 builds the new image uses debian because it has a simpler and has a reproducible way to generate it. The x86 fedora image will remain though.
With the current nettle master oss fuzz still fails to compile (does link statically) due to cnd_memcpy not found:
https://oss-fuzz-build-logs.storage.googleapis.com/log-8fca2d38-422a-47bf-84...
On December 29, 2018 9:40:48 AM UTC, nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
I am not at home to check but most likely a newer openssl is needed.
You can use fedora:29 or fedora:latest
Ok, I'm trying
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 166de71b..f4ed3496 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -1,7 +1,7 @@ variables: BUILD_IMAGES_PROJECT: gnutls/build-images DEBIAN_CROSS_BUILD: buildenv-debian-cross
- FEDORA_BUILD: buildenv-f28
- FEDORA_BUILD: buildenv-f29 FEDORA_X86_BUILD: buildenv-f28-x86 GET_SOURCES_ATTEMPTS: "3"
(Also changing FEDORA_X86_BUILD in a similar way failed).
I've also added needed asserts in eccdata, to satisfy the static analyzer (and I guess eccdata's validation of command line args isn't that robust even efter these changes, but it doesn't really need to be).
Ouch, and it seems the static analyzer now has even more warnings on eccdata. Maybe more asserts needed to tell it that accesses are within the allocated and initialized table size.
Besides that, there's one remaining warning from the static analyzer, on examples/eratosthenes.c. I'm considering just deleting that file.
It was used for generating tables used by bignum-next-prime.c, but that file was deleted a few years ago. It was unused since prime generation was rewritten in 2010. The new (in 2010) code in nettle_random_prime uses a smaller table of the 171 odd primes < 1024, and some auxillary tables to aid trial division. I'm afraid I don't recall what tools were used to prepare those tables.
Regards, /Niels