Created attachment 241002 [details] Patch file Update to 8.0.0. ChangeLog: https://curl.se/changes.html#8_0_0 MFH: 2023Q1 Security: 0d7d104c-c6fb-11ed-8a4b-080027f5fec9
It would be great if this could be handled with priority since there are at least 3 old CVEs present and today 4 new were published!
8.0.1 is out https://curl.se/changes.html
Created attachment 241030 [details] Updated patch file Newer version 8.0.1 is released.
Created attachment 241031 [details] Updated patch file Oops, I updated wrong patch.
We have (again) to wait for "maintaner timeout" to update?
+1 for an immediate commit!
I've prepared this update but did not commit it. Some ports assume that curl is version 7 and stop building if curl > 7. I also got a notification from naddy@ about this potential breakage. I guess we need an exp-run to find out such cases.
I have such a build running (thanks to bofh), it'll probably be done within a day and I'll report back on breakage.
Good to know that. Thanks.
net-mgmt/ettercap [ 67% 188/279] /usr/bin/cc -Dsslstrip_EXPORTS -I/usr/local/include/gtk-3.0 -I/usr/local/include/freetype2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/atk-1.0 -I/wrkdirs/usr/ports/net-mgmt/ettercap/work/.build/include -I/wrkdirs/usr/ports/net-mgmt/ettercap/work/ettercap-0.8.3.1/include -I/usr/include/ncurses -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -O2 -w -D_FORTIFY_SOURCE=2 -fPIC -MD -MT plug-ins/CMakeFiles/sslstrip.dir/sslstrip/sslstrip.c.o -MF plug-ins/CMakeFiles/sslstrip.dir/sslstrip/sslstrip.c.o.d -o plug-ins/CMakeFiles/sslstrip.dir/sslstrip/sslstrip.c.o -c /wrkdirs/usr/ports/net-mgmt/ettercap/work/ettercap-0.8.3.1/plug-ins/sslstrip/sslstrip.c FAILED: plug-ins/CMakeFiles/sslstrip.dir/sslstrip/sslstrip.c.o /usr/bin/cc -Dsslstrip_EXPORTS -I/usr/local/include/gtk-3.0 -I/usr/local/include/freetype2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/atk-1.0 -I/wrkdirs/usr/ports/net-mgmt/ettercap/work/.build/include -I/wrkdirs/usr/ports/net-mgmt/ettercap/work/ettercap-0.8.3.1/include -I/usr/include/ncurses -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -O2 -w -D_FORTIFY_SOURCE=2 -fPIC -MD -MT plug-ins/CMakeFiles/sslstrip.dir/sslstrip/sslstrip.c.o -MF plug-ins/CMakeFiles/sslstrip.dir/sslstrip/sslstrip.c.o.d -o plug-ins/CMakeFiles/sslstrip.dir/sslstrip/sslstrip.c.o -c /wrkdirs/usr/ports/net-mgmt/ettercap/work/ettercap-0.8.3.1/plug-ins/sslstrip/sslstrip.c /wrkdirs/usr/ports/net-mgmt/ettercap/work/ettercap-0.8.3.1/plug-ins/sslstrip/sslstrip.c:57:2: error: libcurl 7.26.0 or up is needed #error libcurl 7.26.0 or up is needed ^ 1 error generated. ninja: build stopped: subcommand failed. *** Error code 1 I still have ~100 ports left to build due to circumstances but if someone would like to take a look at ettercap that would be great meanwhile.
math/R: checking if libcurl is version 7 and >= 7.28.0... no configure: error: libcurl >= 7.28.0 library and headers are required with support for https There might be a few others left so fix these two and request a final one
Created attachment 241171 [details] net-mgmt/ettercap: Fix build with cURL 8.0 This patch fixed net-mgmt/ettercap for me.
Created attachment 241172 [details] math/R: Fix build with cURL 8.0 This patch fixed math/R build for me.
The math/R change looks good, but but math/R already has a (very small) configure patch. Could you either integrate your change into the existing patch or let me know that you want me to proceed (I have a local branch with a similar change to the one here).
Created attachment 241189 [details] math/libRmath: patch for cURL 8
Created attachment 241200 [details] math/libRmath: patch for cURL 8 Bring this patch more in line with the one for math/R.
+1 for the priority -- large stack of vulnerabilities affecting 7.88.1 . Only: why so many changes in this patch? I could bump the port by only changing PORTVERSION to "8.0.1" (see my duplicate @ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270578 ).
*** Bug 270578 has been marked as a duplicate of this bug. ***
Hi Antoine, Can you do an exp-run with the attached patches applied? Best regards, Daniel
Exp-run looks fine for ports that explicitely depend on ftp/curl I don't know if it's worth testing ports that indirectly depend on it
curl was just updated in 0799d457b1becdc3c05f1b0070c31389100fd2c2 (with no mention of this PR). Shall we close?
I'm new (too FreeBSD using bugzilla) so please go gentle. I'm confused. This issue took a lot of posts (and a lot of work). Surely upgrading Curl should have been a simple case. If other packages got broke as a result of the 7->8 increase then those package should have had their own issues raised and therefore dealt with. With these CVE's out there and with so many could this not have been done quicker? Personally I think even doing exp-runs went as far beyond duty as it should have. Actually going to the trouble of creating patches for other packages, while nice and helpful, was going a bit far. Or rather I mean holding Curl-8.0.1 back till those were complete and tested, was going a bit far. If there is a bona fide reason, educate me. curl CVE's have been fast a furious recently and the biggest reason for doing port upgrades. To have systems monitoring alerting daily for months and unable to get them updated to the point of securely patched, it just seems a lot of these posts could (or should) have been offloaded to the other packages. No?
Guidelines in Porters Handbook are respected and covers most common scenarios, see https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-maintainer for more information. You preferably don't blindly update a library that a large number of ports depends on because no one likes breakage at the end of the day. While one library doesn't sound that bad initially keep in mind that we have a lot more than just one in our tree and imagine if we used this approach this for all... If you want to have further discussion about this topic I'd suggest that you use the FreeBSD ports mailinglist. Best regards, Daniel
(In reply to Joseph Mingrone from comment #21) > Shall we close? I guess this should be MFH... 2023Q2 has been tagged last week and I don't think it could stay vulnerable for three months... I'm building my ports with this cherry-picked, but that's by no means a complete exp-run.
like @ml said, any chance to push this to 2023Q2 considering the CVEs? Thanks very much!
(In reply to Alex from comment #25) I second this!
In fact, that's an accident to commit curl 8.0.1. As I said before, I've prepared the update already. But I forgot to remove it from my script. Anyway, I've merged the update and 3 fixes (R, libRmath and ettercap) to 2023Q2 branch. Thank you all.