Created attachment 213912 [details] poudriere build log for net-mgmt/netdata-1.21.1 After the new version of netdata (1.21.1) landed in ports, it fails to build. Most likely due to me having "DEFAULT_VERSIONS+= ssl=libressl" in make.conf. The following log lines seem relevant: libnetdata/socket/security.c:71:16: error: use of undeclared identifier 'TLS1_3_VERSION' return TLS1_3_VERSION; libnetdata/socket/security.c:74:12: error: use of undeclared identifier 'TLS_MAX_VERSION' return TLS_MAX_VERSION;
Created attachment 213913 [details] libressl-patch from upstream The attached file fixes the problem. Upstream is in the process of merging this. Will probably land in the next upstream version.
https://github.com/netdata/netdata/pull/8807 as reference
Thanks for the report and proposing a fix. However, the fix tries to mess with libressl internals, so is unsuitable, reasons in a separate comment.
A commit references this bug: Author: mandree Date: Wed Apr 29 22:50:09 UTC 2020 New revision: 533401 URL: https://svnweb.freebsd.org/changeset/ports/533401 Log: net-mgmt/netdata: broken with libressl{,-devel} netdata is trying to move forward with crypto versions, and use TLS v1.3 functions. libressl is outdated and does not offer these, so the proper recourse is marking netdata BROKEN with libressl, rather than weakening its crypto features by enabling a library. FreeBSD 12.1 has two suitable openssl implementations currently, one in the base system (which is also the default), one in ports. PR: 246027 Submitted by: lysfjord.daniel@smokepit.net Changes: head/net-mgmt/netdata/Makefile
It's not like TLS 1.2 is horribly broken or anything, and the fix is from upstream, so they plan on supporting it themselves. Marking it as broken, when the fix comes whenever they merge the PR, is somewhat intuitive?
(In reply to lysfjord.daniel from comment #5) *counterintuitive, not intuitive..
Comment on attachment 213913 [details] libressl-patch from upstream LIBRESSL_INTERNAL does not belong here, and the patch should check technically chedck features of the library, rather than second-guess about what a particular implementation might provide. This issue was also taken upstream, follow Daniel Engberg's URL.
Daniel (Lysfojrd), agreed on the TLS v1.2 account, and I feel some disappointment or astonishment on your part. Technically, the patch is unsound and incurs technical debt for future maintenance, on a port that is technically without maintainer. Details have been reported upstream per Daniel (Engberg)'s reference from comment #2. As soon as a sound patch appears in whatever form (upstream, release, ...), we can consider it, this patch was unsuitable as discussed upstream, and I don't mean to burden the FreeBSD committers group with non-sustainable solutions. For now the sustainable answer remains "use openssl", and that's what the port says. My apologies for using the wrong tag (Submitted...) rather than (Reported...) in my earlier commit. Sorry.