text:
[external test] Compile and link 1.1.1 command line app against the master headers and library

From point 2 of the Technical Items still to be done list:
Compile and link 1.1.1 command line app against the master headers and library.
Run 1.1.1 app test cases against the chimera.
Treat this as an external test using a special 1.1.1 branch.

These items are blocking building 1.1.1 apps with 3.0:
OCSP_REQ_CTX_new API has changed between 1.1.1 and 3.0 - Issue 13873
1.1.1 - prototype is OCSP_REQ_CTX *OCSP_REQ_CTX_new(BIO *io, int maxline);
3.0 - define has 8 args instead of two: #   define OCSP_REQ_CTX_new(wb, rb, m, ml, mrl, t, ect, ea)
OSSL_HTTP_REQ_CTX_new(wb, rb, m, ml, mrl, t, ect, ea)
OCSP_REQ_CTX_http API has changed between 1.1.1 and 3.0 - Issue 13873
1.1.1 - prototype is int OCSP_REQ_CTX_http(OCSP_REQ_CTX *rctx, const char *op, const char *path)
3.0 - define has four parameters: #   define OCSP_REQ_CTX_http(r, s, po, pa)
OSSL_HTTP_REQ_CTX_header(r, s, po, pa)
X509_http_nbio - docs in 3.0 are incorrect
1.1.1 - prototype is int X509_http_nbio(OCSP_REQ_CTX *rctx, X509 **pcert)
3.0 - define is # define X509_http_nbio(url) X509_load_http(url, NULL, NULL, 0)
X509_CRL_http_nbio not defined but is mentioned in doc/man3/X509_load_http.pod as a define having only one param instead of two
1.1.1 - prototype is int X509_CRL_http_nbio(OCSP_REQ_CTX *rctx, X509_CRL **pcrl)
3.0 - define is # define X509_CRL_http_nbio(url) X509_CRL_load_http(url, NULL,  NULL, 0)
TLS_CT_GOST12_SIGN is missing from 3.0
TLSEXT_TYPE_heartbeat is missing from 3.0

These items are blocking building 1.1.1 apps with 3.0:
OCSP_REQ_CTX_new API has changed between 1.1.1 and 3.0 - Issue 13873
1.1.1 - prototype is OCSP_REQ_CTX *OCSP_REQ_CTX_new(BIO *io, int maxline);
3.0 - define has 8 args instead of two: #   define OCSP_REQ_CTX_new(wb, rb, m, ml, mrl, t, ect, ea)
OSSL_HTTP_REQ_CTX_new(wb, rb, m, ml, mrl, t, ect, ea)
OCSP_REQ_CTX_http API has changed between 1.1.1 and 3.0 - Issue 13873
1.1.1 - prototype is int OCSP_REQ_CTX_http(OCSP_REQ_CTX *rctx, const char *op, const char *path)
3.0 - define has four parameters: #   define OCSP_REQ_CTX_http(r, s, po, pa)
OSSL_HTTP_REQ_CTX_header(r, s, po, pa)
X509_http_nbio - docs in 3.0 are incorrect
1.1.1 - prototype is int X509_http_nbio(OCSP_REQ_CTX *rctx, X509 **pcert)
3.0 - define is # define X509_http_nbio(url) X509_load_http(url, NULL, NULL, 0)
X509_CRL_http_nbio not defined but is mentioned in doc/man3/X509_load_http.pod as a define having only one param instead of two
1.1.1 - prototype is int X509_CRL_http_nbio(OCSP_REQ_CTX *rctx, X509_CRL **pcrl)
3.0 - define is # define X509_CRL_http_nbio(url) X509_CRL_load_http(url, NULL,  NULL, 0)
TLS_CT_GOST12_SIGN is missing from 3.0
TLSEXT_TYPE_heartbeat is missing from 3.0

TLS_CT_GOST12_SIGN is TLS_CT_GOST12_LEGACY_SIGN in 3.0.0

TLS_CT_GOST12_SIGN is TLS_CT_GOST12_LEGACY_SIGN in 3.0.0

X509_http_nbio - docs in 3.0 are incorrect
1.1.1 - prototype is int X509_http_nbio(OCSP_REQ_CTX *rctx, X509 **pcert)
3.0 - define is # define X509_http_nbio(url) X509_load_http(url, NULL, NULL, 0)

X509_CRL_http_nbio not defined but is mentioned in doc/man3/X509_load_http.pod as a define having only one param instead of two
1.1.1 - prototype is int X509_CRL_http_nbio(OCSP_REQ_CTX *rctx, X509_CRL **pcrl)
3.0 - define is # define X509_CRL_http_nbio(url) X509_CRL_load_http(url, NULL, NULL, 0)

Sorry for these - fix for them is in #13960.

X509_http_nbio - docs in 3.0 are incorrect
1.1.1 - prototype is int X509_http_nbio(OCSP_REQ_CTX *rctx, X509 **pcert)
3.0 - define is # define X509_http_nbio(url) X509_load_http(url, NULL, NULL, 0)

X509_CRL_http_nbio not defined but is mentioned in doc/man3/X509_load_http.pod as a define having only one param instead of two
1.1.1 - prototype is int X509_CRL_http_nbio(OCSP_REQ_CTX *rctx, X509_CRL **pcrl)
3.0 - define is # define X509_CRL_http_nbio(url) X509_CRL_load_http(url, NULL, NULL, 0)

Sorry for these - fix for them is in #13960.

Clone openssl 3.0 and build (I cloned to openssl)
Clone openssl 1.1.1 and build (I cloned to openssl_1_1_1)
cd to the openssl 1.1.1 top level directory
Create a folder named test_apps_3 or choose any name.
Copy the script below to the folder.
Run the script.
Copy test_apps_3/bin/openssl to apps/openssl
cd to top of the openssl 1.1.1 build directory.
You need to set OPENSSL_REGRESSION= path to the openssl 3 clone. You must not use a relative path.
You should be able to run OPENSSL_REGRESSION=path_to_openssl util/shlib_wrap.sh apps/openssl version
You can now run
OPENSSL_REGRESSION=../openssl make TESTS=25 test and other tests
You may run the script with --clean to clean the test folder you created
You may run the script with --preprocess to only preprocess the source files.  .pp files will be in the bin folder.
Use this script to build apps/openssl in an openssl 1.1.1 clone:

USEABORT=1
abort() {
	echo $1
	[ $USEABORT = "1" ] &&  exit 1
}

BUILD_MODE="-c"
BUILD_OUTPUT_TYPE="o"
DO_CLEAN=0
DO_INSTALL=0

OSSL=/usr/local/openssl3
SRCAPPDIR=../../openssl_1_1_1/apps
TESTDIR=`pwd`
BINDIR="$TESTDIR"/bin
APPDIR="$TESTDIR"/apps
SKIPFILES=""

OPT_INCLUDE="-I./include -I$APPDIR -I$OSSL/include -I$OSSL/include/openssl -I$APPDIR/include"
OPT_DEFINES="-DOPENSSL_NO_HEARTBEATS -DOPENSSL_NO_OCSP -DOPENSSL_UNISTD=<stdlib.h> -DOPENSSL_BUILDING_OPENSSL -D_REENTRANT -DLIST_SEPARATOR_CHAR=';'"

OBJ=""
LIBSRC="app_rand.c apps.c bf_prefix.c opt.c s_cb.c s_socket.c"
#
# left out ocsp.c
APPSRC="asn1pars.c ca.c ciphers.c cms.c crl.c crl2p7.c dgst.c dhparam.c dsa.c dsaparam.c ec.c ecparam.c enc.c engine.c errstr.c gendsa.c genpkey.c genrsa.c nseq.c openssl.c passwd.c pkcs12.c pkcs7.c pkcs8.c pkey.c pkeyparam.c pkeyutl.c prime.c rand.c rehash.c req.c rsa.c rsautl.c s_client.c s_server.c s_time.c sess_id.c smime.c speed.c spkac.c srp.c storeutl.c ts.c verify.c version.c x509.c"

dobuild() {
	if [ ! -f "$BINDIR"/$1.$BUILD_OUTPUT_TYPE ]; then
		DOBUILD=1
	elif [ "$BINDIR"/$1.$BUILD_OUTPUT_TYPE -ot "$APPDIR"/$1.c ]; then
		DOBUILD=1
	else
		DOBUILD=0
	fi
}

# start here

for i
do
 case "$i" in
 	--clean) DO_CLEAN=1;;
 	--install) DO_INSTALL=1;;
	--preprocess) BUILD_MODE="-E"; BUILD_OUTPUT_TYPE="pp";;
	--noabort) USEABORT=0;;
	--skip)
		SKIPFILES="$SKIPFILES $2"
 esac
 shift
done

if [ $DO_CLEAN = '1' ]; then
	rm -rf "$BINDIR"
	rm -rf "$APPDIR"
fi
if [ ! -d "$BINDIR" ]; then
	mkdir -p "$BINDIR"
fi
if [ ! -d "$APPDIR" ]; then
	mkdir -p "$APPDIR"
	(cd "$SRCAPPDIR"; tar cf - .) | (cd "$APPDIR"; tar xf -)
fi

#[ -f "$APPDIR"/progs.pl ] && (cd ..; perl "$APPDIR"/progs.pl $APPSRC >"$APPDIR"/progs.h ) || abort "Can't make progs.h"

for src in $APPSRC
do
	echo $SKIPFILES | grep --quiet "$src" || {
		echo $src
		FN=$(basename $src .c)
		dobuild $FN
		echo $DOBUILD, $FN
		if [ $DOBUILD = 1 ] ; then
			set -x
			cc  $OPT_INCLUDE -arch x86_64 $BUILD_MODE -Wall -g -O0 $OPT_DEFINES -o "$BINDIR"/$FN.$BUILD_OUTPUT_TYPE "$APPDIR"/$FN.c || abort "compile failed for $FN.c" }
			unset x
		fi
		OBJ="$OBJ $BINDIR/$FN.$BUILD_OUTPUT_TYPE"
	}
done

LIBOBJ=""
for src in $LIBSRC
do
	echo $SKIPFILES | grep --quiet "$src" || {
		echo $src
		FN=$(basename $src .c)
		if [ "$BINDIR"/$FN.$BUILD_OUTPUT_TYPE -ot "$APPDIR"/$FN.c ]; then
			set -x
			cc  $OPT_INCLUDE -arch x86_64 $BUILD_MODE -Wall -g -O0 $OPT_DEFINES -o "$BINDIR"/$FN.$BUILD_OUTPUT_TYPE "$APPDIR"/$FN.c || abort "compile failed for $FN.c"
			unset x
		fi
		LIBOBJ="$LIBOBJ $BINDIR/$FN.$BUILD_OUTPUT_TYPE"
	}
done
if [ "x$LIBOBJ" != x ]; then
	ar r bin/libapps.a $LIBOBJ
fi

