Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On 12/14/20 4:37 PM, Konstantin Belousov wrote: > On Mon, Dec 14, 2020 at 11:44:27AM -0800, John Baldwin wrote: >> If we import 3.0.0 into, say, 13.2, then when 13.0/13.1 are EOLd we are >> no longer having to maintain 1.1.1 in 13. If people want to keep older >> applications built on unsupported releases still working without >> recompiling, etc. they will have to manage that themselves. Currently >> we don't support 12.0 on the 12.x branch for example. > What do you mean by 'not supported'? Don't we put large efforts into > keeping ABI backward compatible to allow to run _any_ binary built early ? > The only exception I can think of is that we allow ABI mistakes on HEAD > to be fixed in non-backward compatible way. > > But for 12.0-built binaries, we offer full support. In fact it is the easiest > case, if comparing e.g. with binaries built against older branches. > > It is possible to bump dso version on stable branch, which I believe was > already done several times. In this case, we provided compatXx- > for stable/X branch, which contiained shared objects with previous versions. So to be clear, my suggestion was precisely to bump the shared library and ship the 1.1.1 libraries in misc/compat13 packages, and while yes, binaries would still work (so be supported in that sense), they would not be supported in the sense of getting SA backports for bugs in the old libssl they are linked against. The cases that suck is if due to library dependencies a process pulls in both libssl.so.X verisons in the same binary. We could use symbol versioning to at least ensure a given DSO always gets the symbols it linked against, but it wouldn't solve the problem of a library returning a SSL * handle to another DSO that is linked against the other version. I do think though that sort of cross-threading is perhaps rarer with libssl than it would be with, say, libc where the malloc/free cross-threading is very common and breaks horribly. -- John Baldwin ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Mon, Dec 14, 2020 at 11:44:27AM -0800, John Baldwin wrote: > If we import 3.0.0 into, say, 13.2, then when 13.0/13.1 are EOLd we are > no longer having to maintain 1.1.1 in 13. If people want to keep older > applications built on unsupported releases still working without > recompiling, etc. they will have to manage that themselves. Currently > we don't support 12.0 on the 12.x branch for example. What do you mean by 'not supported'? Don't we put large efforts into keeping ABI backward compatible to allow to run _any_ binary built early ? The only exception I can think of is that we allow ABI mistakes on HEAD to be fixed in non-backward compatible way. But for 12.0-built binaries, we offer full support. In fact it is the easiest case, if comparing e.g. with binaries built against older branches. It is possible to bump dso version on stable branch, which I believe was already done several times. In this case, we provided compatXx- for stable/X branch, which contiained shared objects with previous versions. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
As a party with a vested interest in FIPS, you can guess were I stand on replacing OpenSSL with some other crypto engine in FreeBSD. ;) We are currently building FreeBSD 11.4 against a copy of the latest OpenSSL 1.0.2 release by diverting the build to a separate part of our source tree in secure/lib/Makefile. This has been working quite well for us. We'll see what happens with our ongoing 12.2 upgrade. Not really the point of this email though. Regarding /dev/crypto: > Also, when I have tested it with actual offload hardware, it doesn't > really compete with native AES instructions on the CPU running in > userland. Here you're really comparing two hardware accelerators, one with extra kernel overhead, so it's not really fair. Have you compared RSA or EC signing and verifying between libcrypto and /dev/crypto? This would give you a better idea of /dev/crypto performance improvement. (I'll say that /dev/crypto is not really of interest to me professionally, because FIPS) > KTLS does help because you can use sendfile, but > /dev/crypto is not a win in my testing. I had to make additional > changes to teach the engine in 1.0.2 to use AES-GCM with the > extensions needed for TLS as well as wire the user buffers to avoid > copies, and with that I got a hardware co-processor to break even > with AES-NI in userland in terms of both throughput and CPU usage > for HTTPS. sendfile-enabled KTLS, OTOH, is able to achieve > significantly higher throughput. I don't know anything about KTLS - is that using OpenSSL for it's crypto? If so, can it load a FIPS canister/provider? If not, then FIPS may be an issue for us (and other commercial users of FreeBSD), I hope it's something we can disable... Is there some documentation about this someone can point me to? - Steve Wall ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On 12/12/20 4:57 PM, John-Mark Gurney wrote: > John Baldwin wrote this message on Sat, Dec 12, 2020 at 11:40 -0800: >> On 12/10/20 10:46 PM, John-Mark Gurney wrote: >>> I have not heard if OpenSSL has bother to address the breakage of >>> /dev/crypto that also recently came up, but it does appear that they >>> are no longer a good fit for FreeBSD. >> >> I think I can't disagree more. In terms of /dev/crypto, see here: >> >> https://github.com/openssl/openssl/pull/13468 > > I went back to the original PR that rewrote /dev/crypto: > https://github.com/openssl/openssl/pull/3744 > > The PR was submitted in June 2017, and they tested on FreeBSD 8.4-R, > which had support end on June 2015. Even back in 2017, it was easy > enough w/ VMs and cloud compute to spin up a modern, supported > FreeBSD box. > > Yes, it's good that it's now getting fixed, 3 years after it was broken. > > If FreeBSD is going to continue to use OpenSSL, better testing needs to > be done to figure out such breakage earliers, and how to not have them > go undetected for so long. At some point the onus is also on FreeBSD to keep things working as well. In practice, our kernel crypto interface is pretty crappy (hopefully less crappy in 13, but there is still room for improvement). Also, when I have tested it with actual offload hardware, it doesn't really compete with native AES instructions on the CPU running in userland. KTLS does help because you can use sendfile, but /dev/crypto is not a win in my testing. I had to make additional changes to teach the engine in 1.0.2 to use AES-GCM with the extensions needed for TLS as well as wire the user buffers to avoid copies, and with that I got a hardware co-processor to break even in with AES-NI in userland in terms of both throughput and CPU usage for HTTPS. sendfile-enabled KTLS, OTOH, is able to achieve significantly higher throughput. >> Also, OpenSSL has been perfectly fine to work with in terms of >> upstreaming KTLS. kaduk@ is an OpenSSL committer and has been >> helpful with helping me find reviewers for patches when needed >> as well. >> >> In terms of OpenSSL vs other SSL libraries, I'll defer to this: >> >> https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html > > I'll note that this article is more for a developer than the maintainer > of an OS. When FreeBSD has 5 year support cycles, things are slightly > different, otherwise I agree that the article is good advice (from my > brief reading/looking over). While it's true it is tailored for a developer, I think it is still relevant in its discussion of alternative SSL library implementations. I agree with Gordon's assessment that there aren't really other viable alternatives. >>> Even as it stands, FreeBSD has committed to supporting 12 for close >>> to a year longer than OpenSSL has for 1.1.1 meaning we will be in the >>> same situation we are w/ 11 in a few years. >>> >>> Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation >>> than we are now. OpenSSL 3.0.0 has no support commitment announced >>> yet, and sticking with 1.1.1 for 13 will put us even in a worse >>> situation than we are today. >>> >>> What are peoples thoughts on how to address the support mismatch between >>> FreeBSD and OpenSSL? And how to address it? >> >> I do think the support mismatch questions are still real, and I'm not >> sure what the best answer is. My guess is that the the delay of >> 3.0.0 (which I had hoped would ship in 13.0) will mean that 1.1.1's >> lifetime will get extended, but probably not enough to cover 13.x >> for 5 years. One option may be that we provide a compat openssl for >> 13.x that is 1.1.1 for things built on the head of the branch but >> actually import OpenSSL 3.0.0 into stable/13 at some point. You could >> do this with a shlib major version bump. It won't solve all problems >> if some shared library linked against 1.1.1 returns some object >> allocated by libssl that the application tries to use directly (and >> the application is linked against 3.0.0), but I'm not sure how common >> that situation will be in practice. OpenSSL isn't libc where you have >> issues with malloc/free crossing this sort of boundary. > > In the case of mixed 1.1.1 and 3.0.0, that should just be disallowed. > > Though importing 3.0.0 doesn't solve the issue if 1.1.1 has a security > problem... Because the security problem in 1.1.1 will still need to be > addressed to deal w/ all the applications that are linked against it.. If we import 3.0.0 into, say, 13.2, then when 13.0/13.1 are EOLd we are no longer having to maintain 1.1.1 in 13. If people want to keep older applications built on unsupported releases still working without recompiling, etc. they will have to manage that themselves. Currently we don't support 12.0 on the 12.x branch for example. -- John Baldwin ___ freebsd-security@freebsd.org mailing list
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On 20. 12. 14., Ed Maste wrote: > On Mon, 14 Dec 2020 at 11:46, Ed Maste wrote: >> >> On Thu, 10 Dec 2020 at 10:43, Wall, Stephen wrote: >>> A query: am I right that the patch doesn’t bump the OpenSSL version to 1.1.1.i ? >>> >>> That is correct. >> >> Further to that, OpenSSL 1.1.1i includes some additional, minor >> changes beyond the vulnerability fix. 1.1.1i is now in HEAD (as of >> r368472) and has been merged to stable/12. > > Oops, I got ahead of myself - it has not yet been merged to stable/12. Now it's done (r368639). Sorry for the delay. I wasn't sure about mergeinfo because of svn-to-git transition. Jung-uk Kim ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Mon, 14 Dec 2020 at 11:46, Ed Maste wrote: > > On Thu, 10 Dec 2020 at 10:43, Wall, Stephen wrote: > > > > > A query: am I right that the patch doesn’t bump the OpenSSL version to > > > 1.1.1.i ? > > > > That is correct. > > Further to that, OpenSSL 1.1.1i includes some additional, minor > changes beyond the vulnerability fix. 1.1.1i is now in HEAD (as of > r368472) and has been merged to stable/12. Oops, I got ahead of myself - it has not yet been merged to stable/12. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Thu, 10 Dec 2020 at 10:43, Wall, Stephen wrote: > > > A query: am I right that the patch doesn’t bump the OpenSSL version to > > 1.1.1.i ? > > That is correct. Further to that, OpenSSL 1.1.1i includes some additional, minor changes beyond the vulnerability fix. 1.1.1i is now in HEAD (as of r368472) and has been merged to stable/12. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Wed, 9 Dec 2020 at 18:03, FreeBSD Security Advisories wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > = > FreeBSD-SA-20:33.opensslSecurity Advisory > The FreeBSD Project > > Topic: OpenSSL NULL pointer de-reference > > Category: contrib > Module: openssl > Announced: 2020-12-08 > Affects:All supported versions of FreeBSD. > Corrected: 2020-12-08 18:28:49 UTC (stable/12, 12.2-STABLE) > 2020-12-08 19:10:40 UTC (releng/12.2, 12.2-RELEASE-p2) > 2020-12-08 19:10:40 UTC (releng/12.1, 12.1-RELEASE-p12) > CVE Name: CVE-2020-1971 > > Note: The OpenSSL project has published publicly available patches for > versions included in FreeBSD 12.x. This vulnerability is also known to > affect OpenSSL versions included in FreeBSD 11.4. The fix has been backported by jkim@ to stable/11 in r368530: https://svnweb.freebsd.org/base?view=revision=368530 It can be applied to a releng/11.4 Subversion checkout by executing (at the top of the checked-out tree): $ svn merge -c 368530 ^/stable/11 . I expect an updated advisory, including the 11.4 patch, to be released soon. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Benjamin Kaduk wrote this message on Sat, Dec 12, 2020 at 18:07 -0800: > On Sat, Dec 12, 2020 at 04:57:08PM -0800, John-Mark Gurney wrote: > > > > If FreeBSD is going to continue to use OpenSSL, better testing needs to > > be done to figure out such breakage earliers, and how to not have them > > go undetected for so long. > > I don't think anyone would argue against increasing test coverage. > The most important question seems to be how to know what should be getting > tested but isn't. Do you have any ideas for where to start looking? Is there a CI pipeline setup for OpenSSL testing on -current and the stable branches? If so, where the results posted? Are the existing test suite being run? Why was the engine test not being run? Has that now been fixed? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Sun, Dec 13, 2020 at 12:12:08PM +, John Long via freebsd-security wrote: > Hi Guys, > > What about adopting OpenBSD's libressl? I was expecting it to take a > long time to be compatible but from my uneducated point of view it > looks like they did an incredible job. I think everything on OpenBSD > uses it. > > I was running OpenBSD until I put FreeBSD 12.2 on a new box, so I > haven't been looking at for a year or so. > > Does anybody know if this is a viable option? Can we just link against > libressl or is it (much) more involved than that? As was mentioned elsewhere, LibreSSL isn't a great fit due to their very limited support lifespan of a given release. Once a stable release is made, that branch is only given 1 year of support. This doesn't mesh well with FreeBSD's 5 year support lifespan of a given branch. Gordon ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Hi Guys, What about adopting OpenBSD's libressl? I was expecting it to take a long time to be compatible but from my uneducated point of view it looks like they did an incredible job. I think everything on OpenBSD uses it. I was running OpenBSD until I put FreeBSD 12.2 on a new box, so I haven't been looking at for a year or so. Does anybody know if this is a viable option? Can we just link against libressl or is it (much) more involved than that? /jl On Sat, 12 Dec 2020 18:07:27 -0800 Benjamin Kaduk wrote: > On Sat, Dec 12, 2020 at 04:57:08PM -0800, John-Mark Gurney wrote: > > > > If FreeBSD is going to continue to use OpenSSL, better testing > > needs to be done to figure out such breakage earliers, and how to > > not have them go undetected for so long. > > I don't think anyone would argue against increasing test coverage. > The most important question seems to be how to know what should be > getting tested but isn't. Do you have any ideas for where to start > looking? > > Thanks, > > Ben > ___ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscr...@freebsd.org" ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Sat, Dec 12, 2020 at 04:57:08PM -0800, John-Mark Gurney wrote: > > If FreeBSD is going to continue to use OpenSSL, better testing needs to > be done to figure out such breakage earliers, and how to not have them > go undetected for so long. I don't think anyone would argue against increasing test coverage. The most important question seems to be how to know what should be getting tested but isn't. Do you have any ideas for where to start looking? Thanks, Ben ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
John Baldwin wrote this message on Sat, Dec 12, 2020 at 11:40 -0800: > On 12/10/20 10:46 PM, John-Mark Gurney wrote: > > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at > > 23:03 +: > >> versions included in FreeBSD 12.x. This vulnerability is also known to > >> affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > >> project is only giving patches for that version to premium support contract > >> holders. The FreeBSD project does not have access to these patches and > >> recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > >> up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > >> may update this advisory to include FreeBSD 11.4 should patches become > >> publicly available. > > > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > > for almost a year, and 11 is going to have almost another year of > > support during which time if there's another vuln, we'll again be > > leaving the users in a bad place. > > > > I have not heard if OpenSSL has bother to address the breakage of > > /dev/crypto that also recently came up, but it does appear that they > > are no longer a good fit for FreeBSD. > > I think I can't disagree more. In terms of /dev/crypto, see here: > > https://github.com/openssl/openssl/pull/13468 I went back to the original PR that rewrote /dev/crypto: https://github.com/openssl/openssl/pull/3744 The PR was submitted in June 2017, and they tested on FreeBSD 8.4-R, which had support end on June 2015. Even back in 2017, it was easy enough w/ VMs and cloud compute to spin up a modern, supported FreeBSD box. Yes, it's good that it's now getting fixed, 3 years after it was broken. If FreeBSD is going to continue to use OpenSSL, better testing needs to be done to figure out such breakage earliers, and how to not have them go undetected for so long. > Also, OpenSSL has been perfectly fine to work with in terms of > upstreaming KTLS. kaduk@ is an OpenSSL committer and has been > helpful with helping me find reviewers for patches when needed > as well. > > In terms of OpenSSL vs other SSL libraries, I'll defer to this: > > https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html I'll note that this article is more for a developer than the maintainer of an OS. When FreeBSD has 5 year support cycles, things are slightly different, otherwise I agree that the article is good advice (from my brief reading/looking over). > > Even as it stands, FreeBSD has committed to supporting 12 for close > > to a year longer than OpenSSL has for 1.1.1 meaning we will be in the > > same situation we are w/ 11 in a few years. > > > > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > > than we are now. OpenSSL 3.0.0 has no support commitment announced > > yet, and sticking with 1.1.1 for 13 will put us even in a worse > > situation than we are today. > > > > What are peoples thoughts on how to address the support mismatch between > > FreeBSD and OpenSSL? And how to address it? > > I do think the support mismatch questions are still real, and I'm not > sure what the best answer is. My guess is that the the delay of > 3.0.0 (which I had hoped would ship in 13.0) will mean that 1.1.1's > lifetime will get extended, but probably not enough to cover 13.x > for 5 years. One option may be that we provide a compat openssl for > 13.x that is 1.1.1 for things built on the head of the branch but > actually import OpenSSL 3.0.0 into stable/13 at some point. You could > do this with a shlib major version bump. It won't solve all problems > if some shared library linked against 1.1.1 returns some object > allocated by libssl that the application tries to use directly (and > the application is linked against 3.0.0), but I'm not sure how common > that situation will be in practice. OpenSSL isn't libc where you have > issues with malloc/free crossing this sort of boundary. In the case of mixed 1.1.1 and 3.0.0, that should just be disallowed. Though importing 3.0.0 doesn't solve the issue if 1.1.1 has a security problem... Because the security problem in 1.1.1 will still need to be addressed to deal w/ all the applications that are linked against it.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Sat, Dec 12, 2020 at 11:40:13AM -0800, John Baldwin wrote: > On 12/10/20 10:46 PM, John-Mark Gurney wrote: > > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at > > 23:03 +: > >> versions included in FreeBSD 12.x. This vulnerability is also known to > >> affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > >> project is only giving patches for that version to premium support contract > >> holders. The FreeBSD project does not have access to these patches and > >> recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > >> up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > >> may update this advisory to include FreeBSD 11.4 should patches become > >> publicly available. > > > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > > for almost a year, and 11 is going to have almost another year of > > support during which time if there's another vuln, we'll again be > > leaving the users in a bad place. > > > > I have not heard if OpenSSL has bother to address the breakage of > > /dev/crypto that also recently came up, but it does appear that they > > are no longer a good fit for FreeBSD. > > I think I can't disagree more. In terms of /dev/crypto, see here: > > https://github.com/openssl/openssl/pull/13468 > > Also, OpenSSL has been perfectly fine to work with in terms of > upstreaming KTLS. kaduk@ is an OpenSSL committer and has been > helpful with helping me find reviewers for patches when needed > as well. > > In terms of OpenSSL vs other SSL libraries, I'll defer to this: > > https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html > > > Even as it stands, FreeBSD has committed to supporting 12 for close > > to a year longer than OpenSSL has for 1.1.1 meaning we will be in the > > same situation we are w/ 11 in a few years. > > > > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > > than we are now. OpenSSL 3.0.0 has no support commitment announced > > yet, and sticking with 1.1.1 for 13 will put us even in a worse > > situation than we are today. > > > > What are peoples thoughts on how to address the support mismatch between > > FreeBSD and OpenSSL? And how to address it? > > I do think the support mismatch questions are still real, and I'm not > sure what the best answer is. My guess is that the the delay of > 3.0.0 (which I had hoped would ship in 13.0) will mean that 1.1.1's > lifetime will get extended, but probably not enough to cover 13.x > for 5 years. One option may be that we provide a compat openssl for > 13.x that is 1.1.1 for things built on the head of the branch but > actually import OpenSSL 3.0.0 into stable/13 at some point. You could > do this with a shlib major version bump. It won't solve all problems > if some shared library linked against 1.1.1 returns some object > allocated by libssl that the application tries to use directly (and > the application is linked against 3.0.0), but I'm not sure how common > that situation will be in practice. OpenSSL isn't libc where you have > issues with malloc/free crossing this sort of boundary. > Openssl 3 is still in Alpha and unless a few apps change to accommodate, it should be delayed until the developers get teir act together. > -- > John Baldwin > ___ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Merry Christmas 2020 and Happy New Year 2021 ! ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On 12/10/20 10:46 PM, John-Mark Gurney wrote: > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at 23:03 > +: >> versions included in FreeBSD 12.x. This vulnerability is also known to >> affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL >> project is only giving patches for that version to premium support contract >> holders. The FreeBSD project does not have access to these patches and >> recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage >> up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project >> may update this advisory to include FreeBSD 11.4 should patches become >> publicly available. > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > for almost a year, and 11 is going to have almost another year of > support during which time if there's another vuln, we'll again be > leaving the users in a bad place. > > I have not heard if OpenSSL has bother to address the breakage of > /dev/crypto that also recently came up, but it does appear that they > are no longer a good fit for FreeBSD. I think I can't disagree more. In terms of /dev/crypto, see here: https://github.com/openssl/openssl/pull/13468 Also, OpenSSL has been perfectly fine to work with in terms of upstreaming KTLS. kaduk@ is an OpenSSL committer and has been helpful with helping me find reviewers for patches when needed as well. In terms of OpenSSL vs other SSL libraries, I'll defer to this: https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html > Even as it stands, FreeBSD has committed to supporting 12 for close > to a year longer than OpenSSL has for 1.1.1 meaning we will be in the > same situation we are w/ 11 in a few years. > > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > than we are now. OpenSSL 3.0.0 has no support commitment announced > yet, and sticking with 1.1.1 for 13 will put us even in a worse > situation than we are today. > > What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it? I do think the support mismatch questions are still real, and I'm not sure what the best answer is. My guess is that the the delay of 3.0.0 (which I had hoped would ship in 13.0) will mean that 1.1.1's lifetime will get extended, but probably not enough to cover 13.x for 5 years. One option may be that we provide a compat openssl for 13.x that is 1.1.1 for things built on the head of the branch but actually import OpenSSL 3.0.0 into stable/13 at some point. You could do this with a shlib major version bump. It won't solve all problems if some shared library linked against 1.1.1 returns some object allocated by libssl that the application tries to use directly (and the application is linked against 3.0.0), but I'm not sure how common that situation will be in practice. OpenSSL isn't libc where you have issues with malloc/free crossing this sort of boundary. -- John Baldwin ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Fri, Dec 11, 2020 at 01:36:13PM +0100, Tomasz CEDRO wrote: > On Fri, Dec 11, 2020 at 12:44 PM Franco Fichtner wrote: > > > On 11. Dec 2020, at 12:38 PM, Martin Simmons wrote: > > >> On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: > > >> What are peoples thoughts on how to address the support mismatch between > > >> FreeBSD and OpenSSL? And how to address it? > > > Maybe it would help a little if the packages on pkg.FreeBSD.org all used > > > the > > > pkg version of OpenSSL? Currently, it looks like you have build your own > > > ports if you want that. > > > > This pretty much breaks LibreSSL ports usage for binary package consumers. > > Why not switch to LibreSSL as default? :-) > Is LibreSSL TLSv1.3 compliant? > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > ___ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Merry Christmas 2020 and Happy New Year 2021 ! ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Fri, Dec 11, 2020 at 1:57 PM Franco Fichtner wrote: > > On 11. Dec 2020, at 1:36 PM, Tomasz CEDRO wrote: > > On Fri, Dec 11, 2020 at 12:44 PM Franco Fichtner wrote: > >>> On 11. Dec 2020, at 12:38 PM, Martin Simmons wrote: > On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: > What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it? > >>> Maybe it would help a little if the packages on pkg.FreeBSD.org all used > >>> the > >>> pkg version of OpenSSL? Currently, it looks like you have build your own > >>> ports if you want that. > >> This pretty much breaks LibreSSL ports usage for binary package consumers. > > Why not switch to LibreSSL as default? :-) > > Good question. > > LibreSSL lacks engine and PSK support. TLS 1.3 was tailing behind. Missing > CMS also was a large issue for those who needed it. Someone with more in- > depth knowledge can probably name more. > > The other issue with LibreSSL in general is that third party support is mostly > ok, but some high profile cases have had issues with it for years: HAProxy, > OpenVPN, StrongSwan just to name a few. Having ports contributors and > committers > chase these unthankful quests is probably not worth the overall effort. > > It works pretty well as a ports crypto replacement, but for the reasons listed > above it is probably not going to happen on a default scale. > > Also, LibreSSL in base was a failed experiment in HardenedBSD. Its release > cycle > and support policy is tailored neatly around OpenBSD releases and the attempt > to break ABI compatibility in packages while you retrofit a new version into > a minor release can fail pretty spectacularly. > > I'm not being skeptical. I helped improve overall LibreSSL support in the > ports > tree since 2015. The LibreSSL team is doing a great job all things > considered. > > This is simply the current reality of keeping LibreSSL in ports a steady > alternative. Thank you Franco! Too many reasons why not to.. looks like no good alternative.. at least for now :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Fri, Dec 11, 2020 at 12:44 PM Franco Fichtner wrote: > > On 11. Dec 2020, at 12:38 PM, Martin Simmons wrote: > >> On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: > >> What are peoples thoughts on how to address the support mismatch between > >> FreeBSD and OpenSSL? And how to address it? > > Maybe it would help a little if the packages on pkg.FreeBSD.org all used the > > pkg version of OpenSSL? Currently, it looks like you have build your own > > ports if you want that. > > This pretty much breaks LibreSSL ports usage for binary package consumers. Why not switch to LibreSSL as default? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Fri, Dec 11, 2020 at 02:35:42PM -0800, John-Mark Gurney wrote: > Benjamin Kaduk wrote this message on Fri, Dec 11, 2020 at 12:38 -0800: > > On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote: > > > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at > > > 23:03 +: > > > > versions included in FreeBSD 12.x. This vulnerability is also known to > > > > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > > > > project is only giving patches for that version to premium support > > > > contract > > > > holders. The FreeBSD project does not have access to these patches and > > > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or > > > > leverage > > > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD > > > > Project > > > > may update this advisory to include FreeBSD 11.4 should patches become > > > > publicly available. > > > > > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > > > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > > > for almost a year, and 11 is going to have almost another year of > > > support during which time if there's another vuln, we'll again be > > > leaving the users in a bad place. > > > > To be blunt: didn't we try reevaluating already, and come up empty? > > Software is not a stand still, just because in the past we didn't find > anything, doesn't mean we won't find something this time. Sure. I was just hoping that you might have some thoughts about what had changed, since you were bringing it up again, though I don't mind asking an open question to the list. > > OpenSSL's 5-year support lifetime is quite generous, in my experience, and > > we are suffering more of a clash of release dates than a fundamental > > support-lifetime mismatch. > > > > > I have not heard if OpenSSL has bother to address the breakage of > > > /dev/crypto that also recently came up, but it does appear that they > > > are no longer a good fit for FreeBSD. > > > > I'm not sure why you leap from issues with the devcrypto engine to a > > broader "no longer a good fit" conclusion. The devcrypto engine is hardly > > a core piece of functionality, and jhb has > > No, but it demonstrates the amount of work that the OpenSSL devs are > putting in to supporting FreeBSD. It's one thing to say, we're not > going to support /dev/crypto anymore and stop compiling it on FreeBSD, > it's another to take known working software and intentionally break it > w/o evaluating it's impact upon their "supported" platforms. OpenSSL > chose to do the later... With all due respect, that seems to misrepresent the facts of the situation. If you consider the history at https://github.com/openssl/openssl/pull/3744 it is quite clear that the cryptodev rewrite was specifically tested on FreeBSD before it was committed. An older version, to be sure, yet we might as well be complaining about FreeBSD having changed the userspace/kernel interface rather than OpenSSL having changed its interface. (I am pretty sure that I pointed out to levitte at the time that it was an old version, but I didn't feel a need to repeat the testing locally because FreeBSD is known for its backward compatibility. I don't have that mail on this system, though.) > > https://github.com/openssl/openssl/pull/13468 up waiting for review. > > Why is FreeBSD reacting to these problems? Why didn't OpenSSL devs drop > a mail to FreeBSD -security saying, btw, we've changed X, and we know > it'll break your code, so heads up if anyone wants to fix it, please > submit patches, otherwise in a few weeks we'll disable building support > for it on FreeBSD. If they're not regularly running and testing code > on FreeBSD (or is actively working w/ a person to do such a thing), can > we really say that OpenSSL supports FreeBSD? Um, hello? I'm an OpenSSL committer and I regularly build and test the OpenSSL code on FreeBSD. Not the devcrypto engine, obviously, given the rest of this thread, but the rest of it. Having recently learned that my assumption about the devcrypto engine was misguided, I can start testing that, too. There's also been some recent work from David Carlier to help bring support for some of the more advanced features to FreeBSD as well. If you want examples of upstream proactively keeping up FreeBSD support, I offer: https://github.com/openssl/openssl/pull/12887 https://github.com/openssl/openssl/pull/11797 https://github.com/openssl/openssl/pull/8509 and that's the only instances of FreeBSD-specific breakage (other than devcrypto) that I can recall. The "new" (several years old, at this point) mandatory code-review policy seems to be doing its job, and the quality of new code is generally pretty good. > > I regularly commit to openssl from my FreeBSD system, including the > > build+test cycle; the core functionality remains well-supported. To be > > honest, I didn't bother caring about
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Sat, Dec 12, 2020 at 05:11:07AM +0200, Konstantin Belousov wrote: > On Fri, Dec 11, 2020 at 06:42:13PM -0800, Gordon Tetlow via freebsd-security > wrote: > > On Fri, Dec 11, 2020 at 02:35:42PM -0800, John-Mark Gurney wrote: > > > Benjamin Kaduk wrote this message on Fri, Dec 11, 2020 at 12:38 -0800: > > > > On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote: > > > > > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 > > > > > at 23:03 +: > > > > > > versions included in FreeBSD 12.x. This vulnerability is also > > > > > > known to > > > > > > affect OpenSSL versions included in FreeBSD 11.4. However, the > > > > > > OpenSSL > > > > > > project is only giving patches for that version to premium support > > > > > > contract > > > > > > holders. The FreeBSD project does not have access to these patches > > > > > > and > > > > > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or > > > > > > leverage > > > > > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD > > > > > > Project > > > > > > may update this advisory to include FreeBSD 11.4 should patches > > > > > > become > > > > > > publicly available. > > > > > > > > > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > > > > > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > > > > > for almost a year, and 11 is going to have almost another year of > > > > > support during which time if there's another vuln, we'll again be > > > > > leaving the users in a bad place. > > > > > > > > To be blunt: didn't we try reevaluating already, and come up empty? > > > > > > Software is not a stand still, just because in the past we didn't find > > > anything, doesn't mean we won't find something this time. > > > > I welcome a reasonable alternative to be put forward, but I'm pretty > > sure there isn't one. The five year lifespan of our releases pretty much > > guarantees our crypto toolkit is going to be out of support. This is the > > reality we have signed up for. > > > > LibreSSL - 1 year lifespan of stable branch. > > BoringSSL - No guarantee of API/ABI stability. Actively tells people not > > to use it for production use cases. > > > > Anything other viable implementations I'm missing? > I believe it was discussed, but either there are some insurmountable > issues, or it was abandoned just because. > > What about making openssl private for base ? Pro is that it would be > possible to update to new major release in the midst of the stable > branch, and even keep all branches on the same release. There is no ABI > or API stability to satisfy. > > There is a technical cons argument, besides amount of work required. It > is important that private openssl libs do not leaked into user namespace > and did not clashed with openssl names from ports. Basically, I believe > this is what makes the issue hard and requires a lot of work. > > BTW, this is something where upstream OpenSSL could help. If they started > supporting mangling all exported symbols, it would make this proposal easier > up to the trivial level. There's currently support for mangling the SONAME and symbol version (https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb) but not the actual symbols themselves. Given that the exported symbols are already tracked in the ".num" files and there's perl to process them, it seems like it would not be a huge amount of work to add some mangling and emit a header with the relevant #defines ... I'm less sure of whether it would easily get accepted, though. I think the topic has come up previously but would have to dig a bit to find it. -Ben ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Fri, Dec 11, 2020 at 06:42:13PM -0800, Gordon Tetlow via freebsd-security wrote: > On Fri, Dec 11, 2020 at 02:35:42PM -0800, John-Mark Gurney wrote: > > Benjamin Kaduk wrote this message on Fri, Dec 11, 2020 at 12:38 -0800: > > > On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote: > > > > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at > > > > 23:03 +: > > > > > versions included in FreeBSD 12.x. This vulnerability is also known > > > > > to > > > > > affect OpenSSL versions included in FreeBSD 11.4. However, the > > > > > OpenSSL > > > > > project is only giving patches for that version to premium support > > > > > contract > > > > > holders. The FreeBSD project does not have access to these patches > > > > > and > > > > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or > > > > > leverage > > > > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD > > > > > Project > > > > > may update this advisory to include FreeBSD 11.4 should patches become > > > > > publicly available. > > > > > > > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > > > > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > > > > for almost a year, and 11 is going to have almost another year of > > > > support during which time if there's another vuln, we'll again be > > > > leaving the users in a bad place. > > > > > > To be blunt: didn't we try reevaluating already, and come up empty? > > > > Software is not a stand still, just because in the past we didn't find > > anything, doesn't mean we won't find something this time. > > I welcome a reasonable alternative to be put forward, but I'm pretty > sure there isn't one. The five year lifespan of our releases pretty much > guarantees our crypto toolkit is going to be out of support. This is the > reality we have signed up for. > > LibreSSL - 1 year lifespan of stable branch. > BoringSSL - No guarantee of API/ABI stability. Actively tells people not > to use it for production use cases. > > Anything other viable implementations I'm missing? I believe it was discussed, but either there are some insurmountable issues, or it was abandoned just because. What about making openssl private for base ? Pro is that it would be possible to update to new major release in the midst of the stable branch, and even keep all branches on the same release. There is no ABI or API stability to satisfy. There is a technical cons argument, besides amount of work required. It is important that private openssl libs do not leaked into user namespace and did not clashed with openssl names from ports. Basically, I believe this is what makes the issue hard and requires a lot of work. BTW, this is something where upstream OpenSSL could help. If they started supporting mangling all exported symbols, it would make this proposal easier up to the trivial level. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Fri, Dec 11, 2020 at 02:35:42PM -0800, John-Mark Gurney wrote: > Benjamin Kaduk wrote this message on Fri, Dec 11, 2020 at 12:38 -0800: > > On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote: > > > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at > > > 23:03 +: > > > > versions included in FreeBSD 12.x. This vulnerability is also known to > > > > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > > > > project is only giving patches for that version to premium support > > > > contract > > > > holders. The FreeBSD project does not have access to these patches and > > > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or > > > > leverage > > > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD > > > > Project > > > > may update this advisory to include FreeBSD 11.4 should patches become > > > > publicly available. > > > > > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > > > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > > > for almost a year, and 11 is going to have almost another year of > > > support during which time if there's another vuln, we'll again be > > > leaving the users in a bad place. > > > > To be blunt: didn't we try reevaluating already, and come up empty? > > Software is not a stand still, just because in the past we didn't find > anything, doesn't mean we won't find something this time. I welcome a reasonable alternative to be put forward, but I'm pretty sure there isn't one. The five year lifespan of our releases pretty much guarantees our crypto toolkit is going to be out of support. This is the reality we have signed up for. LibreSSL - 1 year lifespan of stable branch. BoringSSL - No guarantee of API/ABI stability. Actively tells people not to use it for production use cases. Anything other viable implementations I'm missing? Gordon ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Benjamin Kaduk wrote this message on Fri, Dec 11, 2020 at 12:38 -0800: > On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote: > > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at > > 23:03 +: > > > versions included in FreeBSD 12.x. This vulnerability is also known to > > > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > > > project is only giving patches for that version to premium support > > > contract > > > holders. The FreeBSD project does not have access to these patches and > > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or > > > leverage > > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD > > > Project > > > may update this advisory to include FreeBSD 11.4 should patches become > > > publicly available. > > > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > > for almost a year, and 11 is going to have almost another year of > > support during which time if there's another vuln, we'll again be > > leaving the users in a bad place. > > To be blunt: didn't we try reevaluating already, and come up empty? Software is not a stand still, just because in the past we didn't find anything, doesn't mean we won't find something this time. > OpenSSL's 5-year support lifetime is quite generous, in my experience, and > we are suffering more of a clash of release dates than a fundamental > support-lifetime mismatch. > > > I have not heard if OpenSSL has bother to address the breakage of > > /dev/crypto that also recently came up, but it does appear that they > > are no longer a good fit for FreeBSD. > > I'm not sure why you leap from issues with the devcrypto engine to a > broader "no longer a good fit" conclusion. The devcrypto engine is hardly > a core piece of functionality, and jhb has No, but it demonstrates the amount of work that the OpenSSL devs are putting in to supporting FreeBSD. It's one thing to say, we're not going to support /dev/crypto anymore and stop compiling it on FreeBSD, it's another to take known working software and intentionally break it w/o evaluating it's impact upon their "supported" platforms. OpenSSL chose to do the later... > https://github.com/openssl/openssl/pull/13468 up waiting for review. Why is FreeBSD reacting to these problems? Why didn't OpenSSL devs drop a mail to FreeBSD -security saying, btw, we've changed X, and we know it'll break your code, so heads up if anyone wants to fix it, please submit patches, otherwise in a few weeks we'll disable building support for it on FreeBSD. If they're not regularly running and testing code on FreeBSD (or is actively working w/ a person to do such a thing), can we really say that OpenSSL supports FreeBSD? > I regularly commit to openssl from my FreeBSD system, including the > build+test cycle; the core functionality remains well-supported. To be > honest, I didn't bother caring about devcrypto because I didn't expect it > to be widely used, given that you have to have special hardware to overcome > the hit of syscall context switching. Sounds like you need to get a QAT system or other accelerator board for testing then. There are a new class of crypto accelerators that make this a viable option again, so I dispute your definition of devcrypto not being useful. > > Even as it stands, FreeBSD has committed to supporting 12 for close > > to a year longer than OpenSSL has for 1.1.1 meaning we will be in the > > same situation we are w/ 11 in a few years. > > > > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > > than we are now. OpenSSL 3.0.0 has no support commitment announced > > yet, and sticking with 1.1.1 for 13 will put us even in a worse > > situation than we are today. > > OpenSSL 3.0.0 is not going to be LTS; I expect it to go EoL before 1.1.1 > does. (And I expect 1.1.1 to be supported past 2023-09-11, though of > course I do not speak for the project.) I also think that 3.0.0 is not the Until the OpenSSL project changes it, we have to operate under the assumption that the date will not change, and make plans to deal w/ OpenSSL 1.1.1 on 13-current for years after OpenSSL stops supporting it. > recommended relase for anyone who doesn't need the FIPS compatibility; > there's been a substantial rearchitecture and will likely be growing pains > as tend to accompany dot-zero releases. > > > What are peoples thoughts on how to address the support mismatch between > > FreeBSD and OpenSSL? And how to address it? > > > > IMO, FreeBSD does need to do something, and staying w/ OpenSSL does > > not look like a viable option. > > IMO OpenSSL 1.1.1 is generally in pretty good shape and much easier to > maintain than 1.0.2 was. I have yet to see an alternative suitable for > inclusion in the base system that would be more viable. -- John-Mark Gurney
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Hi Ben, > On 11. Dec 2020, at 9:13 PM, Benjamin Kaduk wrote: > > Could you please clarify what you mean by "second tier crypto" and "first > tier crypto"? I'm having a hard time understanding this statement. Sorry for being unclear. First tier = base system crypto for ports Second tier = ports/packages crypto for ports It's also true what John-Mark wrote that moving ports to ports-based crypto does not solve security updates for the dependent base system parts. pkg-base can fix this, but then that also requires to stay clear of package ABI clashes in dependent packages, which requires concerted updates of base and ports packages or at least some sort of version constraint / mismatch detection via something other than the FreeBSD version number. Cheers, Franco ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Hi John-Mark, On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote: > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at 23:03 > +: > > versions included in FreeBSD 12.x. This vulnerability is also known to > > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > > project is only giving patches for that version to premium support contract > > holders. The FreeBSD project does not have access to these patches and > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > > may update this advisory to include FreeBSD 11.4 should patches become > > publicly available. > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > for almost a year, and 11 is going to have almost another year of > support during which time if there's another vuln, we'll again be > leaving the users in a bad place. To be blunt: didn't we try reevaluating already, and come up empty? OpenSSL's 5-year support lifetime is quite generous, in my experience, and we are suffering more of a clash of release dates than a fundamental support-lifetime mismatch. > I have not heard if OpenSSL has bother to address the breakage of > /dev/crypto that also recently came up, but it does appear that they > are no longer a good fit for FreeBSD. I'm not sure why you leap from issues with the devcrypto engine to a broader "no longer a good fit" conclusion. The devcrypto engine is hardly a core piece of functionality, and jhb has https://github.com/openssl/openssl/pull/13468 up waiting for review. I regularly commit to openssl from my FreeBSD system, including the build+test cycle; the core functionality remains well-supported. To be honest, I didn't bother caring about devcrypto because I didn't expect it to be widely used, given that you have to have special hardware to overcome the hit of syscall context switching. > Even as it stands, FreeBSD has committed to supporting 12 for close > to a year longer than OpenSSL has for 1.1.1 meaning we will be in the > same situation we are w/ 11 in a few years. > > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > than we are now. OpenSSL 3.0.0 has no support commitment announced > yet, and sticking with 1.1.1 for 13 will put us even in a worse > situation than we are today. OpenSSL 3.0.0 is not going to be LTS; I expect it to go EoL before 1.1.1 does. (And I expect 1.1.1 to be supported past 2023-09-11, though of course I do not speak for the project.) I also think that 3.0.0 is not the recommended relase for anyone who doesn't need the FIPS compatibility; there's been a substantial rearchitecture and will likely be growing pains as tend to accompany dot-zero releases. > What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it? > > IMO, FreeBSD does need to do something, and staying w/ OpenSSL does > not look like a viable option. IMO OpenSSL 1.1.1 is generally in pretty good shape and much easier to maintain than 1.0.2 was. I have yet to see an alternative suitable for inclusion in the base system that would be more viable. -Ben ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On Fri, Dec 11, 2020 at 11:11:54AM +0100, Andrea Venturoli wrote: > On 12/10/20 12:03 AM, FreeBSD Security Advisories wrote: > > > Note: The OpenSSL project has published publicly available patches for > > versions included in FreeBSD 12.x. This vulnerability is also known to > > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > > project is only giving patches for that version to premium support contract > > holders. The FreeBSD project does not have access to these patches and > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > > may update this advisory to include FreeBSD 11.4 should patches become > > publicly available. > > So I'm looking for suggestion on how to handle this. > I guess I'll just upgrade some 11.4 to 12.2 and that'll be it. > > However there are a few boxes I can't or don't want to upgrade and I'm > thinking about using openssl from ports. > > > > If I'm correct, I'll need to put "DEFAULT_VERSIONS= ssl=openssl" either > in /etc/make.conf and/or in /usr/local/etc/poudriere.d/114amd64-make.conf. > > I started with the latter, but a bulk run ended up in some port failing > (and a lot being skipped) due to kerberos support: AFAICT I cannot use > base's kerberos with ports' openssl. Which is a better replacement: MIT > or HEIMDAL? It would be useful to give more specifics on the failures, as there's a few classes of things that can go wrong. It doesn't look like openssl from ports attempts to support the TLS ciphers with kerberos, which would rule out the "openssl tries to depend on kerberos" class of issues. I assume, then, that you're running into API conflicts where hcrypto and libcrypto present similar-named symbols, in which case MIT would be preferred. (The heimdal in base is quite old anyway, and using an external kerberos would be recommended in general if you're using it for much.) -Ben ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Hi Franco, On Fri, Dec 11, 2020 at 01:28:43PM +0100, Franco Fichtner wrote: > > > On 11. Dec 2020, at 13:20, Martin Simmons wrote: > > > > > > I'm talking about the binary packages from pkg.FreeBSD.org. Don't they > > always > > use the base OpenSSL at the moment? > > Yes, and if it would be built against ports OpenSSL you can no longer build > against LibreSSL locally. > > In OPNsense we do build against ports OpenSSL for upgrade ease, but we also > offer a second set of packages for LibreSSL. > > For the normal FreeBSD user defaulting packages against OpenSSL from ports > would be severely limiting their capability to deviate from this with one-off > builds and most cannot or will not run their own poudriere batch. > > Effectively, using the second tier crypto to emulate the first tier crypto > would trash the second tier for everyone else. Could you please clarify what you mean by "second tier crypto" and "first tier crypto"? I'm having a hard time understanding this statement. Thanks, Ben ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Robert Schulze wrote this message on Fri, Dec 11, 2020 at 10:14 +0100: > Hi, > > Am 11.12.20 um 07:46 schrieb John-Mark Gurney: > > > > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > > than we are now. OpenSSL 3.0.0 has no support commitment announced > > yet, and sticking with 1.1.1 for 13 will put us even in a worse > > situation than we are today. > > > > What are peoples thoughts on how to address the support mismatch between > > FreeBSD and OpenSSL? And how to address it? > > > > IMO, FreeBSD does need to do something, and staying w/ OpenSSL does > > not look like a viable option. > > you may install a current OpenSSL via ports if you like to. > I don't see any OpenSSL fork to be more reliable than its predecessor > but there has been done much work in the portstree to enable the system > administrator to switch. That does not fix all the applications that are in base, like fetch, that use OpenSSL. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
> On Fri, 11 Dec 2020 13:28:43 +0100, Franco Fichtner said: > > > On 11. Dec 2020, at 13:20, Martin Simmons wrote: > > > > > >> > >> On Fri, 11 Dec 2020 12:44:17 +0100, Franco Fichtner said: > >> > On 11. Dec 2020, at 12:38 PM, Martin Simmons > wrote: > >>> > On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: > > What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it? > >>> > >>> Maybe it would help a little if the packages on pkg.FreeBSD.org all used > >>> the > >>> pkg version of OpenSSL? Currently, it looks like you have build your own > >>> ports if you want that. > >> > >> This pretty much breaks LibreSSL ports usage for binary package consumers. > > > > I'm talking about the binary packages from pkg.FreeBSD.org. Don't they > > always > > use the base OpenSSL at the moment? > > Yes, and if it would be built against ports OpenSSL you can no longer build > against LibreSSL locally. > > In OPNsense we do build against ports OpenSSL for upgrade ease, but we also > offer a second set of packages for LibreSSL. > > For the normal FreeBSD user defaulting packages against OpenSSL from ports > would be severely limiting their capability to deviate from this with one-off > builds and most cannot or will not run their own poudriere batch. OK, I see what you mean now. The underlying problem is that it is impossible to install packages/ports for OpenSSL and LibreSSL at the same time. __Martin ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
> On 11. Dec 2020, at 1:36 PM, Tomasz CEDRO wrote: > > On Fri, Dec 11, 2020 at 12:44 PM Franco Fichtner wrote: >>> On 11. Dec 2020, at 12:38 PM, Martin Simmons wrote: On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: What are peoples thoughts on how to address the support mismatch between FreeBSD and OpenSSL? And how to address it? >>> Maybe it would help a little if the packages on pkg.FreeBSD.org all used the >>> pkg version of OpenSSL? Currently, it looks like you have build your own >>> ports if you want that. >> >> This pretty much breaks LibreSSL ports usage for binary package consumers. > > Why not switch to LibreSSL as default? :-) Good question. LibreSSL lacks engine and PSK support. TLS 1.3 was tailing behind. Missing CMS also was a large issue for those who needed it. Someone with more in- depth knowledge can probably name more. The other issue with LibreSSL in general is that third party support is mostly ok, but some high profile cases have had issues with it for years: HAProxy, OpenVPN, StrongSwan just to name a few. Having ports contributors and committers chase these unthankful quests is probably not worth the overall effort. It works pretty well as a ports crypto replacement, but for the reasons listed above it is probably not going to happen on a default scale. Also, LibreSSL in base was a failed experiment in HardenedBSD. Its release cycle and support policy is tailored neatly around OpenBSD releases and the attempt to break ABI compatibility in packages while you retrofit a new version into a minor release can fail pretty spectacularly. I'm not being skeptical. I helped improve overall LibreSSL support in the ports tree since 2015. The LibreSSL team is doing a great job all things considered. This is simply the current reality of keeping LibreSSL in ports a steady alternative. Cheers, Franco ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
> On 11. Dec 2020, at 13:20, Martin Simmons wrote: > > >> >> On Fri, 11 Dec 2020 12:44:17 +0100, Franco Fichtner said: >> On 11. Dec 2020, at 12:38 PM, Martin Simmons wrote: >>> On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: What are peoples thoughts on how to address the support mismatch between FreeBSD and OpenSSL? And how to address it? >>> >>> Maybe it would help a little if the packages on pkg.FreeBSD.org all used the >>> pkg version of OpenSSL? Currently, it looks like you have build your own >>> ports if you want that. >> >> This pretty much breaks LibreSSL ports usage for binary package consumers. > > I'm talking about the binary packages from pkg.FreeBSD.org. Don't they always > use the base OpenSSL at the moment? Yes, and if it would be built against ports OpenSSL you can no longer build against LibreSSL locally. In OPNsense we do build against ports OpenSSL for upgrade ease, but we also offer a second set of packages for LibreSSL. For the normal FreeBSD user defaulting packages against OpenSSL from ports would be severely limiting their capability to deviate from this with one-off builds and most cannot or will not run their own poudriere batch. Effectively, using the second tier crypto to emulate the first tier crypto would trash the second tier for everyone else. Cheers, Franco ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
> On Fri, 11 Dec 2020 12:44:17 +0100, Franco Fichtner said: > > > On 11. Dec 2020, at 12:38 PM, Martin Simmons wrote: > > > >> On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: > >> > >> What are peoples thoughts on how to address the support mismatch between > >> FreeBSD and OpenSSL? And how to address it? > > > > Maybe it would help a little if the packages on pkg.FreeBSD.org all used the > > pkg version of OpenSSL? Currently, it looks like you have build your own > > ports if you want that. > > This pretty much breaks LibreSSL ports usage for binary package consumers. I'm talking about the binary packages from pkg.FreeBSD.org. Don't they always use the base OpenSSL at the moment? __Martin ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
> On Wed, 9 Dec 2020 23:03:00 + (UTC), FreeBSD Security Advisories > said: > > Note: The OpenSSL project has published publicly available patches for > versions included in FreeBSD 12.x. This vulnerability is also known to > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > project is only giving patches for that version to premium support contract > holders. The FreeBSD project does not have access to these patches and > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > may update this advisory to include FreeBSD 11.4 should patches become > publicly available. I see that Ubuntu have backported this (see 1.0.2n-1ubuntu5.5 in https://launchpad.net/ubuntu/+source/openssl1.0). __Martin ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
> On 11. Dec 2020, at 12:38 PM, Martin Simmons wrote: > >> On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: >> >> What are peoples thoughts on how to address the support mismatch between >> FreeBSD and OpenSSL? And how to address it? > > Maybe it would help a little if the packages on pkg.FreeBSD.org all used the > pkg version of OpenSSL? Currently, it looks like you have build your own > ports if you want that. This pretty much breaks LibreSSL ports usage for binary package consumers. Cheers, Franco ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
> On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: > > What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it? Maybe it would help a little if the packages on pkg.FreeBSD.org all used the pkg version of OpenSSL? Currently, it looks like you have build your own ports if you want that. __Martin ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Andrea Venturoli wrote on 2020-12-11: > On 12/10/20 12:03 AM, FreeBSD Security Advisories wrote: > > > Note: The OpenSSL project has published publicly available patches for > > versions included in FreeBSD 12.x. This vulnerability is also known to > > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > > project is only giving patches for that version to premium support contract > > holders. The FreeBSD project does not have access to these patches and > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > > may update this advisory to include FreeBSD 11.4 should patches become > > publicly available. > > So I'm looking for suggestion on how to handle this. > I guess I'll just upgrade some 11.4 to 12.2 and that'll be it. The fix was already backported to stable/11 so it's now "publicly available": https://svnweb.freebsd.org/base?view=revision=368530 I expect that releng/11.4 will receive the fix in the near future. Fabian pgpW1Wp6QrP6r.pgp Description: OpenPGP digital signature
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
On 12/10/20 12:03 AM, FreeBSD Security Advisories wrote: Note: The OpenSSL project has published publicly available patches for versions included in FreeBSD 12.x. This vulnerability is also known to affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL project is only giving patches for that version to premium support contract holders. The FreeBSD project does not have access to these patches and recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project may update this advisory to include FreeBSD 11.4 should patches become publicly available. So I'm looking for suggestion on how to handle this. I guess I'll just upgrade some 11.4 to 12.2 and that'll be it. However there are a few boxes I can't or don't want to upgrade and I'm thinking about using openssl from ports. If I'm correct, I'll need to put "DEFAULT_VERSIONS= ssl=openssl" either in /etc/make.conf and/or in /usr/local/etc/poudriere.d/114amd64-make.conf. I started with the latter, but a bulk run ended up in some port failing (and a lot being skipped) due to kerberos support: AFAICT I cannot use base's kerberos with ports' openssl. Which is a better replacement: MIT or HEIMDAL? Then I think I'll just need "pkg upgrade -f", where I'm using packages. I still have some systems, however, that are using portupgrade: perhaps I can convert some to packages, but others have to stay like this for the moment. Will "portupgrade -Fa" do or do I need something more complex? bye & Thanks av. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Hi, Am 11.12.20 um 07:46 schrieb John-Mark Gurney: > > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > than we are now. OpenSSL 3.0.0 has no support commitment announced > yet, and sticking with 1.1.1 for 13 will put us even in a worse > situation than we are today. > > What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it? > > IMO, FreeBSD does need to do something, and staying w/ OpenSSL does > not look like a viable option. > you may install a current OpenSSL via ports if you like to. I don't see any OpenSSL fork to be more reliable than its predecessor but there has been done much work in the portstree to enable the system administrator to switch. There is not much left (if anything) to be done in FreeBSD itself regarding the standard crypto library. regards, Robert Schulze ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at 23:03 +: > versions included in FreeBSD 12.x. This vulnerability is also known to > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > project is only giving patches for that version to premium support contract > holders. The FreeBSD project does not have access to these patches and > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > may update this advisory to include FreeBSD 11.4 should patches become > publicly available. FreeBSD needs to reevaluate the continued reliance on OpenSSL for our crypto/TLS library. 1.0.2 which is in 11-stable has not had support for almost a year, and 11 is going to have almost another year of support during which time if there's another vuln, we'll again be leaving the users in a bad place. I have not heard if OpenSSL has bother to address the breakage of /dev/crypto that also recently came up, but it does appear that they are no longer a good fit for FreeBSD. Even as it stands, FreeBSD has committed to supporting 12 for close to a year longer than OpenSSL has for 1.1.1 meaning we will be in the same situation we are w/ 11 in a few years. Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation than we are now. OpenSSL 3.0.0 has no support commitment announced yet, and sticking with 1.1.1 for 13 will put us even in a worse situation than we are today. What are peoples thoughts on how to address the support mismatch between FreeBSD and OpenSSL? And how to address it? IMO, FreeBSD does need to do something, and staying w/ OpenSSL does not look like a viable option. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
> A query: am I right that the patch doesn’t bump the OpenSSL version to > 1.1.1.i ? That is correct. - Steve Wall ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl
Hi, > On 9 Dec 2020, at 23:03, FreeBSD Security Advisories > wrote: > > Signed PGP part > = > FreeBSD-SA-20:33.opensslSecurity Advisory > The FreeBSD Project > > Topic: OpenSSL NULL pointer de-reference > [etc] A query: am I right that the patch doesn’t bump the OpenSSL version to 1.1.1.i ? -- Bob Bishop r...@gid.co.uk signature.asc Description: Message signed with OpenPGP
