# uname -a FreeBSD pyrogl.a9development.com 13.1-STABLE FreeBSD 13.1-STABLE stable/13-n254189-0811d18fea91 GENERIC amd64 # git log -1 . commit 2de693838714fb47abc4b9f468ef20e129e31f47 Author: Bernard Spil <brnrd@FreeBSD.org> Date: Sun Sep 25 11:15:46 2022 +0000 security/libressl: Update to 3.5.3 * Make sure you check https://wiki.freebsd.org/LibreSSL/3.5 and UPDATING libtool: compile: cc -DPACKAGE_NAME=\"libressl\" -DPACKAGE_TARNAME=\"libressl\" -DPACKAGE_VERSION=\"3.5.3\" "-DPACKAGE_STRING=\"libressl 3.5.3\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libressl\" -DVERSION=\"3.5.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSIZEOF_TIME_T=8 -DHAVE_SYMLINK=1 -DHAVE_ENDIAN_H=1 -DHAVE_ERR_H=1 -DHAVE_READPASSPHRASE_H=1 -DHAVE_NETINET_IP_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_ARPA_NAMESER_H=1 -DHAVE_NETDB_H=1 -DHAVE_RESOLV_H=1 -DHAVE_ASPRINTF=1 -DHAVE_MEMMEM=1 -DHAVE_READPASSPHRASE=1 -DHAVE_REALLOCARRAY=1 -DHAVE_STRLCAT=1 -DHAVE_STRLCPY=1 -DHAVE_STRNDUP=1 -DHAVE_STRNLEN=1 -DHAVE_STRSEP=1 -DHAVE_STRTONUM=1 -DHAVE_TIMEGM=1 -DHAVE_GETPROGNAME=1 -DHAVE_SYSLOG=1 -DHAVE_ACCEPT4=1 -DHAVE_PIPE2=1 -DHAVE_POLL=1 -DHAVE_SOCKETPAIR=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_ARC4RANDOM_UNIFORM=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_TIMINGSAFE_BCMP=1 -DHAVE_TIMINGSAFE_MEMCMP=1 -DHAVE_DL_ITERATE_PHDR=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_VA_COPY=1 -DHAVE___VA_COPY=1 -DHAS_GNU_WARNING_LONG=1 -I. -I../include -I../include/compat -DLIBRESSL_INTERNAL -D__BEGIN_HIDDEN_DECLS= -D__END_HIDDEN_DECLS= -I../crypto/bio -D_FORTIFY_SOURCE=2 -O2 -pipe -fpic -DPIC -Wl,-rpath,/usr/local/lib -Wl,--as-needed -fstack-protector-strong -fno-strict-aliasing -Wall -std=gnu99 -fno-strict-aliasing -fno-strict-overflow -fstack-protector-strong -DHAVE_GNU_STACK -Qunused-arguments -Wno-pointer-sign -MT d1_pkt.lo -MD -MP -MF .deps/d1_pkt.Tpo -c d1_pkt.c -fPIC -DPIC -o .libs/d1_pkt.o d1_pkt.c:138:8: error: use of undeclared identifier 'BYTE_ORDER' if (BYTE_ORDER == LITTLE_ENDIAN) ^ d1_pkt.c:138:22: error: use of undeclared identifier 'LITTLE_ENDIAN' if (BYTE_ORDER == LITTLE_ENDIAN) ^ 2 errors generated. *** Error code 1 Stop. make[3]: stopped in /usr/ports/security/libressl/work-default/libressl-3.5.3/ssl *** Error code 1 Stop. make[2]: stopped in /usr/ports/security/libressl/work-default/libressl-3.5.3 *** Error code 1 Stop. make[1]: stopped in /usr/ports/security/libressl *** Error code 1 Stop. make: stopped in /usr/ports/security/libressl
Same for 3.5.4: --- ssl_algs.lo --- libtool: compile: cc -DPACKAGE_NAME=\"libressl\" -DPACKAGE_TARNAME=\"libressl\" -DPACKAGE_VERSION=\"3.5.4\" "-DPACKAGE_STRING=\"libressl 3.5.4\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libressl\" -DVERSION=\"3.5.4\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSIZEOF_TIME_T=8 -DHAVE_SYMLINK=1 -DHAVE_ENDIAN_H=1 -DHAVE_ERR_H=1 -DHAVE_READPASSPHRASE_H=1 -DHAVE_NETINET_IP_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_ARPA_NAMESER_H=1 -DHAVE_NETDB_H=1 -DHAVE_RESOLV_H=1 -DHAVE_ASPRINTF=1 -DHAVE_MEMMEM=1 -DHAVE_READPASSPHRASE=1 -DHAVE_REALLOCARRAY=1 -DHAVE_STRLCAT=1 -DHAVE_STRLCPY=1 -DHAVE_STRNDUP=1 -DHAVE_STRNLEN=1 -DHAVE_STRSEP=1 -DHAVE_STRTONUM=1 -DHAVE_TIMEGM=1 -DHAVE_GETPROGNAME=1 -DHAVE_SYSLOG=1 -DHAVE_ACCEPT4=1 -DHAVE_PIPE2=1 -DHAVE_POLL=1 -DHAVE_SOCKETPAIR=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_ARC4RANDOM_UNIFORM=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_TIMINGSAFE_BCMP=1 -DHAVE_TIMINGSAFE_MEMCMP=1 -DHAVE_DL_ITERATE_PHDR=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_VA_COPY=1 -DHAVE___VA_COPY=1 -DHAS_GNU_WARNING_LONG=1 -I. -I../include -I../include/compat -DLIBRESSL_INTERNAL -D__BEGIN_HIDDEN_DECLS= -D__END_HIDDEN_DECLS= -I../crypto/bio -D_FORTIFY_SOURCE=2 -O2 -pipe -O3 -pipe -funroll-loops -mretpoline -fpic -DPIC -Wl,-rpath,/usr/local/lib -Wl,--as-needed -fstack-protector-strong -fno-strict-aliasing -fdebug-prefix-map=/tmp/ports/usr/ports/security/libressl/work-default/libressl-3.5.4=. -Wall -std=gnu99 -fno-strict-aliasing -fno-strict-overflow -fstack-protector-strong -DHAVE_GNU_STACK -Qunused-arguments -Wno-pointer-sign -MT ssl_algs.lo -MD -MP -MF .deps/ssl_algs.Tpo -c ssl_algs.c -o ssl_algs.o >/dev/null 2>&1 --- d1_pkt.lo --- d1_pkt.c:138:8: error: use of undeclared identifier 'BYTE_ORDER' if (BYTE_ORDER == LITTLE_ENDIAN) ^ d1_pkt.c:138:22: error: use of undeclared identifier 'LITTLE_ENDIAN' if (BYTE_ORDER == LITTLE_ENDIAN) ^ 2 errors generated. *** [d1_pkt.lo] Error code 1
Same here with 3.5.4, no problem with 3.5.3. FreeBSD 13.2-PRERELEASE #0 stable/13-4ad47cfc amd64
Created attachment 240057 [details] patch This works for me.
Works for me, thanks
(In reply to jakub_lach from comment #4) Spoke too fast. fatal: unable to access 'https://git.freebsd.org/src.git/': LibreSSL/3.5.4: error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt
/usr/local/bin/openssl s_client -connect youtube.com:443 -tls1_2 - work /usr/local/bin/openssl s_client -connect youtube.com:443 - NOT work /usr/bin/openssl s_client -connect youtube.com:443 - work some how tls 1.3 is broken here.
I have try to build 3.5.3 with this patch and it fail with tls 1.3 like 3.5.4. Same 3.5.3 from package (was build many time ago) work fine. IMHO issue is outside port.
Created attachment 240070 [details] patch This passes make test and tls 1.3 works. In first patch I miss other files that includes endian.h.
*** Bug 270072 has been marked as a duplicate of this bug. ***
I'm having this issue as well. In fact, I am building the exact same ports tree with 12.4-STABLE and libressl builds just fine. 13.2-STABLE will not build, citing this very issue. I concur that the problem may be outside the port.
And yet, Ivan's patch builds fine. Thank you Ivan. I'll test whether it works or not for TLS 1.3 soon enough.
Both sides, client (via curl) and server (via nginx) appear to work with this patch.
Created attachment 240941 [details] patch include/compat/endian.h Can you please also test attached patch? That looks to be more the "royal" way of doing things. I don't have a CURRENT system to test on. For now, I'll add Ivan's patch, but this should be reported/included upstream.
Patching github.com/libressl/portable would be appreciated. If needed I can provide the patch upstream.
(In reply to Bernard Spil from comment #13) Why CURRENT while this issue is on -STABLE? --- d1_pkt.lo --- d1_pkt.c:138:8: error: use of undeclared identifier 'BYTE_ORDER' if (BYTE_ORDER == LITTLE_ENDIAN) ^ d1_pkt.c:138:22: error: use of undeclared identifier 'LITTLE_ENDIAN' if (BYTE_ORDER == LITTLE_ENDIAN) ^ 2 errors generated. *** [d1_pkt.lo] Error code 1 make[3]: stopped in /usr/obj/usr/ports/security/libressl/work-default/libressl-3.6.2/ssl 1 error FreeBSD 13.2-STABLE #0 stable/13-aa728e209 amd64
(In reply to jakub_lach from comment #15) meant STABLE... "Good" to see the issue persists with LibreSSL 3.6. Trying to piece this together from 2023-03-16 snapshot base.txz. Working on LibreBSD with FreeBSD 13.2-RC3 & LibreSSL 3.7.1 I ran into the same error. Worked around that by using HAVE_MACHINE_ENDIAN_H in stead of HAVE_ENDIAN_H. Now to figure out what knobs to turn to get the port to do this.
(In reply to Bernard Spil from comment #16) I wonder: why 3.6.2 and not 3.7.x? You can use: make test to check port, in past it help me with patch.
(In reply to Bernard Spil from comment #13) I'm happy to test this patch, but should I back the other one out first?
Looks like this is a POSIX issue with the Base OS. As per POSIX: http://www.opengroup.org/austin/docs/austin_514.txt The <endian.h> header shall define at least the following macros for use in determining host byte order for integer types: BYTE_ORDER this macro shall have a value equal to one of the *_ENDIAN macros in this header. LITTLE_ENDIAN if BYTE_ORDER == LITTLE_ENDIAN, the host byte order is from least significant to most significant. BIG_ENDIAN if BYTE_ORDER == BIG_ENDIAN, the host byte order is from most significant to least significant. and apparently it doesn't. Using machine/endian.h in stead unbreaks it. Any hints how I can take this forward?
`/usr/include/endian.h` was introduced for a better linux compatibility in stable two months ago. It sounds that libressl does not handle this new input correctly ?
The weird thing is that ``` #include <stdio.h> #include <endian.h ``` works. but not ``` #include <endian.h #include <stdio.h> ```
Created attachment 240973 [details] change inclusion order
2 notes: 1. Error happen on 13/stable too. 2. There is more than 1 files that uses BYTE_ORDER, all of these files must be covered by patch. Most files contain: #ifdef BYTE_ORDER == LITTLE_ENDIAN or similar and does not produce error on build, but will not work properly and fail on: make test
Including `<sys/_types.h>` at first place in `endian.h` solve the issue. root@llanura:~ # diff -u /usr/include/endian.h.orig /usr/include/endian.h --- /usr/include/endian.h.orig 2023-03-19 20:21:06.799414000 +0100 +++ /usr/include/endian.h 2023-03-19 20:21:11.125166000 +0100 @@ -15,6 +15,7 @@ * FreeBSD's sys/_endian.h is very close to the interface provided on Linux by * glibc's endian.h. */ +#include <sys/_types.h> #include <sys/_endian.h>
Created attachment 240987 [details] endian.h include cdefs.h to get __BSD_VISIBLE.
Please do not commit anything to base. I'm traveling and will look closely at this in 40 hours. However, for endian.h, _types.h was excluded on purpose,if memory serves because other things break if you define too much in endian.h. this is most likely a bug in the port that broke that I missed when I did the 5 or 6 exp runs to get endian.h right.
The compatibility was for glibc's endian.h... I'll check it when I land . The stdio.h vs endian.h order shouldn't matter... sorry for any delays in this, but I'm sitting in the boarding area for my flight... after so many gotchas I'm paranoid about touching this.
I'm on a flight, so I'm not able to do full research. endian.h is *NOT* in posix today. It's not in issue 7. It does look like it's in the issue 8 draft, which is currently being finalized. The problem is two fold. First, sys/_endian.h is not include sys/ctype.h to pick up the visibility macros. Second #if BYTE_ENDIAN == LITTLE_ENDIAN works even if you don't include this file because undefined macros are 0 and 0 == 0. Some of the tests I did thus work accidentally. Sorry for the cut and past, but this should fix it: diff --git a/sys/sys/_endian.h b/sys/sys/_endian.h index 7ac39386e2e1..9c0af610e4a4 100644 --- a/sys/sys/_endian.h +++ b/sys/sys/_endian.h @@ -36,6 +36,9 @@ #error "sys/_endian.h should not be included directly" #endif +/* Pick up visibility macros -- and likely too much name space pollution */ +#include <sys/cdefs.h> + /* BSD Compatiblity */ #define _BYTE_ORDER __BYTE_ORDER__ @@ -66,10 +69,10 @@ #endif /* - * Deprecated variants that don't have enough underscores to be useful in more - * strict namespaces. + * These variants are only well defined for BSD namespace, or for + * newer posix versions (issue 8, forthcoming... */ -#if __BSD_VISIBLE +#if __BSD_VISIBLE || _POSIX_C_SOURCE > 200809 #define LITTLE_ENDIAN _LITTLE_ENDIAN #define BIG_ENDIAN _BIG_ENDIAN #define PDP_ENDIAN _PDP_ENDIAN
... but when the macros are used not in cpp, but in an C if, you get the error reported. Please test my fix. I'll commit it in ~15 hours when I land, catch a connecting flight, get to the hotel and can run a buildworld just to make sure this don't break anything.
@Warner Losh, /libressl/ tests passed successfully with the last patch. Thanks.
https://reviews.freebsd.org/D39176 is the review for my changes, slightly tweaked from what I posted here.
If you make change to system than I can assume that many ports that was build before can be broken. What we will do with that?
(In reply to Ivan Rozhuk from comment #32) You will likely have to rebuild once this change is committed. If you are using poudriere you can force it to rebuild all the packages. Once I see this change land in stable/13 I will be rebuilding everything myself.
(In reply to Dave Hayes from comment #33) What about other FreeBSD ports/packages users?
(In reply to Ivan Rozhuk from comment #34) I am not a FreeBSD committer or ports builder, so I can't speak for them. I would like to think there would be a major rebuild just because of this. However, given that 13.2 is nearing a release, I would presume that this major rebuild of all public ports and packages would happen during or soon after.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ed52baf51bd142b5e32701842346452a7ebe37a5 commit ed52baf51bd142b5e32701842346452a7ebe37a5 Author: Warner Losh <imp@FreeBSD.org> AuthorDate: 2023-03-22 02:25:58 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2023-03-22 02:25:58 +0000 _endian.h: Include sys/ctypes.h for visibility macros BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN will be required by the forthcoming POSIX Issue 8. In addition, they are provided in the BSD compilation environments. However, depending on the order includes happend, sys/cdefs.h may or may not be included when endian.h is included. Include it here so we can safely test __BSD_VISIBLE. Add visibility when we're compiling in the future for issue 8, but since the date number for issue 8 hasn't been fixed, use strictly greater than the issue 7 date.of 200809. This had the side effect of sometimes (in the traditional BSD compliation environment) #if BYTE_ORDER == LITTLE_ENDIAN and #if BYTE_ORDER == BIG_ENDIAN both being true because none of these were defined. This fixes that. It also fixes including it after <stdio.h> but not before. PR: 269249 MFC After: 1d (build related) Reviewed by: kib, emaste Differential Revision: https://reviews.freebsd.org/D39176 Sponsored by: Netflix sys/sys/_endian.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
Nice! About how long can I expect it to take before the above is MFC'd to stable/13?
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4ccd5e64b76bbaa874c50755d17394a7ed195f93 commit 4ccd5e64b76bbaa874c50755d17394a7ed195f93 Author: Warner Losh <imp@FreeBSD.org> AuthorDate: 2023-03-22 02:25:58 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2023-03-22 22:30:51 +0000 _endian.h: Include sys/cdefs.h for visibility macros BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN will be required by the forthcoming POSIX Issue 8. In addition, they are provided in the BSD compilation environments. However, depending on the order includes happend, sys/cdefs.h may or may not be included when endian.h is included. Include it here so we can safely test __BSD_VISIBLE. Add visibility when we're compiling in the future for issue 8, but since the date number for issue 8 hasn't been fixed, use strictly greater than the issue 7 date.of 200809. This had the side effect of sometimes (in the traditional BSD compliation environment) #if BYTE_ORDER == LITTLE_ENDIAN and #if BYTE_ORDER == BIG_ENDIAN both being true because none of these were defined. This fixes that. It also fixes including it after <stdio.h> but not before. PR: 269249 MFC After: 1d (build related) Reviewed by: kib, emaste Differential Revision: https://reviews.freebsd.org/D39176 Sponsored by: Netflix (cherry picked from commit ed52baf51bd142b5e32701842346452a7ebe37a5) sys/sys/_endian.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
A commit in branch releng/13.2 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d08ffbd70e7245f94af4b103f64c7ecab6da9d7f commit d08ffbd70e7245f94af4b103f64c7ecab6da9d7f Author: Warner Losh <imp@FreeBSD.org> AuthorDate: 2023-03-22 02:25:58 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2023-03-23 06:39:30 +0000 _endian.h: Include sys/cdefs.h for visibility macros BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN will be required by the forthcoming POSIX Issue 8. In addition, they are provided in the BSD compilation environments. However, depending on the order includes happend, sys/cdefs.h may or may not be included when endian.h is included. Include it here so we can safely test __BSD_VISIBLE. Add visibility when we're compiling in the future for issue 8, but since the date number for issue 8 hasn't been fixed, use strictly greater than the issue 7 date.of 200809. This had the side effect of sometimes (in the traditional BSD compliation environment) #if BYTE_ORDER == LITTLE_ENDIAN and #if BYTE_ORDER == BIG_ENDIAN both being true because none of these were defined. This fixes that. It also fixes including it after <stdio.h> but not before. PR: 269249 MFC After: 1d (build related) Reviewed by: kib, emaste Differential Revision: https://reviews.freebsd.org/D39176 Approved by: re@ (gjb) (cherry picked from commit ed52baf51bd142b5e32701842346452a7ebe37a5) (cherry picked from commit 4ccd5e64b76bbaa874c50755d17394a7ed195f93) sys/sys/_endian.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
(In reply to commit-hook from comment #39) FWIW, I've had to recompile i915kms.ko (kmod, drm) after rebuilding world on -STABLE, as it failed to load.
I'm happy to report that using poudriere with a jail for stable/13 as of e7d9a68e8 with Ivan's patch to the makefile backed out builds LibreSSL successfully. (Other things have broken (e.g. drm-kmod) but that's not the focus of this bug.) I'm thinking this bug is resolved, but I'll let others weigh in.
(In reply to Dave Hayes from comment #42) Objective is to build on stable/13, releng/13.2 etc. without Ivan's patch... Can you confirm that works as well?
(In reply to Bernard Spil from comment #43) I've have built libressl on -STABLE without Ivan's patch, I think that Dave as well ("patch backed out").
(In reply to Bernard Spil from comment #43) After system rebuild+reinstall with patch from Warner, libressl can be used with and without my patch.
Thanks all! Restored original behavior in LibreBSD as well, builds OK https://github.com/Sp1l/LibreBSD/commit/7bf8794d887e1e463c6f430384bb7f9d3f9bdab9