# build stubs
if [ -d "$TESTDIR"/stubs ]; then
	for src in "$TESTDIR"/stubs/*.c
	do
		echo $src
		FN=$(basename $src .c)
		set -x
		cc  $OPT_INCLUDE -arch x86_64 $BUILD_MODE -Wall -g -O0 $OPT_DEFINES -o "$BINDIR"/$FN.$BUILD_OUTPUT_TYPE "$APPDIR"/$FN.c || abort "compile failed for $FN.c"
		unset x
		OBJ="$OBJ $BINDIR/$FN.$BUILD_OUTPUT_TYPE"
	done
fi

if [ $BUILD_OUTPUT_TYPE = "o" ]; then
	cc -o "$BINDIR"/openssl $OBJ "$BINDIR"/libapps.a "$OSSL"/lib/libssl.3.dylib "$OSSL"/lib/libcrypto.3.dylib
	if [ x$DO_INSTALL = x1 ]; then
		rm "$SRCAPPDIR"/openssl
		cp "$BINDIR"/openssl "$SRCAPPDIR"/openssl
	fi
fi

Clone openssl 3.0 and build (I cloned to openssl)
Clone openssl 1.1.1 and build (I cloned to openssl_1_1_1)
cd to the openssl 1.1.1 top level directory
Create a folder named test_apps_3 or choose any name.
Copy the script below to the folder.
Run the script.
Copy test_apps_3/bin/openssl to apps/openssl
cd to top of the openssl 1.1.1 build directory.
You need to set OPENSSL_REGRESSION= path to the openssl 3 clone. You must not use a relative path.
You should be able to run OPENSSL_REGRESSION=path_to_openssl util/shlib_wrap.sh apps/openssl version
You can now run
OPENSSL_REGRESSION=../openssl make TESTS=25 test and other tests
You may run the script with --clean to clean the test folder you created
You may run the script with --preprocess to only preprocess the source files.  .pp files will be in the bin folder.
Use this script to build apps/openssl in an openssl 1.1.1 clone:

USEABORT=1
abort() {
	echo $1
	[ $USEABORT = "1" ] &&  exit 1
}

BUILD_MODE="-c"
BUILD_OUTPUT_TYPE="o"
DO_CLEAN=0
DO_INSTALL=0

OSSL=/usr/local/openssl3
SRCAPPDIR=../../openssl_1_1_1/apps
TESTDIR=`pwd`
BINDIR="$TESTDIR"/bin
APPDIR="$TESTDIR"/apps
SKIPFILES=""

OPT_INCLUDE="-I./include -I$APPDIR -I$OSSL/include -I$OSSL/include/openssl -I$APPDIR/include"
OPT_DEFINES="-DOPENSSL_NO_HEARTBEATS -DOPENSSL_NO_OCSP -DOPENSSL_UNISTD=<stdlib.h> -DOPENSSL_BUILDING_OPENSSL -D_REENTRANT -DLIST_SEPARATOR_CHAR=';'"

OBJ=""
LIBSRC="app_rand.c apps.c bf_prefix.c opt.c s_cb.c s_socket.c"
#
# left out ocsp.c
APPSRC="asn1pars.c ca.c ciphers.c cms.c crl.c crl2p7.c dgst.c dhparam.c dsa.c dsaparam.c ec.c ecparam.c enc.c engine.c errstr.c gendsa.c genpkey.c genrsa.c nseq.c openssl.c passwd.c pkcs12.c pkcs7.c pkcs8.c pkey.c pkeyparam.c pkeyutl.c prime.c rand.c rehash.c req.c rsa.c rsautl.c s_client.c s_server.c s_time.c sess_id.c smime.c speed.c spkac.c srp.c storeutl.c ts.c verify.c version.c x509.c"

dobuild() {
	if [ ! -f "$BINDIR"/$1.$BUILD_OUTPUT_TYPE ]; then
		DOBUILD=1
	elif [ "$BINDIR"/$1.$BUILD_OUTPUT_TYPE -ot "$APPDIR"/$1.c ]; then
		DOBUILD=1
	else
		DOBUILD=0
	fi
}

# start here

for i
do
 case "$i" in
 	--clean) DO_CLEAN=1;;
 	--install) DO_INSTALL=1;;
	--preprocess) BUILD_MODE="-E"; BUILD_OUTPUT_TYPE="pp";;
	--noabort) USEABORT=0;;
	--skip)
		SKIPFILES="$SKIPFILES $2"
 esac
 shift
done

if [ $DO_CLEAN = '1' ]; then
	rm -rf "$BINDIR"
	rm -rf "$APPDIR"
fi
if [ ! -d "$BINDIR" ]; then
	mkdir -p "$BINDIR"
fi
if [ ! -d "$APPDIR" ]; then
	mkdir -p "$APPDIR"
	(cd "$SRCAPPDIR"; tar cf - .) | (cd "$APPDIR"; tar xf -)
fi

#[ -f "$APPDIR"/progs.pl ] && (cd ..; perl "$APPDIR"/progs.pl $APPSRC >"$APPDIR"/progs.h ) || abort "Can't make progs.h"

for src in $APPSRC
do
	echo $SKIPFILES | grep --quiet "$src" || {
		echo $src
		FN=$(basename $src .c)
		dobuild $FN
		echo $DOBUILD, $FN
		if [ $DOBUILD = 1 ] ; then
			set -x
			cc  $OPT_INCLUDE -arch x86_64 $BUILD_MODE -Wall -g -O0 $OPT_DEFINES -o "$BINDIR"/$FN.$BUILD_OUTPUT_TYPE "$APPDIR"/$FN.c || abort "compile failed for $FN.c" }
			unset x
		fi
		OBJ="$OBJ $BINDIR/$FN.$BUILD_OUTPUT_TYPE"
	}
done

LIBOBJ=""
for src in $LIBSRC
do
	echo $SKIPFILES | grep --quiet "$src" || {
		echo $src
		FN=$(basename $src .c)
		if [ "$BINDIR"/$FN.$BUILD_OUTPUT_TYPE -ot "$APPDIR"/$FN.c ]; then
			set -x
			cc  $OPT_INCLUDE -arch x86_64 $BUILD_MODE -Wall -g -O0 $OPT_DEFINES -o "$BINDIR"/$FN.$BUILD_OUTPUT_TYPE "$APPDIR"/$FN.c || abort "compile failed for $FN.c"
			unset x
		fi
		LIBOBJ="$LIBOBJ $BINDIR/$FN.$BUILD_OUTPUT_TYPE"
	}
done
if [ "x$LIBOBJ" != x ]; then
	ar r bin/libapps.a $LIBOBJ
fi

# build stubs
if [ -d "$TESTDIR"/stubs ]; then
	for src in "$TESTDIR"/stubs/*.c
	do
		echo $src
		FN=$(basename $src .c)
		set -x
		cc  $OPT_INCLUDE -arch x86_64 $BUILD_MODE -Wall -g -O0 $OPT_DEFINES -o "$BINDIR"/$FN.$BUILD_OUTPUT_TYPE "$APPDIR"/$FN.c || abort "compile failed for $FN.c"
		unset x
		OBJ="$OBJ $BINDIR/$FN.$BUILD_OUTPUT_TYPE"
	done
fi

if [ $BUILD_OUTPUT_TYPE = "o" ]; then
	cc -o "$BINDIR"/openssl $OBJ "$BINDIR"/libapps.a "$OSSL"/lib/libssl.3.dylib "$OSSL"/lib/libcrypto.3.dylib
	if [ x$DO_INSTALL = x1 ]; then
		rm "$SRCAPPDIR"/openssl
		cp "$BINDIR"/openssl "$SRCAPPDIR"/openssl
	fi
fi

@nelsonopenssl, I detect traces of MacOS/X :wink:

@nelsonopenssl, I detect traces of MacOS/X :wink:

Just a trace? I did do the work on Ubuntu. My shell coding is probably old fashioned though
Sent from my iPhone

On Jan 27, 2021, at 3:24 PM, Richard Levitte notifications@github.com wrote:

@nelsonopenssl, I detect traces of MacOS/X 😉
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Just a trace? I did do the work on Ubuntu. My shell coding is probably old fashioned though
Sent from my iPhone

On Jan 27, 2021, at 3:24 PM, Richard Levitte notifications@github.com wrote:

@nelsonopenssl, I detect traces of MacOS/X 😉
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Well, only MacOS/X has shared libraries called whatever.dylib :wink:

Well, only MacOS/X has shared libraries called whatever.dylib :wink:

X509_http_nbio - docs in 3.0 are incorrect
1.1.1 - prototype is int X509_http_nbio(OCSP_REQ_CTX *rctx, X509 **pcert)
3.0 - define is # define X509_http_nbio(url) X509_load_http(url, NULL, NULL, 0)

X509_CRL_http_nbio not defined but is mentioned in doc/man3/X509_load_http.pod as a define having only one param instead of two
1.1.1 - prototype is int X509_CRL_http_nbio(OCSP_REQ_CTX *rctx, X509_CRL **pcrl)
3.0 - define is # define X509_CRL_http_nbio(url) X509_CRL_load_http(url, NULL, NULL, 0)

Sorry for these - fix for them is in #13960.

That fix is merged now.

I have a cmake based 1.1.1-derived branch that does this, and which includes github action tests.
https://github.com/levitte/openssl/tree/EXPERIMENTAL-build-against-3.0

Closed based on the availability of @levitte's branch
Issue #14275 can be used to track fixes to the tests

authors: DDvO levitte mattcaswell nelsonopenssl romen


text:
What year is now?

https://www.openssl.org/
Copyright © 1999-2018, OpenSSL Software Foundation.
Really? 2018?
:-)

Good. Closing. MC & HNY++

source: gharchive/issue

repo: openssl/openssl

license_type: permissive

license_source: github-api


text:
Add an EVP demo for key encoding using RSA

Do both encode and decode.
It should be the current best practice (fetch), have proper error handling and resource allocation/deallocation and be in the style of a known answer test.

I'd like to take a crack at this one, if you'd like to assign it to me!

It's all yours :)

There is likely going to be a new easier API for key generation soon: #14695  The exact form isn't known, however this will only have a minor or no impact on this example.

Yeah, the demo should demonstrate the "normal, full-featured way" not the quick call (that call should not need a demo).

Before I countinue development, I want to make sure I'm on the right track (I'm fairly new to OpenSSL). Could you point out the "core" function(s) that need to be demonstrated? Just want to make sure I get exactly what you want :)

Please look at the examples in https://github.com/openssl/openssl/blob/master/doc/man3/OSSL_DECODER_from_bio.pod and https://github.com/openssl/openssl/blob/master/doc/man3/OSSL_ENCODER_to_bio.pod.

Thanks! I'll change what I had coded 😅

perhaps a simple test is to build against a version of openssl that is configured with no-deprecated  right, @t8m ?

Yeah, sure, the demo should build fine against no-deprecated build of openssl.

authors: CuckooEXE paulidale richsalz t8m


text:
Why is Ed25519 not implemented using radix-$2^{64}$ or radix-$2^{51}$ finite field layer?

crypto/ec/curve25519.c is the source code of X25519 and Ed25519 implementation. The macro X25519_ASM and the specific software/hardware environment are used to decide if X25519 uses radix-$2^{64}$ (fe64 type), radix-$2^{51}$ (fe51 type), or radix-$2^{25.5}$ (fe type) finite field implementation.
But Ed25519's finite field layer is always implemented using only radix-$2^{25.5}$ (fe type) version.
I'm planning to develop an Ed25519 implementation using radix-$2^{64}$ or radix-$2^{51}$ finite field layer. Therefore, I'd like to know:

Why is Ed25519 not implemented using radix-$2^{64}$ or radix-$2^{51}$ finite field layer?
Are there other potential considerations?

Did you find this code: https://github.com/openssl/openssl/blob/master/crypto/ec/asm/x25519-x86_64.pl ?
However, any faster implementation will always be considered.

@paulidale That's X25519, not Ed25519. I believe OpenSSL's Ed25519 is indeed always radix 25.5, which leaves a ton of perf on the table on 64-bit platforms.

I'm planning to develop a faster Ed25519 implementation with radix-64 or radix-51. I found that the existing X25519 implementation to be sub-optimal from a code size perspective. The basic pattern of crypto/ec/curve25519.c is as follows.
#if defined(X25519_ASM) && (defined(__x86_64) || defined(__x86_64__) || \
                            defined(_M_AMD64) || defined(_M_X64))
# define BASE_2_64_IMPLEMENTED

// radix-64 finite filed implementation, i.e., fe64 type.

#endif

#if defined(X25519_ASM) \
    || ( (defined(__SIZEOF_INT128__) && __SIZEOF_INT128__ == 16) \
         && !defined(__sparc__) \
         && (!defined(__SIZEOF_LONG__) || (__SIZEOF_LONG__ == 8)) \
         && !(defined(__ANDROID__) && !defined(__clang__)) )
# define BASE_2_51_IMPLEMENTED

// radix-51 finite field implementation, i.e., fe51 type.

#endif

// radix-25.5 finite field implementation, i.e., fe type. This implementation is not wrapped by any conditional macros.

In a specific environment, it is possible for the fe64 type and fe51 type to exist at the same time.
The point that can be improved by refactoring the code is that if the fe64 type exists then fe51 type can not exist, which can reduce the code size.
After the Ed25519 is implemented using fe64 type or fe51 type. The ideal pattern of curve25519.c should be something like:
#if defined(X25519_ASM) && (defined(__x86_64) || defined(__x86_64__) || \
                            defined(_M_AMD64) || defined(_M_X64))
# define BASE_2_64_IMPLEMENTED

// radix-64 finite field implementation and corresponding X25519/Ed25519 implementation.

#elif defined(X25519_ASM) \
    || ( defined(INT128_MAX) \
         && !defined(__sparc__) \
         && (!defined(__SIZEOF_LONG__) || (__SIZEOF_LONG__ == 8)) \
         && !(defined(__ANDROID__) && !defined(__clang__)) )
# define BASE_2_51_IMPLEMENTED

// radix-51 finite field implementation and corresponding X25519/Ed25519 implementation.

#else

// radix-25.5 finite field implementation and corresponding X25519/Ed25519 implementation.

#endif

In this way, only one of fe64, fe51, and fe can exist at the same time.
Do you have any opinions?

authors: Ji-Peng davidben paulidale


text:
Bug in Bio_Printf

Hello
If i call
out = BIO_new_file("test.txt", "w");
BIO_printf(out, "TEST%s","zz");
There is no problem, in the result file, there is : TESTzz
But if I call
out = BIO_new_file("test.txt", "w");
BIO_printf(out, "TEST%s","\r\n");
In the result file, I got : TESTCRCRLF instead of TESTCRLF

Can you check, I don't undertstand why there is this problem
I haven't this problem with previous version of OpenSSL (0.9 or 1.0 or 1.1)
I do the test with OpenSSL 3.0.4
Regards
Gilles

What platform are you seeing this on? My assumption is that printing the LF is being converted to CRLF automatically somewhere (perhaps because the file is open in "w" mode not "wb"). Not sure why the behaviour would have changed between OpenSSL versions though.

Hello
I am working on Windows
You are rigth, if I use "wb", I haven't the problem anymore
The default mode has certainly change in openssl
Regards
Gilles

Ok...so this looks like "not a bug" to me. BIO_printf is behaving as it should, and the additional CRLF is due to the file mode being used. Why this didn't happen in older versions of OpenSSL remains a bit of a mystery which I haven't investigated - but the current behaviour looks to me like I would expect.


text:
Cross-compile to Windows (64-bit) is failing given that statically built OpenSSL can't be found

I am trying to cross-compile a C++ project to Windows using dockcross (more specifically, https://github.com/dockcross/dockcross/tree/master/windows-static-x64) in Ubuntu 20.04. This container image in specific uses MXE together with the x86_64-w64-mingw32 compiler.
OpenSSL is also built (statically) through this container using the following configuration and build command: (note this is being called from CMake, and so the usage of CMake variables)
# Config
perl <SOURCE_DIR>/Configure mingw64 no-shared no-tests --prefix=${CMAKE_INSTALL_PREFIX}
# build
RC=/usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-windres
AR=/usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-ar
RANLIB=/usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-ranlib
CROSS_COMPILE=x86_64-w64-mingw32.static-
make -e RC=${RC} AR=${AR} RANLIB=${RANLIB} CROSS_COMPILE=${CROSS_COMPILE}

The command above runs properly and libcrypto.so and libssl.so are both installed in ${CMAKE_INSTALL_PREFIX}/lib, besides the headers on the ${CMAKE_INSTALL_PREFIX}/include folder. Here's the install tree structure:
.
├── bin
│   ├── ...
│   └── openssl.exe
├── include
│   ├── ...
│   └── openssl
│      ├── ...
│      └── ssl.h
├── lib
│   ├── ...
│   ├── libcrypto.a
│   └── libssl.a
...

But, for some reason, on the C++ project, and when calling find_package(OpenSSL REQUIRED), it fails to find OPENSSL_CRYPTO_LIBRARY as it can be seen above. Note that OPENSSL_INCLUDE_DIR had to also be passed as a CMAKE_ARG to the project because FindOpenSSL() is was also not able to find openssl/ssl.h, although it is installed in ${CMAKE_INSTALL_PREFIX}/include. OpenSSL is marked as a dependency of libdatachannel while building through CMake, so I don't necessarily understand why this fails. One thing to note is that MXE sets MSYS to 1, and also since we are using mingw32 to cross-compile,WIN32 and MINGW are also set to 1. If I try to manually set MINGW and WIN32 to 0, then find_package(OpenSSL) succeeds and the build process continues, until the linker fails because the architecture is of course wrong. Setting the OPENSSL_ROOT_DIR also doesn't help.
Is this potentially a problem with the OpenSSL build or even with the default FindOpenSSL.cmake module? Or is this something that can be addressed on the C++ project CMakeLists.txt? Any help with this would be appreciated.
Thanks in advance!

For whatever it can help with, here's the /usr/src/mxe/usr/x86_64-w64-mingw32.static/share/cmake/mxe-conf.cmake MXE configuration:
# This file is part of MXE. See LICENSE.md for licensing information.

# https://cmake.org/cmake/help/latest

# Can't set `cmake_minimum_required` or `cmake_policy` in toolchain
# since toolchain is read before CMakeLists.txt
# See `target-cmake.in` for CMAKE_POLICY_DEFAULT_CMPNNNN

# Check if we are using mxe supplied version
#   - toolchain is included multiple times so set a guard in
#     environment to suppress duplicate messages
if(NOT ${CMAKE_COMMAND} STREQUAL /usr/src/mxe/usr/x86_64-pc-linux-gnu/bin/cmake AND NOT DEFINED ENV{_MXE_CMAKE_TOOLCHAIN_INCLUDED})
    message(WARNING "
** Warning: direct use of toolchain file is deprecated
** Please use prefixed wrapper script instead:
     x86_64-w64-mingw32.static-cmake [options] <path-to-source>
       - uses mxe supplied cmake version 3.20.1
       - loads toolchain
       - loads common run results
       - sets various policy defaults
    ")
    set(ENV{_MXE_CMAKE_TOOLCHAIN_INCLUDED} TRUE)
endif()

# Use CACHE variables to allow user setting with `-D`
# Use CACHE FORCE in rare cases of misconfigured CMakeLists.txt
#   - e.g include(FindPkgConfig)
#     https://github.com/mxe/mxe/issues/1023
#   - projects may still set these in which case FORCE doesn't have
#     any advantage, just causes inconvenience
#     https://github.com/mxe/mxe/pull/1621#discussion_r106937505
# Use normal variables expected to be set by toolchain/system
#   - projects should test for these values and not try to override

## General configuration
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR x86_64 CACHE STRING "System Processor")
set(MSYS 1)
set(CMAKE_EXPORT_NO_PACKAGE_REGISTRY ON)
# Workaround for https://www.cmake.org/Bug/view.php?id=14075
set(CMAKE_CROSS_COMPILING ON)

## Library config
set(BUILD_SHARED_LIBS OFF CACHE BOOL "BUILD_SHARED_LIBS")
set(BUILD_STATIC_LIBS ON CACHE BOOL "BUILD_STATIC_LIBS")
set(BUILD_SHARED OFF CACHE BOOL "BUILD_SHARED")
set(BUILD_STATIC ON CACHE BOOL "BUILD_STATIC")
set(LIBTYPE STATIC)

## Paths etc.
# These MODEs shouldn't be changed by users, we only want headers/libs
# from cross-build and "never" want binaries. We do, however, want
# `*-config` scripts but there's no way to instruct cmake to do that.
#
# The best solution may be to whitelist utilities
#   https://github.com/mxe/mxe/issues/1667
# and symlink them to an additional root path, changing PROGRAM to ONLY

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

# Allow user to specify list of locations to search
set(CMAKE_FIND_ROOT_PATH /usr/src/mxe/usr/x86_64-w64-mingw32.static CACHE PATH "List of root paths to search on the filesystem")
set(CMAKE_PREFIX_PATH /usr/src/mxe/usr/x86_64-w64-mingw32.static CACHE PATH "List of directories specifying installation prefixes to be searched")
set(CMAKE_INSTALL_PREFIX /usr/src/mxe/usr/x86_64-w64-mingw32.static CACHE PATH "Installation Prefix")
# For custom mxe FindPackage scripts
set(CMAKE_MODULE_PATH "/usr/src/mxe/usr/share/cmake/modules" ${CMAKE_MODULE_PATH})

# projects (mis)use `-isystem` to silence warnings from 3rd-party
# source (among other things). gcc6 introduces changes to search
# order which breaks this usage.
#   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
#   https://gitlab.kitware.com/cmake/cmake/issues/16291
#   https://gitlab.kitware.com/cmake/cmake/issues/16919
set(CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES /usr/src/mxe/usr/x86_64-w64-mingw32.static/include)
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES /usr/src/mxe/usr/x86_64-w64-mingw32.static/include)

## Programs
set(CMAKE_C_COMPILER /usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-gcc)
set(CMAKE_CXX_COMPILER /usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-g++)
set(CMAKE_Fortran_COMPILER /usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-gfortran)
set(CMAKE_RC_COMPILER /usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-windres)
# CMAKE_RC_COMPILE_OBJECT is defined in:
#     <cmake root>/share/cmake-X.Y/Modules/Platform/Windows-windres.cmake
set(CPACK_NSIS_EXECUTABLE x86_64-w64-mingw32.static-makensis)

## Individual package configuration
file(GLOB mxe_cmake_files
    "/usr/src/mxe/usr/x86_64-w64-mingw32.static/share/cmake/mxe-conf.d/*.cmake"
)
foreach(mxe_cmake_file ${mxe_cmake_files})
    include(${mxe_cmake_file})
endforeach()
set(CMAKE_CROSSCOMPILING_EMULATOR "/usr/bin/wine")


text:
why the key iv and ctx

Please do NOT use issues to ask questions about OpenSSL.
Instead, please use the Q&A category in Discussions
to ask your question.

Please use Q&A category in Discussions to post a question.


text:
SNI issue with Subject Alternative Names certificate support.

I added SNI support to our OpenSSL v3.4-based servers and our testers are finding issues with certificates with www.domains.   We are not sure what could be the issue, but after trying certs w/o www.domain as the Subject Alternative Name, an exploratory hack to find a solution was to add a "www." + domain to our SNI-callback logic to make sure an incoming "www.domain" SNI can be mapped to an SNI defined "domain" context.
GPT4o indicates this is a known issue.   Is this true or is the hack is necessary?

I work like to point out, the solution I believe I found to work but I hate hacks, is adding "www." to the certificate domain cert.  To make it less a hack, what I am working on is exacting the Subject Alternative Names (SANs) of a cert intended to be an SNI cert.  and apply it a SNI domain::context map only for "www." or wildcard "*.".   Of cause for a single SAN cert domain w/o multiple and wildcard domains, this is not a problem with basic OpenSSL server/client logic.  Only with the SNI logic used for Virtual Domains.  Which worked fine until the traditional CNAME "www." alias included in the same SAN logic. fails in SNI callback logic.
The question I have, I am wasting my time and there is already a SNI-related solution with proper API calls and/or callbacks?
Thanks


text:
Cache Digest constants

EVP_CIPHER already caches certain constants so that we don't have to query the provider every time. We do the same thing with EVP_MD constants. Without this we can get performance issues, e.g. running "speed" with small blocks of data to digest can spend a long time in EVP_MD_size(), which should be quick.
Partialy fixes #13578
I've also refactored the EVP_CIPHER constant caching to move it into evp_cipher_from_dispatch, i.e. to where the EVP_CIPHER actually gets constructed rather than where it is fetched in EVP_CIPHER_fetch. The problem with the latter is that we construct a cipher once, but we may fetch it many times. We shouldn't have to cache the constants every time we fetch.

I've run some tests to see the effect on performance of this change. I ran both the "before" and "after" tests with #13721 applied. I'm seeing quite a lot of variability in the results from one run to the next, so my confidence the precise numbers is quite low. To try and reduce variability as much as possible I "warmed up" my machine before both the "before" and "after" tests by repeating the same speed command 5 times and discarding the results. I then ran the command again 5 times and recorded the results.
I compiled with just config --strict-warnings, and ran this speed command:
openssl speed -evp sha256 -bytes 16

The "before" output was:
sha256           38566.15k
sha256           36042.71k
sha256           42937.12k
sha256           42312.67k
sha256           44117.60k

Which gives an average of 40795.25k
The "after" output was:
sha256           46979.81k
sha256           49308.40k
sha256           48095.66k
sha256           46935.39k
sha256           46201.71k

Which gives an average of 47504.19k.
This represents a speed-up of approximately 16% (if you believe the numbers).

Deprecated functions like EVP_MD_meth_set_result_size() set md->md_size, which is now the cached value. Either they should actually change something in the provider, return an error, or be removed. This PR doesn't actually introduce the problem, but now seems to use existing variables that were not initialized before, but that we did read and then don't do anything with.
The functions are currently documented to just return 1.

I think it's a separate issue and these functions should not be applicable to provided digests.

I think it's a separate issue and these functions should not be applicable to provided digests.

Exactly. Those functions are deprecated for a reason. They are intended for use when you are setting up your own custom EVP_MD which you have created yourself.

Either they should actually change something in the provider, return an error, or be removed.

I disagree. They are deprecated and therefore their usage is strongly discouraged. Existing uses will not be broken. I don't see a problem here.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged. Thanks!

source: gharchive/pull-request

authors: beldmit kroeckx mattcaswell openssl-machine


text:
64bit ssl op

The last commit is a code readability issue.  It duplicates the cleanup in #15184 so either this or that (heh) could be merged first without causing major headaches.  Expressing things in terms of bits is much more clear than comparing large hex numbers, especially 64-bit hex numbers :)
The OTC wanted this for beta as it's an API change.

I'm in favor of 64-bit options field; I had tried it a while ago when one of my features would've pushed the limit.

fixup commit pushed.

Surely someone on the git project sees things like "fixup! fixup! fixup! fixup! fixup! Slightly reformat ssl.h.in " and wants to make "spam" and alias for "fixup" :)

Surely someone on the git project sees things like "fixup! fixup! fixup! fixup! fixup! Slightly reformat ssl.h.in " and wants to make "spam" and alias for "fixup" :)

People need to learn how to use --fixup or git should recognize this stuff... Sigh...

The --autosquash handles the multiple-fixup commits just fine so it is just a cosmetic problem.

it is just a cosmetic problem.

I know.  I was making a joke, a reference to the famous (https://www.dailymotion.com/video/x9fly1 etc)

You have removed all the older OP which were defined as zero and were being left for compatibility reasons.
That wasn't meant to happen in this PR.

This pull request is ready to merge

Pushed! Thanks.

authors: mattcaswell openssl-machine richsalz t-j-h t8m tmshort


text:
Add RAND_UNIMPLEMENTED error code

See old GitHub PR #38.
Trivial change, completely re-implemented by me.

make update to update the list of errors in .c and .h files?

Forgot to push those files, thanks.  updated commit pushed.

thanks.

authors: richsalz tmshort


text:
Move randomness to allocated buffer

Don't keep it in the DRBG object, just allocate/free as needed.

Thanks!


text:
Don't negotiate TLSv1.3 if our EC cert isn't TLSv1.3 capable

TLSv1.3 is more restrictive about the curve used. There must be a matching sig alg defined for that curve. Therefore if we are using some other curve in our certificate then we should not negotiate TLSv1.3.
Additionally we should not apply signature algorithm curve checks in TLSv1.2. RFC8446 says this:
    ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature
    pairs.  However, the old semantics did not constrain the signing
    curve.  If TLS 1.2 is negotiated, implementations MUST be prepared
    to accept a signature that uses any curve that they advertised in
    the "supported_groups" extension.

Fixes #7435

Please add tests

I updated this to add a test and rebased it.
I also dropped the commit about sig alg curve checks in TLSv1.2. This turned out to be unnecessary (and wrong).

I wonder if we should also add some test that fails.

I wonder if we should also add some test that fails.

Can you suggest what such a test might look like?

Ping @kroeckx

Ping @kroeckx

I wonder if we should also add some test that fails.

Can you suggest what such a test might look like?

Could that be a cert with an invalid curve for TLSv1.3, perhaps?  I'm not savvy enough to know if that should cause an error or a downgrade to TLSv1.2, but yeah, something like that.  The way I understand this PR, you've only added a test for a cert that successfully enables TLSv1.3, is that correct?

Could that be a cert with an invalid curve for TLSv1.3, perhaps? I'm not savvy enough to know if that should cause an error or a downgrade to TLSv1.2, but yeah, something like that. The way I understand this PR, you've only added a test for a cert that successfully enables TLSv1.3, is that correct?

The tests do add a curve which is invalid for TLSv1.3. Prior to the fix in this PR libssl would have negotiated TLSv1.3 anyway and then subsequently failed. After the fix in this PR libssl realises that its cert is not TLSv1.3 compatibile and successfully negotiates TLSv1.2 instead.

@vdukhovni I added a commit to implement your suggestion for the key generation in the script. I also added a commit to add a test which checks for a failed connection if the minimum protocol is TLSv1.3 and brainpool is used as per @kroeckx suggestion.
Can you reconfirm?
@kroeckx are you ok with this now?

Yes, it's fine for me.

authors: kroeckx levitte mattcaswell


text:
Fix: using connect host name for SNI with proxy CONNECT in s_client

Before, the proxy host name was used for SNI.
Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

Can you please rebase this if it is still relevant?

This was not rebased. Closing.


text:
WIP: Use 'OPENSSL_' as common include guard prefix

The current policy mandates that all public symbols should have an OpenSSL-specific prefix in order not to pollute the global namespace of the C compiler and preprocessor.
In order to conform to the policy, all include guard prefixes are changed from 'HEADER_' to 'OPENSSL_'.
Note: This pull request replaces #8890 with consent from @DDvO (see https://github.com/openssl/openssl/pull/8890#issuecomment-496182190).
commits
The bulk changes are in commit 5e450009bac728c8d4ed1c4253182b91ec9f45e4:
commit 5e450009bac728c8d4ed1c4253182b91ec9f45e4
Author: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Date:   Sun Jun 30 14:52:46 2019 +0200

    Use 'OPENSSL_' as common include guard prefix

    The current policy mandates that all public symbols should have an
    OpenSSL-specific prefix in order not to pollute the global namespace of
    the C compiler and preprocessor.

    In order to conform to the policy, all include guard prefixes are changed
    from 'HEADER_' to 'OPENSSL_'.

The bulk changes were automated using the following bash script, which is included in 63b9ca52d19c582342996d104e15835ff38fc0b5 for reference only. It will be discarded before merging.
commit 63b9ca52d19c582342996d104e15835ff38fc0b5
Author: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Date:   Sun Jun 30 14:19:16 2019 +0200

    Add `update-openssl-include-guards` script [to be discarded]

Finally, the change to util/mkerr.pl is based on a patch from @DDvO  which was triggered by a change request from @bernd-edlinger (see https://github.com/openssl/openssl/pull/8669#discussion_r280882523).
commit 755b50599854734f4c70c11fe7899d875acf6db2
Author: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Date:   Sun Jun 30 15:06:18 2019 +0200

    util/mkerr.pl: use 'OPENSSL_' as include guard prefix of *err.h files

    Also add a comment at the corresponding `#endif`.

Initially I thought this should be backported to 1.1.1, but meanwhile I believe that it is too big a change for doing it. Although the include guards are not part of the API in the strict sense, application developers might depend on their names to check whether certain OpenSSL headers have already been included.
What's your opinion about that, @openssl/omc?

A CHANGES entry will certainly be necessary. I will wait a little and see in which direction the discussion goes, before adding it.

Side note: the policy talks about new features (i.e new APIs)

I'm all for this change, including a back port to 1.1.1. Our current guards are ridiculously generic...

Side note: the policy talks about new features (i.e new APIs)

I assume you are referring to the commit messag. Would you find the following text more suitable?
Use 'OPENSSL_' as common include guard prefix

The current policy mandates that new public API symbols should
have an OpenSSL-specific prefix in order not to pollute the
global namespace of the C compiler. Although not mentioned
explicitly in the policy, it is sensible to apply the same rule
to preprocessor #include guards as well.

For that reason, all include guard prefixes are changed from
'HEADER_' to 'OPENSSL_'.

I'm all for this change, including a back port to 1.1.1.

Ok, I added the [1.1.1] tag to indicate my intention for backporting. Note however, that I won't cherry-pick. Instead I'll apply the final  version of the update-openssl-include-guards script to the 1.1.1 branch (and create a separate pull request), once this pull request has been accepted.

I'm all for this change, including a back port to 1.1.1.

One final remark w.r.t. backporting:
I certainly agree that it would be desirable to have the change in 1.1.1. The only caveat I see is: What if application developers added some checks for include guards like the following in their code (possibly in some auxilliary include files) in order to add some amendments to the official openssl includes?
#ifdef HEADER_BIO_H
    /* some BIO related code */
