I'd like to request an exp-build with WITH_OPENSSL_PORT=yes and SSLv2/SSLv3 disabled so we will know what would be broken when we flip the default.
Can you provide a make.conf for this exp-run? Also, this will not catch ports that use openssl but don't set USE_OPENSSL in their Makefile, is it needed to patch base?
Created attachment 150347 [details] ports linking against libssl.so.7 on 10.1 amd64
Created attachment 150348 [details] ports linking against libcrypto.so.7 on 10.1 amd64
So here is my proposal for the exp-run: in make.conf: WITH_OPENSSL_PORT=yes security_openssl_UNSET=SSL2 poudriere bulk -qat, then report: - new failures - ports linking against libssl.so.7/libcrypto.so.7 (base) when they should link against libssl.so.8/libcrypto.so.8 (ports) Does that sound ok?
(In reply to Antoine Brodin from comment #4) > So here is my proposal for the exp-run: > > in make.conf: > > WITH_OPENSSL_PORT=yes > security_openssl_UNSET=SSL2 > > poudriere bulk -qat, then report: > - new failures > - ports linking against libssl.so.7/libcrypto.so.7 (base) when they should > link against libssl.so.8/libcrypto.so.8 (ports) > > Does that sound ok? Yes that sounds good and thanks for working on this!
Take for exp-run
(In reply to Antoine Brodin from comment #2) > Created attachment 150347 [details] > ports linking against libssl.so.7 on 10.1 amd64 Is is possible to sort this by when the port listed was last updated in either ascending or descending order? Thanks for the work on this!
(In reply to Antoine Brodin from comment #4) > So here is my proposal for the exp-run: > > in make.conf: > > WITH_OPENSSL_PORT=yes > security_openssl_UNSET=SSL2 > > poudriere bulk -qat, then report: > - new failures > - ports linking against libssl.so.7/libcrypto.so.7 (base) when they should > link against libssl.so.8/libcrypto.so.8 (ports) > > Does that sound ok? What's it mean when both lists have the same port? Example: -devel/git -databases/postgresql94-server -ftp/curl Thanks for the efforts put into this!
New failures, either due to using openssl from ports or disabling SSLv2: + {"origin"=>"audio/libcoverart", "pkgname"=>"libcoverart-1.0.0_3", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"audio/libmusicbrainz3", "pkgname"=>"libmusicbrainz3-3.0.3_3", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"audio/libmusicbrainz5", "pkgname"=>"libmusicbrainz5-5.0.1", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"databases/mariadb100-client", "pkgname"=>"mariadb100-client-10.0.14", "phase"=>"configure", "errortype"=>"???"} + {"origin"=>"databases/mariadb55-client", "pkgname"=>"mariadb55-client-5.5.40", "phase"=>"configure", "errortype"=>"???"} + {"origin"=>"deskutils/mirall", "pkgname"=>"mirall-1.6.3", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"devel/mico", "pkgname"=>"mico-2.3.13", "phase"=>"package", "errortype"=>"compiler_error"} + {"origin"=>"devel/subversion16", "pkgname"=>"subversion16-1.6.23_8", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"devel/subversion17", "pkgname"=>"subversion17-1.7.18", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"editors/p5-Padre", "pkgname"=>"p5-Padre-1.00_2", "phase"=>"stage-qa", "errortype"=>"stage"} + {"origin"=>"ftp/pavuk", "pkgname"=>"pavuk-0.9.35_4", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"games/live-f1", "pkgname"=>"live-f1-0.2.11_1", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"mail/courier", "pkgname"=>"courier-0.65.3_3", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"mail/heirloom-mailx", "pkgname"=>"heirloom-mailx-12.4_6", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"mail/qpopper", "pkgname"=>"qpopper-4.1.0_3", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"mail/wmmaiload", "pkgname"=>"wmmaiload-2.2.1_4", "phase"=>"stage", "errortype"=>"linker_error"} + {"origin"=>"net-mgmt/xymon-server", "pkgname"=>"xymon-server-4.3.17_4", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"net/easysoap", "pkgname"=>"easysoap-0.8.0_5", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"net/gq", "pkgname"=>"gq-1.3.4_11,1", "phase"=>"build", "errortype"=>"missing_LDFLAGS"} + {"origin"=>"net/pen", "pkgname"=>"pen-0.18.0", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"security/nessus", "pkgname"=>"nessus-2.2.9_3", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"security/openvas-client", "pkgname"=>"openvas-client-2.0.4_4", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"security/p5-openxpki", "pkgname"=>"p5-openxpki-0.25.0.1", "phase"=>"build-depends", "errortype"=>"???"} + {"origin"=>"security/qca-ossl", "pkgname"=>"qca-ossl-2.0.0.b3_4", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"security/sst", "pkgname"=>"sst-1.0_1", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"sysutils/nut", "pkgname"=>"nut-2.7.2_6", "phase"=>"package", "errortype"=>"termios"} + {"origin"=>"www/cadaver", "pkgname"=>"cadaver-0.23.3_2", "phase"=>"build", "errortype"=>"missing_header"} + {"origin"=>"www/libwww", "pkgname"=>"libwww-5.4.0_5", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"www/sitecopy", "pkgname"=>"sitecopy-0.16.6_3", "phase"=>"configure", "errortype"=>"configure_error"} + {"origin"=>"www/webstone-ssl", "pkgname"=>"webstone-ssl-2.5", "phase"=>"build", "errortype"=>"linker_error"} Failure logs: http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/libcoverart-1.0.0_3.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/libmusicbrainz3-3.0.3_3.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/libmusicbrainz5-5.0.1.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/mariadb100-client-10.0.14.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/mariadb55-client-5.5.40.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/mirall-1.6.3.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/mico-2.3.13.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/subversion16-1.6.23_8.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/subversion17-1.7.18.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/pavuk-0.9.35_4.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/live-f1-0.2.11_1.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/courier-0.65.3_3.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/heirloom-mailx-12.4_6.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/qpopper-4.1.0_3.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/wmmaiload-2.2.1_4.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/xymon-server-4.3.17_4.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/easysoap-0.8.0_5.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/gq-1.3.4_11,1.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/pen-0.18.0.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/nessus-2.2.9_3.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/openvas-client-2.0.4_4.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/qca-ossl-2.0.0.b3_4.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/sst-1.0_1.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/nut-2.7.2_6.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/cadaver-0.23.3_2.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/libwww-5.4.0_5.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/sitecopy-0.16.6_3.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/errors/webstone-ssl-2.5.log Note: www/neon29 doesn't fail to build (success log at http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/neon29-0.29.6_6.log ) but it seems unusable, all ports trying to link against it fail; net/mpd5 and security/py-pow are probably broken at runtime too (implicit declaration of function 'SSLv2* warnings): http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/py27-pow-0.7.log http://package18.nyi.freebsd.org/data/101amd64-default-PR195796/2014-12-12_06h28m13s/logs/mpd5-5.7_1.log More than 100 ports link against libssl.so.7 (base) when WITH_OPENSSL_PORT=yes, I will try to do a list. For libcrypto.so.7 it's worse, more than 200.
Created attachment 150559 [details] ports linking against libssl.so.7 despite WITH_OPENSSL_PORT=yes
Assign back to reporter, a list of ports broken with SSLv2 disabled and a list of ports linking against base libssl despite WITH_OPENSSL_PORT=yes have been provided.
I've submiited a PR to fix mail/heirloom-mailx : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196082 Thanks to jungleboogie0@gmail.com for the heads up! cheers, Jamie
Incidentally, I'm glad you're looking at the issue of ports that use openssl, but don't use the ports cersion if it's installed. I raised the issue back in April, but no-one seemed too bothered.. https://lists.freebsd.org/pipermail/freebsd-security/2014-April/007648.html
https://lists.freebsd.org/pipermail/freebsd-security/2014-April/007643.html even!
I've submitted a patch for databases/mariadb100-server and -client for which I'm the maintainer. Fixes build with bundled/base/port SSL https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196122
I've submitted a patch for databases/mariadb55-server. Fixes build with bundled/base/port SSL. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196125
I'm not sure if you're tracking depenencies too, but there python27 fails. www/youtube-dl fails with: 7:14 [2] (1) "/tmp" root@catflap# youtube-dl Traceback (most recent call last): File "/usr/local/lib/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/local/lib/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/local/bin/youtube-dl/__main__.py", line 15, in <module> File "/usr/local/bin/youtube-dl/youtube_dl/__init__.py", line 86, in <module> File "/usr/local/bin/youtube-dl/youtube_dl/utils.py", line 22, in <module> File "/usr/local/lib/python2.7/ssl.py", line 60, in <module> import _ssl # if we can't import it, let the error propagate ImportError: /usr/local/lib/python2.7/lib-dynload/_ssl.so: Undefined symbol "SSLv2_method" Recompiling lang/python27 fixes this, without any changes required.
www/neon29 was renamed to www/neon and all affected ports were updated: https://reviews.freebsd.org/D1319#dbd2e955 https://secure.freshbsd.org/commit/freebsd-ports/r375392 https://www.freshports.org/www/neon This means ports like audio/libmusicbrainz5 should compile without issues.
The last update to neon-0.30.1 (r375392) contains some fixes in src/ne_openssl.c to handle OpenSSL without SSL2 support.
A commit references this bug: Author: feld Date: Wed Dec 31 20:18:27 UTC 2014 New revision: 375911 URL: https://svnweb.freebsd.org/changeset/ports/375911 Log: Permit building against OpenSSL without SSLv2 support PR: 195796 Submitted by: lifanov@mail.lifanov.com Changes: head/net-mgmt/xymon-server/Makefile head/net-mgmt/xymon-server/files/Makefile
www/sitecopy has been updated: https://svnweb.freebsd.org/ports/head/www/sitecopy/Makefile?view=log
A commit references this bug: Author: tijl Date: Thu Jan 15 09:05:53 UTC 2015 New revision: 377064 URL: https://svnweb.freebsd.org/changeset/ports/377064 Log: Add missing USE_OPENSSL=yes PR: 195796 Changes: head/audio/baresip/Makefile head/audio/libshairport/Makefile head/audio/opusfile/Makefile head/audio/re/Makefile head/audio/rem/Makefile head/benchmarks/sipp/Makefile head/benchmarks/wrk/Makefile head/chinese/bitchx/Makefile head/comms/conserver-com/Makefile head/databases/libdrizzle-redux/Makefile head/databases/virtuoso/Makefile head/devel/fossil/Makefile head/devel/ice/Makefile head/devel/libmonetra/Makefile head/devel/libmowgli2/Makefile head/devel/pecl-mcve/Makefile head/devel/poco-devel/Makefile head/devel/poco-ssl/Makefile head/devel/ucommon/Makefile head/ftp/tnftp/Makefile head/games/tinymux/Makefile head/irc/bitchx/Makefile head/irc/charybdis/Makefile head/irc/eggdrop-devel/Makefile head/irc/ircd-ratbox/Makefile head/irc/psybnc/Makefile head/irc/xaric/Makefile head/lang/mosh/Makefile head/lang/rubinius/Makefile head/mail/archiveopteryx/Makefile head/mail/archiveopteryx-devel/Makefile head/mail/filtermail/Makefile head/mail/gbuffy/Makefile head/mail/libesmtp/Makefile head/mail/nbsmtp/Makefile head/mail/prayer/Makefile head/mail/spamdyke/Makefile head/multimedia/asdcplib/Makefile head/net/bsdec2-image-upload/Makefile head/net/crtmpserver/Makefile head/net/hostapd/Makefile head/net/httping/Makefile head/net/kamailio/Makefile head/net/l4ip/Makefile head/net/libarms/Makefile head/net/libexosip2/Makefile head/net/miniupnpd/Makefile head/net/p5-Net-TCLink/Makefile head/net/p5-Socket-Class/Makefile head/net/relayd/Makefile head/net/ssltunnel-client/Makefile head/net/ssltunnel-server/Makefile head/net/ssvnc/Makefile head/net/svnup/Makefile head/net/tinyfugue/Makefile head/net/xrdp/Makefile head/net-im/sigram/Makefile head/net-mgmt/icinga/Makefile head/net-mgmt/kismet/Makefile head/net-mgmt/monitoring-plugins/Makefile head/net-mgmt/nagios-check_bacula/Makefile head/net-mgmt/nagios-plugins/Makefile head/net-mgmt/nagircbot/Makefile head/net-mgmt/sysmon/Makefile head/net-p2p/dclib/Makefile head/security/duo/Makefile head/security/hs-HsOpenSSL/Makefile head/security/john/Makefile head/security/ncrack/Makefile head/security/nessus-libnasl/Makefile head/security/openca-tools-forked/Makefile head/security/osiris/Makefile head/security/ossec-hids-client/Makefile head/security/ossec-hids-local/Makefile head/security/ossec-hids-server/Makefile head/security/pev/Makefile head/security/proxytunnel/Makefile head/security/skipfish/Makefile head/security/sslscan/Makefile head/security/starttls/Makefile head/security/stunnel/Makefile head/sysutils/bacula-bat/Makefile head/sysutils/bacula-client/Makefile head/sysutils/bacula-client-static/Makefile head/sysutils/bacula-server/Makefile head/sysutils/monit/Makefile head/sysutils/syslog-ng/Makefile head/sysutils/syslog-ng-devel/Makefile head/sysutils/syslog-ng33/Makefile head/sysutils/syslog-ng34/Makefile head/sysutils/syslog-ng35/Makefile head/sysutils/tlsdate/Makefile head/textproc/exmpp/Makefile head/textproc/htdig/Makefile head/www/blastbeat/Makefile head/www/httrack/Makefile head/www/mini_httpd/Makefile head/www/mini_httpd/files/patch-Makefile head/www/nostromo/Makefile head/www/tengine/Makefile head/www/tntnet/Makefile head/www/xshttpd/Makefile
Can we get another exp-run? It's been a month since the last one and I think most of the problems from the previous run have been fixed now. mail/courier still needs to be fixed by updating the port to the latest version. I contacted the maintainer but since he hasn't kept the port up to date in years to the point that the current version no longer fetches, I don't expect any response. His other ports are also out of date so I think it's best to reset maintainer on them. Maybe oliver@ would be interested in mail/courier since he already maintains other courier related ports.
Hi, Could we get more details about: 1) the goal of the exp-run Is it to test whether ports build with SSLv2 disabled? Is it to test whether ports build with SSLv3 disabled (1st exp-run had SSLv3 enabled) Is it to test whether ports build with openssl from ports? 2) the plan Currently, libfetch links against libssl from base ; pkg needs libssl from base too (chicken/egg problem). Other libraries like libarchive or the kerberos libs link against libcrypto from base. What is the plan for all this?
I haven't looked into upstream OpenSSL current, but I suspect SSLv2 support was already dropped. http://rt.openssl.org/Ticket/Display.html?id=3625&user=guest&pass=guest In this case the original request from Xin LI really makes sense to do an exp-run with OpenSSL from ports before ripping SSLv2/SSLv3 support from the next FreeBSD release.
(In reply to Olli Hauer from comment #25) If the only goal is to check whether ports build with SSLv2/SSLv3 disabled, this should be done with: - base patched to disable SSLv2/SSLv3 support - security/openssl port with SSLv2 and SSLv3 option disabled
I heard that WITH_OPENSSL_PORT is to become the default, e.g. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196247#c4 I assume the reason for that is to move libssl and libcrypto to /usr/lib/private. Other libraries that link to libssl or libcrypto (e.g. libfetch, libarchive,...) will also have to be moved there. Since this will only be the case for FreeBSD 11 and older FreeBSD versions will still have libssl, libcrypto, libarchive,... in /usr/lib, I think the goal of this exp-run should be to detect ports that link with these libraries instead of the ports versions (perhaps by making this a stage-qa error?). The removal of SSL2 and SSL3 (and perhaps also MD2?) from OPTIONS_DEFAULT in security/openssl/Makefile is something that also needs to happen (sooner rather than later imho) so it has been added to this exp-run but it's a separate issue. Can someone from (ports-)secteam can confirm this?
libarchive pkgconfig file is now installed in head, while it wasn't installed on 10.1, so I doesn't seem that the goal is to move it to libprivate For future exp-run related to openssl: 1) If it's related to algorithms to disable, please provide a patch for both base + make.conf/patch for the openssl port 2) If it's related to WITH_OPENSSL_PORT=yes, a prerequisite is that the libfetch/libarchive/libkerberos*/pkg situation is clarified and handled 3) I will not exp-run 1) and 2) at the same time, they have to be tested separately
waiting for a patch and some explanations before another exp-run
Added bug #198330 : graphics/openimageio missing dependency on OpenSSL (from ports)
Just spotted that I have already created some patches fixing this in my GitHub repo https://github.com/Sp1l/ports most were found during a build of all ports with LibreSSL by PC-BSD ftp/pavuk (net-mgmt/xymon-server) net/gq security/nessus (lib-nessus and nasl) security/p5-openxpki www/webstone-ssl I will try and clean these patches, prep for a proper patch and upstream them. Will need some time, the build uncovered a pretty hefty number of failures though on a relative level it wasn't all that much!
Added bug# 198333 for ftp/pavuk fixing Without-SSLv2 and replacing deprecated des_ methods and types with the (not so) new (2007) DES_ variants.
Added bug #198399 to fix SSLv2/SSLv3 for mail/courier
feel free to mark #193482 a see-also instead of a depends-on.
Probably 191919 should also be added here... There's more goodies in https://wiki.freebsd.org/LibreSSL and https://wiki.freebsd.org/OpenSSL security/nessus-libraries fixed by bug #198992 security/sslscan fixed by bug #198401 security/sslwrap fixed by bug #198400 www/webstone-ssl fixed by bug #199019
Some other PR's also related to the lists. These are LibreSSL related but since LibreSSL does not have SSLv2 support at all these fix the no-sslv2 issues as well. databases/virtuoso bug #198368 devel/ice bug #198781 irc/charybdis bug #198504 irc/ircd-ratbox bug #198506 security/john bug #198348 security/stunnel bug #198997
Just opened bug #199377 against emulators/virtualbox-ose which is listed in ports linking against libssl.so.7 despite WITH_OPENSSL_PORT=yes
Created attachment 155480 [details] svn diff for misc/smssend and sysutils/ucspi-ssl Just checked the list "ports linking against libssl.so.7 despite WITH_OPENSSL_PORT=yes" against the ports and found 2 that are missing a USE_OPENSSL misc/smssend sysutils/ucspi-ssl
Several PRs were added for ports linking to base OpenSSL when ports' is specified bug #199390 net/miniupnpd bug #199389 systutils/ipmitool
*** Bug 193482 has been marked as a duplicate of this bug. ***
Patch for comms/kermit updated to allow building without SSLv3 https://bugs.freebsd.org/198980
https://reviews.freebsd.org/D4843 fixes net/svnup
https://reviews.freebsd.org/D5286 fixes irc/ircd-ratbox
A commit references this bug: Author: brnrd Date: Mon Feb 15 19:19:25 UTC 2016 New revision: 408952 URL: https://svnweb.freebsd.org/changeset/ports/408952 Log: irc/ircd-ratbox: Fix OpenSSL linking and simplify - Fix linking with ports' ssl libs - Fix `contrib` build (used base openssl headers) - Re-work EGD detection - Use options helpers - Simplify REINPLACE with :U defaults PR: 195796 Reviewed by: feld (mentor) Approved by: feld (mentor) Differential Revision: D5286 Changes: head/irc/ircd-ratbox/Makefile head/irc/ircd-ratbox/files/patch-configure head/irc/ircd-ratbox/files/patch-configure.ac head/irc/ircd-ratbox/files/patch-contrib_Makefile.in head/irc/ircd-ratbox/files/patch-libratbox_src_openssl.c
A commit references this bug: Author: feld Date: Wed Mar 2 22:31:30 UTC 2016 New revision: 409967 URL: https://svnweb.freebsd.org/changeset/ports/409967 Log: security/openssl: Disable SSLv2 and MD2 SSLv2 is being disabled due to DROWN. MD2 is being disabled as it should not have been enabled by default. This was disabled by upstream back in 2009. PR: 195796 Approved by: delphij, eadler Security: CVE-2009-2409 Security: CVE-2016-0800 Changes: head/security/openssl/Makefile
A commit references this bug: Author: feld Date: Wed Mar 2 22:33:32 UTC 2016 New revision: 409968 URL: https://svnweb.freebsd.org/changeset/ports/409968 Log: MFH: r409967 security/openssl: Disable SSLv2 and MD2 SSLv2 is being disabled due to DROWN. MD2 is being disabled as it should not have been enabled by default. This was disabled by upstream back in 2009. PR: 195796 Approved by: delphij, eadler Security: CVE-2009-2409 Security: CVE-2016-0800 Approved by: ports-secteam (with hat) Changes: _U branches/2016Q1/ branches/2016Q1/security/openssl/Makefile
I see some problems with this commit. The API/ABI of libssl was changed, but there was no shared lib version bump. The packages that depends on libssl from ports did not received a PORTRVISION bump. If the user updates via pkg upgrade, some packages mitght be broken. was this tested? grep openssl-1.0.2 /usr/ports/INDEX-10 | cut -d '|' -f2
(In reply to Dirk Meyer from comment #47) I am seeing this being echoed elsewhere on the internet. Everyone seems to be running into this same problem. The "upgrade" scenario was not part of the test coverage. We have done exp-runs with SSLv2 and SSLv3 disabled to weed out the problem ports, but not "build against previous openssl, upgrade openssl, test". If we just bump PORTREVISION we only fix those specific ports. If someone out there runs their own package server and intentionally build everything against ports' OpenSSL they will still end up with a very broken system. We need to find an amenable way to solve this. I do not know if the Security Officer is aware of this breakage either. If an SA is issued and people upgrade and receive a patched OpenSSL with SSLv2 removed they will also find breakage. I don't currently know how this can be avoided, as the base system OpenSSL is not supposed to have these kinds of changes. I am going to revert this change for the moment and I will be away for a couple days. When an amenable solution is found I think we should take Tijl's advice and also mark these port options as FORBIDDEN as well as disable ZLIB by default, which provides opportunity for the CRIME attack. I do not believe ZLIB or MD2 should cause breakage in the same way TLSv2 being disabled does, but I am not willing to bet my wallet on it at this point.
A commit references this bug: Author: feld Date: Thu Mar 3 13:58:50 UTC 2016 New revision: 410039 URL: https://svnweb.freebsd.org/changeset/ports/410039 Log: security/openssl: Revert disabling of SSLv2 and MD2 Disabling SSLv2 without a shared library bump has a visible impact to some applications. It is unclear at this time if disabling MD2 could cause the same issues, but both are being reverted at the moment to be safe. PR: 195796 Changes: head/security/openssl/Makefile
A commit references this bug: Author: feld Date: Thu Mar 3 13:59:34 UTC 2016 New revision: 410040 URL: https://svnweb.freebsd.org/changeset/ports/410040 Log: MFH: r410039 security/openssl: Revert disabling of SSLv2 and MD2 Disabling SSLv2 without a shared library bump has a visible impact to some applications. It is unclear at this time if disabling MD2 could cause the same issues, but both are being reverted at the moment to be safe. PR: 195796 Approved by: ports-secteam (with hat) Changes: _U branches/2016Q1/ branches/2016Q1/security/openssl/Makefile
(In reply to Dirk Meyer from comment #47) How can we re-approach this? Should we do it again but include PORTREVISION bumps for all the dependent packages? I hate that there wasn't a shared library bump...
Yes, bump all ports that have USE_OPENSSL=yes, or foo_USE=openssl=yes, even if optional. And then, maybe check all the generated packages for dependency on some of the libraries OpenSSL provides. In case a port forgot to say it needed it. And maybe check that it really works after an upgrade :-)
And then, add a really big warning in UPDATING, and an howtofixyourownrepo
IMHO our job as packagers is to ship what upstream delivers. Our own development should be kept to a minimum. Upstream installs with .so.1 (and .so.1.0.0) so that is what we should do too. Bumping the library version is important when existing functions change, but here existing functions were simply removed. Most applications won't be using these functions and will happily continue to work without version bump but need to be rebuild with version bump. Applications that do use these functions will always fail whether you bump the version or not. So if you ask me we should change the openssl port so it installs .so.1 and .so.1.0.0 and a .so.8 symlink to .so.1.0.0 so existing binaries can find the library without rebuilding. This .so.8 symlink should exist for a year or so.
(In reply to Tijl Coosemans from comment #54) I agree, but the problem is possibly a design flaw in OpenSSL: if software was built against OpenSSL and it included support for SSLv2, removing it from OpenSSL is not a no-op. The software will expect functionality to be there and segfault; it doesn't fail gracefully. This makes it very hard to touch OpenSSL to harden the defaults without breaking things for users.
(In reply to Mark Felder from comment #55) As I understand the API (and that's a limited understanding) applications are supposed to use the SSLv23_* functions which negotiate the best SSL or TLS version between a client and a server. Applications can force a specific version by using one of the SSLv2_*, SSLv3_* or TLSv* functions. These are typically only used when applications allow users to configure a specific version. It's the SSLv2_* functions which have been removed. Applications which use these functions will simply fail to start because rtld cannot resolve the symbols. There are no segfaults. But even if there are segfaults that's either an upstream problem or an application problem (because it doesn't adequately check for support at runtime), and not our problem. Our trying to cover up the mess by forcing everything to be rebuilt will only allow either upstream or application developers to continue to be lazy about fixing it properly.
(In reply to Tijl Coosemans from comment #54) We must not follow upstream here as long OpenSSL is in base. The port allows Users to switch gratefully to the new version. To allow this work the soversion must higher than base, and should not match upstream. Please do not break this feature!
(In reply to Tijl Coosemans from comment #56) You do not understand the problems involved, of cause there are segfaults, mainly 2 reasons: Some are caused by changed internal structures, and the sizes uses in binaries does not match. The others are caused because rtld can find this missing symbols in the base opessl libs, which leads to a mix of old and new functions.
As a maintainer, I would like this issue closed. We do not gain anything by breaking the ABBI multiple times. Lets do only one API/ABI change when the new OpenSSL version is out.
(In reply to Dirk Meyer from comment #59) You're right, a lot of these problems are simply solved with OpenSSL 1.1.0. They appear to intend to release it on April 28th. https://www.openssl.org/policies/releasestrat.html This is only ~6 weeks away. I think that is a wise strategy.
(In reply to Dirk Meyer from comment #58) > The port allows Users to switch gratefully to the new version. > To allow this work the soversion must higher than base, > and should not match upstream. Soversion doesn't have to be higher at all. Just try this in an empty directory: touch ssl.c cc -shared -o libssl.so.0 -Wl,-soname=libssl.so.0 ssl.c ln -s libssl.so.0 libssl.so echo 'int main(void) { return 0; }' > test.c cc -o test test.c -L. -lssl objdump -p test | grep NEEDED The test executable will need libssl.so.0 and not base libssl.so.8. > Some are caused by changed internal structures, > and the sizes uses in binaries does not match. Can you show me such a struct because both NO_SSL2 and NO_MD2 only affect function declarations in /usr/local/include/openssl as far as I can see. > The others are caused because rtld can find this missing symbols > in the base opessl libs, which leads to a mix of old and new functions. If a process links in a second version of libssl or libcrypto via a dependency we want to know about that because then something is obviously very wrong. It's very likely that the dependency is missing USE_OPENSSL. This is not supposed to be supported. (In reply to Mark Felder from comment #60) > This is only ~6 weeks away. I think that is a wise strategy. So you want to ship the openssl package in a known to be vulnerable state and let all ports compiled against it potentially use SSLv2 because they detect support for it. What about the quarterly branches?
(In reply to Tijl Coosemans from comment #61) No, I just don't want broken systems and I don't know of a way around it without having to do an insane amount of work in the ports tree and hoping nothing was missed. We aren't the only ones debating this. The most detailed info about the breakage is in the Gentoo bug report on this same issue: https://bugs.gentoo.org/show_bug.cgi?id=576128
(In reply to Tijl Coosemans from comment #61) The openssl port has all vulnerabilities fixed. The openssl-devel ports has unfixed vulnerabilities.
I believe all SSLv2/SSLv3 issues have been fixed.
(In reply to Bernard Spil from comment #64) That's how I close here. If there are any problems, please reopen.