#endif HEADER_BIO_H

We promised that applications only need to be recompiled for OpenSSL 3.0, but this pull request would break that promise for people who relied on the include guards.
OTOH one can argue that the names of the include guards are not considered part of the official API.
That's why I believe it demands at least a discussion (if not a vote) by the @openssl/omc members.

Supporting stupidity like that goes too far IMHO.

We promised that applications only need to be recompiled for OpenSSL 3.0, but this pull request would break that promise for people who relied on the include guards.

Rereading my comment, I noticed that I mixed two questions together.

Should we change the include guards in master, possible breaking builds agains 3.0?
Should we change the include guards in OpenSSL_1_1_1-stable, possible breaking builds agains 1.1.1?

Currently, my opion about those questions is

Yes we should. The benefits outweigh the inconveniences. But we certainly we need to inform people loud enough.
I don't know. We could consider using the #include guards an abuse of the API, but I'm really not sure whether we would annoy some users by introducing a breaking change in a bugfix release.

Supporting stupidity like that goes too far IMHO.

Oh, don't be too harsh with your critics: Here is one valid use case from myself: I'm currently porting my company's code from 1.0.2 to 1.1.1, so I wrote a single compatibility header openssl_compat.h , which adds all the necessary  amendmends for 1.0.2 (*) in order to compile our applications against both 1.0.2 and 1.1.1.  This compatibity header is included after all openssl includes in the modules which use them. By checking the OpenSSL include guards, only amendmends for the previously included OpenSSL headers are added.
Of course it could have been done differently, but having all changes in a single file was the most simple way to do it at the time.
(*) It mostly retrofits accessors for opaque structs. Sincewe are using C++, a lot of functions could simply be copy&pasted from 1.1.1 into the header file and just the inline declaration needed to be added.

Would a sequence like this avoid the compatibility concerns:
#ifndef OPENSSL_HEADER_FOO
# if OPENSSL_API_COMPAT < 0x30000000L
#  define HEADER_FOO
# endif
...
#endif

It's a bit ugly but in 3.0, we can deprecate symbols.  It doesn't address somebody who does #define HEADER_FOO and expects the header to not load when included.
I'd still like to see the HEADER part of the name, hence OPENSSL_HEADER_FOO.

Would a sequence like this avoid the compatibility concerns:
...

I'm not sure. I'd rather not backport this pull request than creating such a three-headed monster.

I'd still like to see the HEADER part of the name, hence OPENSSL_HEADER_FOO.

Do you have any particular reason for your wish? Because what I like most about my naming convention is precisely the fact that for all the public header files the include guard name and the include directive match nicely (e.g. <openssl/hmac.h> and  OPENSSL_HMAC_H). For the internal files, the correspondence is similar although not always consistent.
For me, the _H suffix (which is missing in your example) seems to be sufficient to indicate an include guard.  If that not obvious enough for an include guard, I'd prefer something like OPENSSL_HMAC_H_INCLUDED

The _H suffix would be sufficient I guess.  I don't think there are any examples of a macro ending _H unless it is a head guard.  At least not yet :)

I force-pushed new commits, adressing all review comments (hopefully). Manual changes were made exclusively in the update-openssl-include-guards script (commit b64721082624c1a1c736d53c3dadb72826ce5615), the bulk changes were regenerated  using the script (commit 1ee38fc6c30ee1349e7a5dad313ea99134151bee).
(The third commit was moved to the beginning temporarily, to avoid having to rebase it every time the script is changed. It will be moved back to the end when the reviewing is done.)

I created pull request #9283 as a proof-of-concept of how I intend to do the semi-automated backporting to 1.1.1.

@paulidale @bernd-edlinger now that everything looks right, I intend to add a CHANGES entry and finalize the commit messages. I'll do that later today and let you know when I need reconfirmation. Also it would be nice if this pr would receive a second approval from an OMC member (@levitte?).

@kroeckx @t8m what is your opinion as platform maintainers about the idea to backport the renaming of the include guard prefixes to 1.1.1 (see proof-of-concept in #9283)? On one hand, it is an overdue and sensible change. On the other hand, users might rely on the precise names of the include guards (see discussion following https://github.com/openssl/openssl/pull/9274#issuecomment-507044929), so doing it in a bugfix release might be too risky.

see discussion following https://github.com/openssl/openssl/pull/9274#issuecomment-507044929

in particular also https://github.com/openssl/openssl/pull/9274#issuecomment-507047651

I do not really have a strong opinion either way. I would probably leave it out of 1.1.1 unless this would complicate backports of future patches.
I do not see any reported issues to be fixed by this so that's the reason why I'd rather chose not to put it in 1.1.1.

@paulidale @bernd-edlinger I cleaned up the commits, added a CHANGES entry and removed the auxiliary script. Please take a look at the changes and at the commit messages in their final form
724bee14f0 CHANGES: Add entry about new #include guard prefixes
59267ccf59 Use 'OPENSSL_' as common #include guard prefix
c6ecebe2ed util/mkerr.pl: use 'OPENSSL_' as include guard prefix of *err.h files
and reconfirm your approval.

Needed a rebase to solve a conflict in the changes file.

I wonder why some header files have guards at all.  All the _lcl and _locl header files are typically included from .c files only, i.e. not recursively, for example...

yes, that appeared to me as well.

I'm not pushing anything today. It's impossible to do these changes properly on my little notebook display.

Pushed some additional fixes addressing @bernd-edlinger's comments (listed bottom-up)

The fixup! ... commits just contain trival search&replace changes
The squash! ... commits contain some additional information in the commit message

Note: the following two commits will not be squashed into one, in order not to break git's automatic rename detection:
commit 470c37f9d3dd2ef73aee3a6138e0303c4c9c1442
Author: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Date:   Thu Jul 4 13:40:36 2019 +0200

    add <openssl/ossl_typ.h> compatibility header

commit feb2fd59642085726f9198de07f8d661f3c6163d
Author: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Date:   Thu Jul 4 13:00:12 2019 +0200

    rename <openssl/ossl_typ.h> to <openssl/types.h>

Pull request  #9274 has grown too large now to be backported. Apart from that, it remained unclear whether changing the names of the #incude header guards in a stable release could be safely done without breaking things.
That's why I just closed pull request #9283.

I feel bad for poor @mspncp for "stepping in it" with this PR. :)  Maybe something like this would help, eventually script it to find mismatches:
; git ls-files | fgrep .h | xargs grep -m1 ifndef

Ok @bernd-edlinger, just give me another round to look at all include guards once more. Using git grep will be faster than searching manually through the change sets, and less work for you, too. I'll let you know when I'm through and I'm sure you still will find enough nits and errors for me to fix.
@richsalz thanks for offering you help. No need to worry, I'm not desperate yet ;-).

Thanks @mspncp and apologies for adding so many comments,
I really had no idea how this would evolve...
All my comments are only suggestions, if you see a way
to get things consistent one way or the other that is okay for me as well.

... apologies for adding so many comments

No problem, really. On the contrary: your comments encouraged me to do it properly and not stop half way. So let's pause briefly for a general thought about naming rules for include guards:
I intend to achieve exact correspondence w.r.t filenames, but not strict correspondence w.r.t relative paths, with the important exception that the relative path must match for all public header files <openssl/filename.h>. Matching relative paths strictly for all header files is just too meticulous IMHO.
So the intended naming scheme is roughly as follows:

#include <openssl/filename.h> <-> #define OPENSSL_FILENAME_H
#include "internal/filename.h" <-> #define OPENSSL_INTERNAL_FILENAME_H
#include "filename_lcl.h" <-> #define OPENSSL_FILENAME_LCL_H

Would that be ok for you? (Of course this question not only goes to @bernd-edlinger but to all other @openssl/committers, too).

One more question to all: some of the internal include files do not really require include guards, because they are only included by modules and not by other include files. Should I remove those superfluous include guards or should I leave them in for safety reasons)?

And last but not least:  having two different suffixes _locl.h and _lcl.h is inconsistent, too.
So here is a vote for the @openssl/committers:  which suffix do you prefer?

If you prefer the _lcl.h suffix, please add your 'thumb up' here

filename_lcl.h

If you prefer the _locl.h suffix, please add your 'thumb up' here instead

filename_locl.h

which one is more common today?

Hang on, I'll check it out...

msp@msp-nbw10:~/src/openssl$ find -name '*_locl.h' | wc -l
30
msp@msp-nbw10:~/src/openssl$ find -name '*_lcl.h' | wc -l
19

What would be more interesting: which suffix is older, which is newer :-)

I wouldn't mind to accept the vote from searching the source code. This would mean I'd go for _locl.h.

Hmm....
If we rename those local files, it would be good to do the rename on 1.1.1 as well,
since otherwise lots of PRs will fail to merge against 1.1.1.

Oh, git actually has an excellent file rename detection. In some cases, it will stop you and ask you to increase the renameLimit to a higher value. It even tells you how high it need to be.
I forgot what the defaults are, my limits are already relatively high:
git config merge.renameLimit
32768
git config diff.renameLimit
32768

(git tries to identify file renames along the path from one commit to the other commit via the merge-base. If the branching took place a long time ago this might take some time though.)

It might be better to discuss this on openssl-committers.

One more question to all: some of the internal include files do not really require include guards, because they are only included by modules and not by other include files. Should I remove those superfluous include guards or should I leave them in for safety reasons)?

I like the include guards - they are not difficult to add. The use of the headers can change over time.

The use of the headers can change over time.

Yes, I agree. I already had this in mind when I asked my question, but I didn't mention it because I wanted to add no bias to the question.

Superseded by #9333.

authors: bernd-edlinger levitte mspncp paulidale richsalz slontis t8m


text:
Add manager_extra_services to config.yaml and local.erb

Following the specification defined here, additional services can be enabled in the localrc file:

Other services that are not enabled by default can be enabled in localrc. For example, to add Swift, use the following service names:
enable_service s-proxy s-object s-container s-account

The manager_extra_services key in the config.yaml allows the specification of services to be enabled in the manager node. This is useful for example to test Swift without having to create another node.
If the manager_extra_services key is specified, a new enable_service line is added to the manager localrc file, with the requested services.

Thank you for contributing to openstack-dev/devstack-vagrant!
openstack-dev/devstack-vagrant uses Gerrit for code review.
Please visit
http://docs.openstack.org/infra/manual/developers.html#development-workflow
and follow the instructions there to upload your change to Gerrit.

authors: enricobacis openstack-gerrit

repo: openstack-dev/devstack-vagrant

license_source: bigquery


text:
Return DLRN MD5 hash to the child job

Due to multiple promotions, the tcib job and child job gets different current-podified hashes leading failure of pulling containers in the EDPM deployment jobs.
Returning the dlrn md5 hash to the child job makes sure we populate the same repo on the node.
Note: It also set the returned dlrn md5 hash to the repo-setup to generate proper repos with passed dlrn hash.
As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running
[x] Appropriate documentation exists and/or is up-to-date:

[x] README in the role
[x] Content of the docs/source is reflecting the changes

recheck

/approve

recheck

Only had a quick look but:
Writing the file works fine[1], it's collected [2] but not found?
Seems everything is running on the same node(controller) so not sure what's happening here.
2024-02-16 11:29:39.207860 | controller | TASK [repo_setup : Dump full hash in delorean.repo.md5 file content={{ _repo_setup_json['full_hash'] }}
2024-02-16 11:29:39.207866 | controller | , dest={{ cifmw_repo_setup_basedir }}/artifacts/repositories/delorean.repo.md5] ***
2024-02-16 11:29:39.207872 | controller | Friday 16 February 2024  11:29:39 -0500 (0:00:00.774)       0:00:10.993 *******
2024-02-16 11:29:39.729169 | controller | changed: [localhost]

[2] https://logserver.rdoproject.org/58/1158/3cb71c1758ed139e62fea7ca85b26512028ef11a/github-check/cifmw-tcib/d4778ee/ci-framework-data/artifacts/repositories/delorean.repo.md5
[3]
2024-02-16 17:14:05.053769 | TASK [Slurp dlrn md5 hash]
2024-02-16 17:14:05.316330 | controller | ERROR
2024-02-16 17:14:05.316506 | controller | {
2024-02-16 17:14:05.316536 | controller |   "msg": "file not found:  /home/zuul/ci-framework-data/artifacts/repositories/delorean.repo.md5"
2024-02-16 17:14:05.316558 | controller | }

Thank you @lewisdenny for taking a look at the pr. Yes, it's wired. I have added a task to check for that file. It will give some more data.

recheck dpa job failure unrelated

/override rdoproject.org/github-check
The failure isn't related to that change.

authors: cjeanner lewisdenny raukadah


text:
Ensure we keep track of generated content

It may happen we want to generate twice the same values.yaml, but with
maybe different content - this is especially true in the VA automation,
for instance two stages share the same src_file and the same
value.name, but the output is different.
In such as case, we want to consume the exact same values.yaml
(untouched), the same CI generaged content, and maybe a different user
provided kustomization.
While it was 100% supported, we may lose track of the history of the
changes. This patch therefore ensures we:

backup the files before override
exclude those backup files from the final values.yaml generation

As a pull request owner and reviewers, I checked that:

[X] Appropriate testing is done and actually running

/hold
I tested the backup: true but I want to test the "filter" on the find - this wasn't in my local test..

/approve

/hold cancel
seems to work properly. Molecule is running against that code, ensuring the filter is find - which is the heart of that role.

/approve

authors: cjeanner pablintino raukadah


text:
Rework inventory generation

First we move the inventory files generation to a far earlier stage.
While it doesn't change anything on its content, having the inventory
generated earlier helps debugging it without the need to create any
actual workload (hacky approach I used to validate the generated
inventories).
Then, the data used to generate the inventories is updated, in order to
ensure we're still puting the nodes under the right group.
This is especially important for the OCP cluster, when we have workers
in the picture.
Before this change, the workers were nested under the "ocps" group,
leaving the "ocp_workers" empty.
This change corrects the situation, leading the generated inventories to
look like this:
ocps:
  hosts:
    ocp-master-0:
      ansible_host: master-0.utility
      ansible_user: core
      ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
      ansible_ssh_private_key_file: ~/.ssh/devscripts_key
ocp_workers:
  hosts:
    ocp-worker-0:
      ansible_host: worker-0.utility
      ansible_user: core
      ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
      ansible_ssh_private_key_file: ~/.ssh/devscripts_key
computes:
  hosts:
    compute-xio2mlri-0:
      ansible_host: compute-xio2mlri-0.utility
      ansible_user: zuul
      ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
      ansible_ssh_private_key_file: ~/.ssh/id_cifw
controllers:
  hosts:
    controller-0:
      ansible_host: controller-0.utility
      ansible_user: zuul
      ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
      ansible_ssh_private_key_file: ~/.ssh/id_cifw

recheck

/approve
/lgtm

authors: cjeanner raukadah


text:
Add repo-setup service in hci edpm job

https://github.com/openstack-k8s-operators/ci-framework/pull/800 avoid copying repositories generated by repo-setup to compute nodes.
in HCI edpm job, download-cache service was failing to install packages because there is no repos configured on the edpm node.
Adding repo-setup service to the edpm service list will fix the issue.
As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running

recheck

recheck

recheck

/lgtm

authors: cjeanner raukadah son-vyas viroel


text:
Add relatively simple example of people merging

People merging was a bit of a mystery, which was causing some troubles at the end of the session. This PR shows an example of actually merging people data to give users a better sense of how it would happen.
Also add some basic docs on how scheduled django admin tasks are executed.

This looks good if you want to merge

authors: NewAgeAirbender johnseekins

repo: openstates/documentation


text:
update imagery

apparently running tests updates this file
I am submitting it as PR because it would be preferable to not have this unrelated code changes appear suddenly. I expect that it will stop once this is in the master branch.

output from failed build:
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
nvm.setup
$ export PATH=./node_modules/.bin:$PATH
Updating nvm
nvm.install
2.80s$ nvm install 8
Downloading and installing node v8.12.0...
Downloading https://nodejs.org/dist/v8.12.0/node-v8.12.0-linux-x64.tar.xz...
Computing checksum with sha256sum
Checksums matched!
Now using node v8.12.0 (npm v6.4.1)
$ node --version
v8.12.0
$ npm --version
6.4.1
$ nvm --version
0.33.11
$ npm install
npm WARN deprecated queue-async@1.0.7: renamed to d3-queue
npm WARN deprecated text-encoding@0.6.4: no longer maintained
npm WARN deprecated circular-json@0.3.3: CircularJSON is in maintenance only, flatted is its successor.
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

seems to not be caused by this code change

I am submitting it as PR because it would be preferable to not have this unrelated code changes appear suddenly. I expect that it will stop once this is in the master branch.

Sure.. we don't have to, but there's no harm in updating it..

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself. Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received The build has been terminated

Ugh, yeah sometimes this happens.  It's just a timeout because they couldn't connect to npm or something, not a true failure.

authors: bhousel matkoniecz

repo: openstreetmap/iD

license: ISC


text:
mock bugfix for when a value is not a string

Fixes #202

lgtm :+1:
merging @matteofigus

authors: jankowiakmaria matteofigus

repo: opentable/oc

license: mit


text:
(327) Fix - Custom headers of one component can appear to another.

The problem was introduced with #326 -
In get-component.js the declaration of responseHeaders variable happens in a more
global scope than it should be. For this reason every invocation of renderer
function sees the changes in the headers made by previously requested
components.
The fix is to just move the declaration one scope inner.

Added a unit test to validate the fix - it tries to load two components
subsequently. The first one does provide custom headers while the second
one - don't. Then we check and expect to see there are no custom headers
in the result for the second one.

Excellent, thanks @ivan-dimitrov-skyscanner

This fixed #327

authors: ivan-dimitrov-skyscanner matteofigus


text:
Add Finngen as a gene burden evidence source

24.09 incorporates ~400 evidence resulted from LoF burden analyses made on the Finnish biobank. We need to update the widget and docs to add Finngen as a new source
Background
The data has been integrated without any changes needed other than specifying Finngen as a datasource

Practically all of the associations covered by Finngen were not present in other burden results. This is by looking at the direct associations only. Some examples that will be useful to check the FE:
+---------------+-------------+---------+
|       targetId|    diseaseId|  sources|
+---------------+-------------+---------+
|ENSG00000001626|MONDO_0009061|[FinnGen]|
|ENSG00000004939|MONDO_0008315|[FinnGen]|
|ENSG00000012504|   GO_0036273|[FinnGen]|
|ENSG00000027001|MONDO_0002135|[FinnGen]|
|ENSG00000034971|  EFO_0004190|[FinnGen]|
|ENSG00000034971|  EFO_0004235|[FinnGen]|
|ENSG00000034971|  EFO_0005752|[FinnGen]|
|ENSG00000034971|   GO_0009410|[FinnGen]|
|ENSG00000048828|  EFO_0000221|[FinnGen]|
|ENSG00000070444|MONDO_0015597|[FinnGen]|
|ENSG00000072818|  EFO_0003779|[FinnGen]|
|ENSG00000072818|  EFO_0004705|[FinnGen]|
|ENSG00000072818|  EFO_1000627|[FinnGen]|
|ENSG00000074657|  EFO_0003951|[FinnGen]|

Tasks

[ ] Add FinnGen to the widget subheader (after AstraZeneca PheWAS and Genebass) with a link to https://www.finngen.fi/en
[ ] Update docs. Unfortunately we don't have a manuscript to reference these results

Works in dev

repo: opentargets/issues


text:
removing Volume Modules, Redirecting in runtime.yml

I removed all volume_xx modules as they were replaced by openstack native ones https://github.com/opentelekomcloud/ansible-collection-cloud/issues/89
I redirected all modules we don't have in our collection to native openstack ones so that it's not necessary to use the full FQDN now. For example Instead of openstack.cloud.server you can now just write server in integration tests or opentelekomcloud.cloud.server which makes it simpler to use the modules.
Closes #89

recheck

I needed to change the volume_backup_info integration test as it was looking whether "backups" is defined and the native openstack module calls it "volume_backups" so it was failing.
This may have impact on older Scripts and it may need another workaround

recheck

recheck

recheck

recheck

recheck

recheck


text:
Tayga cannot start

I'm using borderrouter on Raspbian.
With change provided in #158 I cannot start tayga, because tunnel device is not created. When I try to create interface with tayga --mktun I get following error message:
Error: ipv6-addr directive must be specified if prefix is 64:ff9b::/96 and ipv4-addr is a non-global (RFC 1918) address

According to this error message, #158 is incorrect. Should we revert it?

When I revert #158 manually, tayga works correctly.

I saw the same Tayga error here after $git pull to the latest from #146

add ipv6-addr for well-known prefix in merge request #177

repo: openthread/borderrouter


text:
[cli] add command to get network data versions

This commit adds new CLI command netdata version to get the current Network Data's version and stable version.

Note that this information is also available via the leaderdata CLI as well: https://github.com/openthread/openthread/tree/main/src/cli#leaderdata

Note that this information is also available via the leaderdata CLI as well: https://github.com/openthread/openthread/tree/main/src/cli#leaderdata

I see. Thanks. I will close this then. We can get it from leaderdata

authors: abtink jwhui

repo: openthread/openthread


text:
Consider defining security layer

This issue is tracking the consideration and potential designs of a point-to-point security layer for protecting the Spinel stream from from evesdropping or manipulation in case of physical compromise.

I guess the first consideration would be regarding using DTLS or instead using some sort of bespoke protocol. Often times DTLS is tied very closely to the IP networking stack, so it might not be the easiest thing to use.
For a simple high-entropy shared-secret (128 random bits shared between the chips) type of thing, we could pretty easily negotiate a shared key that we could then use to secure the channel with AES-CCM*, which is the same stream cipher that is used in 802.14.5. We would need to renegotiate the keys at every boot and every couple billion packets, but that shouldn't be too difficult.
I'd recommend we avoid using the shared secret directly as the key, since that would require the use of a key counter. It is easy to avoid using such a counter, as long as each chip has a way of generating strong random numbers.

repo: openthread/spinel-spec


text:
Request to transfer opentracing-java-aws under opentracing-contrib

Please help me to transfer java-aws (https://github.com/malafeev/opentracing-java-aws)
under opentracing-contrib

Could you please provide more details about what this lib is actually instrumenting, so that we can pick an appropriate repo name? AWS is a huge ecosystem.

it is an java aws sdk instrumentation (s3 client, dynamodb client etc).
@bhs already created repo: https://github.com/opentracing-contrib/java-aws-sdk
thanks

@yurishkuro as I understand it, the idea is to provide interceptor-style tracing for the AWS SDKs. IMO it's worth batching those into a single git repo since there is a lot of redundancy.

authors: bhs malafeev yurishkuro

repo: opentracing-contrib/meta


text:
🛑 [CN] OpenUPM Website is down

In 070cd3c, [CN] OpenUPM Website (https://openupm.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website is back up in 50f1c2d after 17 minutes.

repo: openupm/upptime-openupmcn

license: MIT


text:
🛑 [CN] OpenUPM API /packages/extra is down

In 4a55bca, [CN] OpenUPM API /packages/extra (https://api.openupm.cn/packages/extra) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM API /packages/extra is back up in b9bea35 after 18 minutes.


text:
🛑 [CN] OpenUPM Website Package Detail is down

In c95c3fc, [CN] OpenUPM Website Package Detail (https://openupm.cn/packages/com.littlebigfun.addressable-importer/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Package Detail is back up in 4792895.


text:
Home page in UI

My actions before raising this issue

[x] Read/searched the docs
[x] Searched past issues

Possible Solution

Currently we have a menu on top with buttons like Project, Tasks, Cloud Storages, Models, etc. In many cases it is useless. For example, for a job it is much better to have Home page | Project #x > Task #y > Job #z where Project #x and Task #y can be links on corresponding pages.
The Home page can have some information about user's activity, some statistics, and big buttons on Projects, Tasks, Jobs, Models, and other pages.  It is more intuitive and will allow us to use the top panel for really critical information.

Possible design of Home page

authors: bsekachev nmanovic

repo: openvinotoolkit/cvat


text:
Improve PIL and COLOR_BGR context image decode performance

Summary

Ticket no. 141409
There was a significant performance degradation on decode_by_pil() if ImageColorChannel.COLOR_BGR.
Improve it by returning a numpy array rather than PIL.Image and using cv2.cvtColor() rather than np.flip().

How to test

tests/unit/test_image.py covers this change.
Compare performance with this code (dataset: Imagenette2)

before
after

00:51<00:00, 361.65it/s
00:19<00:00, 859.39it/s

Checklist

[ ] I have added unit tests to cover my changes.
[ ] I have added integration tests to cover my changes.
[x] I have added the description of my changes into CHANGELOG.
[ ] I have updated the documentation accordingly

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[x] I have updated the license header for each file (see an example below).

# Copyright (C) 2024 Intel Corporation
#
# SPDX-License-Identifier: MIT

Rebased and targeted to releases/1.7.0

repo: openvinotoolkit/datumaro


text:
Overhaul update-bcd.ts

The update-bcd script is in dire need of an overhaul.  It has become too complicated and not easy to maintain, so bugs are challenging to squash.  The script should be rewritten from the ground up in a multi-stage process.

https://github.com/mdn/browser-compat-data/pull/19971 moved this script into BCD and some enhancements are planned. Would it make sense to remove the script from this repo instead after confirming the changes made are exactly the same?

I opened https://github.com/openwebdocs/mdn-bcd-collector/pull/740

authors: Elchi3 foolip queengooborg

repo: openwebdocs/mdn-bcd-collector


text:
Amend the Charter doc to clarify our position on free/paid countent?

Do we need a policy statement from OWD that OWD will only put effort / energy into features & content that is fully free to consume?

Yes, I think we should (both only work on free content and have that explicitly in the charter). I think we should connect this with making web documentation available to as many people as possible. But I'm not sure how we should integrate that into the current wording of the charter.

Yes.
Would it be sufficient enough to add some bits to the last paragraph? Like so:

Open Web Docs invests in and protects free documentation for the open web platform. We provide incentives and a platform for other related organizations to get involved in this work. We ensure developers have the best information available for free to make technology and design decisions and implement on the web platform.

Or do we think this needs its own core value?

authors: Elchi3 torgo wbamberg

repo: openwebdocs/project


text:
[requirements] Update dependencies #65

Dropped Support for python2 and added support for python 3.8
Updated to django 3.0 and removed support for all django versions lower than 2.2
Shifted to jsonfield2 from jsonfield
Fixes #65

Coverage increased (+0.3%) to 99.169% when pulling 59c29f060c9526b12a353d6d5016ca2907905f1b on Weirdo914:master into 953ce2f5fbcb9780dbf69ebf3dcc4d196ef57b1e on openwisp:master.

Coverage increased (+0.3%) to 99.169% when pulling 59c29f060c9526b12a353d6d5016ca2907905f1b on Weirdo914:master into 953ce2f5fbcb9780dbf69ebf3dcc4d196ef57b1e on openwisp:master.

I made the migrations why is it still failing


text:
Travis CI fails

https://travis-ci.org/hackrid/isotp-c/builds/142710775

Hey there! You have this commit in your tree that broke it: https://github.com/hackrid/isotp-c/commit/901370aa72d39aaab2a7a7eec1c8d4b4b7b41aa5
This isn't in master, so you may have forked from someone else's repo? I just added a small update to the main repository at the tests are passing.

authors: hackrid peplin

repo: openxc/isotp-c


text:
Collection-tier service naming practice

If there was a documented practice for naming services, implicitly traced spans could have more relevant names.
@karlunho and @dankosaur mentioned the same solution to this, which is a stage in collection that resolves names.

This could be a google doc in the features folder, if interested enough: https://drive.google.com/drive/u/1/folders/0B0tSnQT3uGdAfmZaVzZfOXJRRzZPUmRDRFVGRUFHVm1fX2ZXenM1VGN3RElTQzc3azI3X1k

Lacking this, there's a fallback order at query time, but this code has proven itself high maintenance. If there was a way to hard-set a service name correctly before storage, this problem space could become smaller.
ex. https://github.com/openzipkin/zipkin/blob/master/zipkin-common/src/main/scala/com/twitter/zipkin/common/Span.scala#L76
  /**
   * Tries to extract the best name of the service in this span. This depends on annotations
   * logged and prioritized names logged by the server over those logged by the client.
   */
  lazy val serviceName: Option[String] = {
    // Most authoritative is the label of the server's endpoint
    binaryAnnotations.find(_.key == Constants.ServerAddr).map(_.serviceName).filterNot(_.isEmpty) orElse
      // Next, the label of any server annotation, logged by an instrumented server
      serverSideAnnotations.headOption.map(_.serviceName).filterNot(_.isEmpty) orElse
      // Next is the label of the client's endpoint
      binaryAnnotations.find(_.key == Constants.ClientAddr).map(_.serviceName).filterNot(_.isEmpty) orElse
      // Next is the label of any client annotation, logged by an instrumented client
      clientSideAnnotations.headOption.map(_.serviceName).filterNot(_.isEmpty) orElse
      // Finally is the label of the local component's endpoint
      binaryAnnotations.find(_.key == Constants.LocalComponent).map(_.serviceName).filterNot(_.isEmpty)
  }

@adriancole is this thought still valid or can we close ?

v2 format made this far less hairy than before. in v1 you could have like 4 different names in the same span!

authors: adriancole jorgheymans

repo: openzipkin/zipkin


text:
add router module

...and tidy names

TODO:

fix router module call args
test in linode sandbox


text:
Update Subscription Status with Deprecation Warnings

Description of the change:
Adds the OperatorDeprecated Condition to the status of Subscriptions when the bundle has been deprecated.
Doing this in the step resolver is convenient because:

We have ready access to the cache entries.
Subscription status is already updated in this area.
Deprecated status should be added promptly if a catalog update occurs which adds the property to a bundle.

Modifying the subscription status within the resolver was both problematic and risky. We've changed strategies and are now updating status during catalog state update. This carries much lower risk.
Remaining Tasks:

[x] Populate cache entries with deprecation info.
[x] Add additional deprecation condition types (package, channel, bundle).
[x] Update logic in catalog operator's syncResolvingNamespace to account for subs updated with only OperatorDeprecated and do not necessarily require InstallPlan updates in the namespace (currently it assumes all updates are new bundles).
[x] Update test and/or add more tests with additional condition types (as above).
[x] Update go.mod to use merged/released API updates to api and registry.
[x] Squash commits where appropriate.

Motivation for the change:
Closes #3099
Brief
RFC
Architectural changes:

/lgtm

/approve

/lgtm

authors: awgreene dtfranz grokspawn joelanford


text:
How to watch all CRs with a specific label?

Type of question

<-- General operator-related help -->

Question: How to watch all CRs with a specific label?
What did you do?
could not find documentation on how to watch all CRs that have a specific label
What did you expect to see?
Documentation about this feature
What did you see instead? Under which circumstances?
I found this issue - but not sure it is related: https://github.com/kubernetes-sigs/controller-runtime/issues/244
Environment
Operator type:

<-- /language go -->

Kubernetes cluster type:
<-- "OpenShift" -->
$ operator-sdk version
operator-sdk version: "v1.0.0-27-g7d672a12", commit: "7d672a1279bc5205e0f5e3c048c5b47dbe364e4e", kubernetes version: "v1.18.2", go version: "go1.15 darwin/amd64", GOOS: "darwin", GOARCH: "amd64"
note that I'm writing the operator based on documentation of v0.19 because v1.0.0 was very buggy and unusable
$ go version (if language is Go)
go version go1.15 darwin/amd64
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-16T00:04:31Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.1+3288478", GitCommit:"3288478", GitTreeState:"clean", BuildDate:"2020-07-23T22:24:05Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
Additional context
I'm writing an operator that will watch all CRs in a specific namespace and wrap them as Deployables (to be then deployed to a multicluster using IBM MCM or RedHat ACM)

https://github.com/kubernetes-sigs/controller-runtime/issues/244 is indeed related. Once that feature is proposed/implemented in controller-runtime, Go projects scaffolded by operator-sdk will support it. Since a corresponding issue exists upstream, I'm closing this one.

authors: arivatibm estroz

repo: operator-framework/operator-sdk


text:
internal/pkg/scaffold/olm-catalog: do not add duplicate channels, use operator-name

Description of the change:

ensure channel does not exist before appending to channels.
use OperatorName instead of ProjectName to match CSV scaffold behaviour.

Motivation for the change: package manifests should not have duplicate channel names.

/test marker

@estroz Can you also update the CHANGELOG?

/test marker

/retest

/retest

authors: estroz joelanford


text:
commands/.../up/local.go: handle sigint and sigterm

This commit fixes issue #366 and kills the go run command spawned
by up local when a SIGINT or SIGTERM signal is sent.

LGTM

Fixed

lgtm

authors: AlexNPavel fanminshi hasbro17


text:
Staggered setup

The main issue is that currently, and as expected, with staggered object, some fields have different size (1 point less/more in the staggered direction)
We need to add an extra one point to the halo so that all fields have same size and we don't have OOB. For some reason it doesn't break now as I think the smallest extent is inferred, however it means the last point is not computed for some fields.

thinking again about this, is it really true that we have OOB? don't we just have one extra unused point in staggered Functions ?

I think this can be closed.

For some reason it doesn't break now as I think the smallest extent is inferred, however it means the last point is not computed for some fields.

any comments about this?

@mloubout I suspect this can be closed now?

Yes, closing

authors: FabioLuporini mloubout

repo: opesci/devito


text:
Tutorials improvements

New clean Pull Request to substitute 704 due to
a bad handling of me.
Main points of revision is this:
https://github.com/opesci/devito/pull/704#discussion_r233517834
I would like to ask sorry for my bad handling.
I accidentally merged an old master and force pushed.
TODO squash multiple commits.

Codecov Report

Merging #735 into master will decrease coverage by 5.3%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #735      +/-   ##
==========================================
- Coverage   88.05%   82.75%   -5.31%
==========================================
  Files         100      100
  Lines        9931     9931
  Branches     2014     2014
==========================================
- Hits         8745     8218     -527
- Misses        941     1439     +498
- Partials      245      274      +29

Impacted Files
Coverage Δ

devito/mpi/routines.py
19.13% <0%> (-80.87%)
:arrow_down:

devito/mpi/utils.py
22.72% <0%> (-77.28%)
:arrow_down:

devito/builtins.py
24.24% <0%> (-48.49%)
:arrow_down:

devito/mpi/distributed.py
52.15% <0%> (-38.28%)
:arrow_down:

devito/core/operator.py
49.35% <0%> (-36.37%)
:arrow_down:

devito/function.py
75% <0%> (-17.21%)
:arrow_down:

devito/types.py
85.79% <0%> (-8.85%)
:arrow_down:

devito/data/data.py
82.98% <0%> (-8.77%)
:arrow_down:

devito/core/autotuning.py
78.91% <0%> (-7.57%)
:arrow_down:

devito/ir/iet/scheduler.py
90.21% <0%> (-6.53%)
:arrow_down:

... and 15 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ac1d00d...c4bec0e. Read the comment docs.

then can we close #704 ?

Merged.

authors: FabioLuporini codecov-io georgebisbas


text:
Slack auto invite

Added a link to the website so people can automatically join the slack channel - we no longer need to invite them.

yes

authors: FabioLuporini navjotk


text:
remove DHCP images and use public ones

Signed-off-by: Boris Glimcher Boris.Glimcher@emc.com

use #172 instead

repo: opiproject/sztp


text:
Interface Statistics Widget table rotation

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[X] I have searched the existing issues and I'm convinced that mine is new.
Is your feature request related to a problem? Please describe.
As you can see my screenshot below and this is on a 1440p monitor by the way, is that I have so many interfaces, that the table gets too wide and it goes under other widgets (2 columns on my dashboard).

Describe the solution you'd like
I would like to have the Interface Statistics Widget table rotated, to allow a OPNsense instance with many interfaces display correctly. If we were to rotate it around this would make all interface viewable, and should also make it visible on all screen sizes and if you have more columns on your dashboard.
Interfaces down the first column and then the packets, bytes, errors along the top, if that makes sense?
Describe alternatives you've considered
There isn't really other than not using the Interface Statistics Widget.
Getting a 21:9 4k monitor... tempting but expensive.
Additional context
Only really effects people with loads of interfaces.

Hopefully my PR for this is up to scratch. It's my first PR for OPNsense 🤭

https://github.com/opnsense/core/pull/4957

repo: opnsense/core


text:
firewall: validate maximum shaper bandwidth

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.
Setting bandwidth too high will fail ipfw validation and will therefore not work.
Describe the solution you like
Validate the maximum bandwidth and/or parse the ipfw output on rules reload.
Describe alternatives you considered
Adjust bandwidth setting to not have a real world reachable maximum bandwidth, but allegedly that is trickier than it sounds in FreeBSD.
Additional context
https://github.com/opnsense/src/issues/129

oops, dup of #5224


text:
firewall rule with alias / MAC does not work reliable

I use a

Sophos SG 115Wr1
with OPNsense 23.7.5-amd64.

For my "smart" home i have installed several IOT devices of Type ESP8266.
I want to restrict access of these devices, thus i defined an alias ESPs based on MAC addresses.

As in my setup access is forbidden in general, i make one rule ESP_an_MQTT to allow traffic for ESP

Unfortunatelly in some cases traffic was blocked.
So i made a second rule that is not based on alias with mac address but with the netmask. That rule is called ESP_an_MQTT_NetMask
See the resulting firewall actions:

Although the ip-adress and mac-adress do not change, the same device sometimes triggers the rule ESP_an_MQTT and sometimes the rule ESP_an_MQTT_NetMask.
If i would not have the additional rule ESP_an_MQTT_NetMask at that time the IOT device would not work and be blocked.
Why is the firewall rule ESP_an_MQTT not working reliable?

I'd guess the problem is that you can't use wildcards in MAC address.
The logic behind is, that it looks in the arp table for current pairs and replaces the mac with the IP :)

As you see in screenshot of the firewall action, sometimes the rule with aliases of mac does not work but 40 minutes later it works.
So it can not be a generell problem with wildcards in MAC addresses.
But perhaps you give a hint:
When does a device disappear from arp table?
How often are the mac addresses replaced with ips?

I made some further testings and it seems that checking arp static table entry  for the dhcp reservation solves the problem.

authors: Lutzion mimugmail


text:
[openvpn] option "block-outside-dns" as checkbox wanted

Hello there.
Since there is a DNS Leak in Windows10 with OpenVPN:

https://github.com/ValdikSS/openvpn-fix-dns-leak-plugin

https://community.openvpn.net/openvpn/ticket/605?__cf_chl_jschl_tk__=a6f7e219f2b7eea6fc3ca6b90a4110db5a79564c-1601904949-0-ARrwznt-ux1J9GjbUS8gszDZBI0hn28Dd0jy2ikTJxVf41p3aezfcUpfH25Ej8iSQAZtUu_HJtAeIloJIhyCbk_N7JPQ9WOOO7lXJiGRJu6a4e2xuzHFOzpQlGyO7yy6eHHqaHdg8tlO7J6qBdJ5-bXUeLq1bAb4PP1Cc8QQbgT1e8fJ2OdREtjaSsrA6pO5KmT0GCkXMOAW7xI_wakhhi7q_1biJQ0Fwu7kG9XDkEUB827hH6J7ildMj6KCdsKnuAGyjJ35xiFb-Vs78FSlrCi8AbrOIKG_o3B_NHK95U4n

https://redmine.pfsense.org/issues/6719

it appears that our roadwarrior clients do not use our DNS server,
if they have a faster IPV6 (DNS) address in their cache.
We can fix this by adding:
push "block-outside-dns"
at:
Setting OpenVPN Server > Adv Options > Custom Options
Well this works quiet good, but we try to avoid using this field,
duo to security. Although this field is going to be removed in the future.
So it would be nice to have a checkbox for that command at the server config.
It would be really great, if you could implement that option.
:)
kind regards

@mpl1ma best open a feature request in core (using our template) https://github.com/opnsense/core/issues/new?assignees=&labels=&template=feature_request.md&title=

repo: opnsense/plugins


text:
Nginx not using TLS 1.2 despite it being in the config

I can’t seem to find help anywhere, so I am asking here additionally.
I need TLS 1.2 for the iOS Apps of Bitwarden and Jellyfin (Swiftfin). I setup my Reverse Proxy to use TLS 1.2, 1.3 with Ciphers from that Mozilla SSL Configurator.
I applied the settings again, I can see these settings in the nginx.conf using the shell and I still don‘t have TLS 1.2. It’s always just TLS 1.3 when I check it with these Testing Sites and I also don‘t have a working App.
Before I used the one built into Synology DSM where it worked.
Anybody here that has an idea?

any hints in nginx general\access\error logs?
can you share server ssl_*  directives values from config? (may be it ssl_ciphers or ssl_prefer_server_ciphers)

I can see these settings in the nginx.conf using the shell

I hope @fichtner will someday have time to look at https://github.com/opnsense/plugins/pull/3678 and we will try to make it possible to view the config in the GUI :wink:

any hints in nginx general\access\error logs? can you share server ssl_* directives values from config? (may be it ssl_ciphers or ssl_prefer_server_ciphers)

Thanks for answering. I can't find anything TLS related in the logs. The ssl_* directives look like this:
    ssl_protocols TLSv1.2 TLSv1.3;     ssl_dhparam /usr/local/opnsense/data/OPNsense/Nginx/dh-parameters.4096.rfc7919;     ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;     ssl_session_timeout 1d;     ssl_session_cache shared:SSL:50m;     ssl_session_tickets off;     ssl_prefer_server_ciphers off;
I used this for reference. Seems to be something like Synology is using in their Nginx implementation.

got it, thanks. looks good, so i think its OpenSSL work and  its not the default server in nginx?
what if you set this params in default_server config or make this server default_server?

Setting the TLS 1.2 one as default_server worked, but now every entry seems to use TLS 1.2. Is that normal?

In my understanding - yes, This is how OpenSSL works: if OpenSSL applies some of the params before the nginx SNI-callback (and it looks like this is still the case from the time of https://forum.nginx.org/read.php?2,254016,254673#msg-254673 ) or there is the lack of SNI info in request - then the default server params will be applied.
so yes, if you need to support the majority of clients, then you need to select a trade-off params on the default server (a client with TLS1.3 support will choose it. older client will choose 1.2)

What would happen if I had multiple default servers and what exactly is the function of the default server?

There can be only one © default_server for every address:port pair. default_server directive simply allows to manipulate the order in which a server is selected for a suitable socket without changing the order of entries in the config
https://nginx.org/en/docs/http/request_processing.html


text:
SNMP: Support for SNMPv3

Hi all,
are there any plans to implement support for SNMPv3? Via WebGUI there is only basic support which (I guess) leads to SNMPv2. There are options to configure SNMPv3 directly in /etc/snmp.conf but I'm not sure if any changes there are safe for updates of the SNMP Plugin or OPNsene itself.
Best regards,
Markus

Hi Markus,
Not familiar with SNMPv3 on FreeBSD yet, but this looks promising as a guide to sketch out a working config:
https://lists.freebsd.org/pipermail/freebsd-current/2014-April/049343.html
If we have a working config we can add the required GUI knobs. How does that sound? :)
Cheers,
Franco

@fichtner at the same time, snmp could be converted to MVC. The plugin seems to be a simple form with a bit of validation.

Hi Franco,
me neither, but that sounds like a deal :)  I'll investigate that the next days.
The challenge here seems to be to work with what is shipped with OPNsense. Based on man page for snmpd.conf there is similar command to net-snmp-create-v3-user which can be found on linux and just creates the lines in /etc/snmp/snmpd.conf and /var/lib/net-snmp/snmpd.conf. As described here https://www.freebsd.org/cgi/man.cgi?query=snmpd.conf&manpath=ports&sektion=5 in section "SNMPv3 USM Users".
I'll play around a little bit with that and come back to you as soon as I got a working configuration :)
Best regards,
Markus

@markuspachali thanks in advance! :)

Hmm... okay, it's not net-snmp which is used, it's bsnmpd. That makes it a "little bit" more complicated. There is nearly no documentation regarding snmpv3 available. This will take some time for me to get a working configuration.
Is there a reason why OPNsene decided to use bsnmpd and not net-snmp? Are there otherwise any chances to  replace bnsmpd with net-snmp, which would make it much easier to get SNMPv3 working?

Very historic reasons. bsnmpd is in the FreeBSD base system, that's all. net-smpd was added to pfSense just this year. I don't mind adding it for SNMPv3 or as an alternative to bsnmpd. One of the key goals has been reached with 17.1: removing the service from the base system.
It would make Fabian's request even easier, we could add a new os-net-snmp package based on MVC and not touch the os-snmp package.

Adding net-snmp as an alternative for bsnmp would be great.
I've spend some time go get a working SNMPv3 config for bsnmpd but without success. Based on my understanding of the comments in the config file /etc/snmpd.config (which is the only documentation I could find) everything is fine. I'm also able to start the deamon with "/usr/sbin/snmpd -c /etc/snmpd.config -d" but there is absolutely no response from the server. SNMPv2 is working fine.
The only current limitation for net-snmp Ic could find is, that there is currently no direct access to pf statistics:
https://forum.pfsense.org/index.php?topic=124071.0

@markuspachali that could be a problem because PF is the core component of OPNsense. However a plugin could be created and it will support the additional OIDs as soon as upstream does it.

hi,
we looking for switching from PfSense to OpnSense and using SNMPv3 for monitoring. It works since a few month under Pfsense but I saw, that OpnSense  doesn't support it yet (which is very sad).
But that is something which I don't understand also from other projects: products/solutions which has there places in security based areas and doesn't support tools / protocols which is required there. SNMP is one of the.  SNMPv2 should be removed from everywhere :-)
I was very happy (also the PCI/DSS auditor), that Pfsense added the v3 version ;-)

Hi,
At the end of the day: who will start the work? :)
Cheers,
Franco

@linuxmail can you upload a anonymized config of v3? I only use v2 since it's my own trusted network :)

@linuxmail I don't mean the xml file, just the snmpd.conf etc.

hi,
I tried to install the PFSense package from net-snmpd and configure it by hand, but the version was compiled with Perl 5.24 but OpnSense has 5.26. So the Daemon refuse to start.

We have the package...
# pkg install net-snmp

hmm, damn :-) Ok, package installed from the repo and now configure:

/etc/rc.conf.d/snmpd

snmpd_enable="YES"
snmpd_flags="-LF 0-4 d -C"
snmpd_conffile="/usr/local/etc/snmp/snmpd.conf /usr/local/etc/snmp/netsnmpd-users.conf"
conffile="/usr/local/etc/snmp/netsnmpd-users.conf"

and configured like my configs above .. and it works for localhost, but not from a different host. Firewall is  open ... hmm.

It must have something todo with the firewall. If I disable the firewall (through the options), than it works also from the remote host. I have on all interfaces an ipv4 allow rule from * to destination *. No other rules.

Your paths are not consistent, is it /var/etc or /usr/local/etc/snmp?
It's ages ago since I used net-snmp (with Linux) ...

hi @mimugmail
on the PFSense  /var/etc is used, on OPNSense usr/local/etc/snmp

I finally started with this plugin. Is it ok only allow v2 and v3?
And for v3 only SHA / AES? I dont want to make and option for DES or MD5 or would this break something?

hi,
thanks for it :-) SHA/AES is fine, since DES / MD5 is depricated. It would not break anything, it says only that old monitoring software isn't able to use V3, but in that case, they can use SNMPv2.

@linuxmail with 18.1.9 you can install the devel pkg via CLI:
pkg install os-net-snmp-devel
I'd love to have some feedback if it works for you (on a test machine).
It currently lacks interface binding (it listens to all) and snmp traps.

No problem, I will test it on our pre production servers on Monday.

hi,
I upgraded both hosts and it seems to be working seamless :-) The only very small issue I had, was that on one node  the agentaddress config line was wrong, as the port was missing. But I removed the whole line (may it was done by me with a copy paste error) and voila ... Icinga2 was happy again with the SNMP checks.
So, great work !

Thanks for testing, I'll try to add bind Interface selection and traps, then it can Go stable.

I have another feature request. Currently v3 users are created as read only (rouser in config). I'd like to have an ability to create r/w users (rwuser in config).

@TheGoblinHero @linuxmail
You guys know what exactly is needed for rw access in addtion to ro?
Never used rw access and I don't want to just guess the solution

You guys know what exactly is needed for rw access in addtion to ro?
Never used rw access and I don't want to just guess the solution

Edit /usr/local/opnsense/service/templates/OPNsense/Netsnmp/snmpd.conf and change "rouser" to "rwuser". Create a user using the web interface. After that you can execute snmpset:
snmpset -v3 -lauthPriv -uusername -asha -Apassword -xaes -Xencryptionkey 127.0.0.1 1.3.6.1.4.1.8072.1.5.3.1.2.1.3.6.1.2.1.2.2 i 1

Will be in next version:
https://github.com/opnsense/plugins/pull/890/files

authors: TheGoblinHero fabianfrz fichtner linuxmail markuspachali mimugmail


text:
add nps

I was getting some errors with a few utilities, so added some nps. If there's an alternative fix, by all means go ahead.
@cliffckerr

looks good, thanks @robynstuart !

authors: cliffckerr robynstuart

repo: optimamodel/sciris


text:
Enable select to be cleared.

Thanks for a great component.
This PR allows it to be "cleared".
I'm not sure how to handle the nullable, maybe better handled by validation?
(I left the js in "dev" mode)
Cheers,
Lindsay

Thanks, that's a good idea. I'll add more functionality and docs in a second.

Hey. I improved on your PR and added some changes, the field should now work as expected when nullable. You should call ->nullable() or ->nullable(true) on the field to make it return null, as is default with Nova fields. Thanks!

authors: Tarpsvo potentweb

repo: optimistdigital/nova-multiselect-field