From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Forthcoming OpenSSL Releases (new blocking bug from openssl-3.x) Date: Wed, 07 Jun 2023 13:24:35 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2635640877064369966==" List-Id: --===============2635640877064369966== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 7 Jun 2023, at 11:17, Adolf Belka wrote: >=20 > Hi Michel, >=20 > On 07/06/2023 10:50, Michael Tremer wrote: >> Hello, >>> On 6 Jun 2023, at 22:51, Adolf Belka wrote: >>>=20 >>> Hi Peter, >>>=20 >>> On 06/06/2023 22:58, Peter M=C3=BCller wrote: >>>> Hello Adolf, >>>> hello Michael, >>>> thank you very much for verifying the OpenVPN functionality for PKCS12 c= ontainers imported >>>> from IPFire systems running OpenSSL 1.1.1x. >>>> As discussed yesterday, I tested the same functionality for IPsec, both = for N2N and roadwarrior >>>> connections. For both cases, an IPFire installtion running Core-Update 1= 75 Development Build >>>> master/3d2beee7 was able to import PKCS12 containers created on an IPFir= e installation running >>>> Core Update 174 without any error message whatsoever, and the IPsec conn= ections could be established >>>> afterwards. >>>> As far as I am aware, all blocking issues with Core Update 175 are now r= esolved, and this >>>> update can finally be released! @Michael, a draft for its release announ= cement should be with >>>> you already. >>>=20 >>> I am afraid there is still some more work I am involved in. I realised th= at we did not have the providers legacy default line in the roadwarrior clien= t configs. After a discussion with Michael, we also decide that we don't want= everything to be running legacy, otherwise it will stay like that for ever. >>>=20 >>> So I am working on some patches that will identify the connection certifi= cates that were created with openssl-1.1.1x and those with openssl-3.x and th= is will be stored as a key for each connection. Then when using any of the op= enssl pkcs12 commands, those that are uploading existing certificates will us= e -legacy if the key is openssl-1.1.1x and not for the openssl-3.x >>> If -legacy is used then providers legacy default will be added to the end= of the .ovpn profile file. >> You don=E2=80=99t need to store this in the CSV file. >> You can simply create a new function in the CGI file that takes the path o= f the p12 file and runs the command with it: >=20 > I can see that but the benefit of having it in the ovpnconfig csv file is t= hat in future you can easily see if you have an old based certificate if newe= r problems occur with the old version. Hmm, is this something we want to expose to the user? >=20 >> openssl pkcs12 -info -nodes -in file.p12 -passin pass: -noout >> You will then need to parse the output and if you find =E2=80=9CMAC: sha1= =E2=80=9D at the beginning of any line (might be worth breaking the loop afte= r the first iteration still) then you will return True, otherwise False. >> Then you can just call the function when you need to know whether this is = a legacy certificate. >> It=E2=80=99s not super fast when iterating over hundreds of connections, b= ut we currently only need this when exporting the ZIP file which does not cre= ate that much extra overhead. > It also needs to be run if the user uploads a client certificate into IPFir= e. That is an option within IPFire when creating a client connection, even if= the vast majority of people don't use it. That uploading expects a pkcs12 fi= le which it then extracts the required certs, key etc from. If that openssl c= ommand does not have -legacy in it then the extraction will fail. Should we actually accept those certificates any more? Are they not considere= d cryptographically weak? > If -legacy is there in the cert and key extraction routines does that still= work if the uploaded certificate has been created with openssl-3.x? I will t= est that out. > If yes then the upload openssl commands could have -legacy as standard as i= t wouldn't make any difference then. >>> For the openssl pkcs12 command that is creating a new connection certific= ate, it will always not use -legacy so that any new certificates that are cre= ated will always be the newer ones. If you use -legacy with the pkcs12 creati= on command then the version will be the same as was created with openssl-1.1.= 1x even though openssl-3.x is running on IPFire. >>>=20 >>> When existing connection certificates expire (default is 760 days) then w= hen a new connection certificate is created it will also always be the openss= l-3.x version. >>>=20 >>> Over time the old openssl-1.1.1x certificates will disappear. >>>=20 >>> I will also look at doing the same thing with the net2net connection cert= ificates so only old ones imported will have the providers legacy default add= ed at the end of the n2nconf file. >> You can use the same function as above, as it does not care whether the PK= CS12 file belongs to a RW or N2N connection. >>> The patches I will supply will be based on the nightly build from last ni= ght so none of my existing patches need to be reverted. >>>=20 >>> I will also go back and modify the backup.pl restore function so that it = also checks the openssl generation of all the connection certs and where requ= ired adds the providers legacy default to the .ovpn config. >> If you use the function, you can skip that step I believe. > You are saying that it will also be covered by the download the client n2n = package flow. I will check that out in my testing. Cool. Let us know if we can help :) -Michael >=20 > Regards, > Adolf. >=20 >>> I am working to get it done as soon as possible. >> -Michael >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>> To echo Erik, many many thanks for all the hard work, and dealing with t= he massive headache >>>> the transition to OpenSSL 3.x has induced! >>>> All the best, >>>> Peter M=C3=BCller >>>>> True, >>>>> thanks to all for this. >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Erik >>>>>=20 >>>>> Am Dienstag, dem 06.06.2023 um 17:23 +0200 schrieb Adolf Belka: >>>>>> Hi Michael, >>>>>>=20 >>>>>> I tested out a newly created openvpn connection on Openssl-3.x and >>>>>> installed that on my laptop with the existing legacy providers lines >>>>>> in >>>>>> the openssl.cnf file commented out. that connection was successfully >>>>>> made. >>>>>>=20 >>>>>> So what we discussed is the case. Any new connection from CU175 >>>>>> onwards >>>>>> will work with a system with OpenSSL-3.x >>>>>>=20 >>>>>> It was what we hoped for and expected but it is good to have it >>>>>> confirmed. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>>>>=20 >>>>>> On 06/06/2023 11:33, Michael Tremer wrote: >>>>>>> Thank you. >>>>>>>=20 >>>>>>> I just created a page to explain this problem: >>>>>>>=20 >>>>>>> https://wiki.ipfire.org/configuration/services/openvpn/openssl-3-tran= sition >>>>>>>=20 >>>>>>> Please feel free to edit if I forgot to mention something. >>>>>>>=20 >>>>>>> We should include this in the change log for the release, but >>>>>>> highlight that this breaking change has not been introduced in >>>>>>> c175, but c175 has the fix. >>>>>>>=20 >>>>>>> -Michael >>>>>>>=20 >>>>>>>> On 4 Jun 2023, at 20:14, Adolf Belka >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> I Have submitted a patch set for fixing the bug#13137 related to >>>>>>>> OpenVPN. This patch set together with the one for bug#13138 >>>>>>>> related to IPSec that I shipped yesterday fix the major bugs I >>>>>>>> found for CU175. >>>>>>>>=20 >>>>>>>> Sorry it took a bit longer than I had hoped for. >>>>>>>>=20 >>>>>>>> Please let me know if there are any problems with what I have >>>>>>>> produced and I will work to sort them out. >>>>>>>>=20 >>>>>>>> I am not aware of any other blocking bugs for CU175 at this point >>>>>>>> in time. :crossed_fingers: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Adolf. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 02/06/2023 21:35, Adolf Belka wrote: >>>>>>>>> The poster found the following reference >>>>>>>>>=20 >>>>>>>>> https://serverfault.com/questions/857131/odd-error-while-using-open= ssl >>>>>>>>>=20 >>>>>>>>> which suggests that openssl can sometimes give spurious error >>>>>>>>> messages if unique_subject is not explicitly defined as yes but >>>>>>>>> it doesn't give any suggestion for why this would have occurred >>>>>>>>> with the move to openssl-3.x >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Adolf. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 02/06/2023 21:28, Adolf Belka wrote: >>>>>>>>>> Hi All, >>>>>>>>>>=20 >>>>>>>>>> On 02/06/2023 19:54, Adolf Belka wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>>=20 >>>>>>>>>>> Just when you thought it was safe to get back in the water >>>>>>>>>>> - aaaaah. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I suspected that IPSec would also suffer from the same >>>>>>>>>>> problem of openssl-3.x vs openssl-1.1.1x for the opening of >>>>>>>>>>> .p12 certificates. >>>>>>>>>>>=20 >>>>>>>>>>> Today, from feedback from Roberto Pena in the forum, it >>>>>>>>>>> turns out that trying to create a Root/Host certificate set >>>>>>>>>>> for IPSec causes an error message to be created. >>>>>>>>>>>=20 >>>>>>>>>>> I reproduced this on CU175 Testing build master/9797af30 >>>>>>>>>>> and confirmed that it did not happen in CU174. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I added the -legacy option into every openssl command in >>>>>>>>>>> vpnmain.cgi dealing with .p12 files but this did not solve >>>>>>>>>>> this problem. I then added -legacy to every openssl >>>>>>>>>>> command. This solved the problem. >>>>>>>>>>>=20 >>>>>>>>>> Someone else in that thread about the IPSec Root/Host >>>>>>>>>> certificate creation has suggested adding >>>>>>>>>>=20 >>>>>>>>>> "unique_subject =3D yes" >>>>>>>>>>=20 >>>>>>>>>> into /var/ipfire/certs/index.txt.attr >>>>>>>>>>=20 >>>>>>>>>> have tried that and it does solve the problem. >>>>>>>>>>=20 >>>>>>>>>> However now have the dilemma of which solution to use, the >>>>>>>>>> unique_subject or the legacy option in the openssl commands. >>>>>>>>>>=20 >>>>>>>>>> I have asked the person who suggested the unique_subject fix, >>>>>>>>>> why this is the correct fix to this problem. I searched on >>>>>>>>>> the internet but only found comments that the default value >>>>>>>>>> of that variable is yes anyway and no reference to it needing >>>>>>>>>> to be changed because of a changed from openssl-1.1.1x to >>>>>>>>>> openssl-3.x >>>>>>>>>>=20 >>>>>>>>>> I will see what input the poster provides but does anyone on >>>>>>>>>> this mailing list have any suggestion as to how the >>>>>>>>>> unique_subject =3D yes fix works and why it is needed with >>>>>>>>>> openssl-3.x or any input on how to make the decision between >>>>>>>>>> the two approaches or if both should be used? >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Adolf. >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I then tried only adding the legacy option to each non .p12 >>>>>>>>>>> openssl command one at a time but this also did not fix the >>>>>>>>>>> problem. So more than one of the non .p12 commands needs to >>>>>>>>>>> be defined as legacy at the same time. >>>>>>>>>>>=20 >>>>>>>>>>> I thought if every openssl command was going to have the >>>>>>>>>>> legacy option then the same effect should be possible by >>>>>>>>>>> adding the legacy provider into the openssl.cnf file. Tried >>>>>>>>>>> this but it didn't solve the error message when creating >>>>>>>>>>> the Root/Host IPSec certificate set. So there must be some >>>>>>>>>>> sort of difference between the command line legacy option >>>>>>>>>>> and the legacy provider option in the openssl.cnf file. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> So I will also submit a patch set for the vpnmain.cgi file >>>>>>>>>>> where all openssl commands have the legacy option added. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The same will be done for the ovpnmain.cgi file to be on >>>>>>>>>>> the safe side. Currently I had only added it to the openssl >>>>>>>>>>> commands running on .p12 files. >>>>>>>>>>>=20 >>>>>>>>>>> I did test creating the Root/Host certificate set on >>>>>>>>>>> OpenVPN with openssl-3.x and that worked successfully but I >>>>>>>>>>> think having the legacy option on every openssl command >>>>>>>>>>> should not cause anything to break. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hope to provide a patch set for the various IPSec/OpenVPN >>>>>>>>>>> openssl issues found over the weekend, presuming no one >>>>>>>>>>> finds any further issues. As Michael has said in the past. >>>>>>>>>>> Better to get any patch fix correct than to have a faulty >>>>>>>>>>> one quickly. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>>=20 >>>>>>>>>>> Adolf. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 31/05/2023 20:53, Adolf Belka wrote: >>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>=20 >>>>>>>>>>>> On 31/05/2023 20:43, Michael Tremer wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Does this mean that OpenVPN cannot read those files >>>>>>>>>>>>> either? I had that suspicion. >>>>>>>>>>>> I believe that is the case. The failure I found has no >>>>>>>>>>>> openssl command in the cgi file and adding "providers >>>>>>>>>>>> legacy default" to the end of the client n2n conf file >>>>>>>>>>>> made everything work again. >>>>>>>>>>>>=20 >>>>>>>>>>>> Your idea of making a modification to the openssl conf >>>>>>>>>>>> file is a good one and I will try that out and see if >>>>>>>>>>>> that works. If so then that would be the better approach >>>>>>>>>>>> as then any certificates would be covered by the legacy >>>>>>>>>>>> approach if required. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Adolf. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I will halt the update for now and let=E2=80=99s take some more >>>>>>>>>>>>> time to figure this one out. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Best, >>>>>>>>>>>>> -Michael >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 31 May 2023, at 19:42, Adolf Belka >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I have figured out how to solve the problem. I have >>>>>>>>>>>>>> to add "providers legacy default" into the n2n client >>>>>>>>>>>>>> configuration file. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I have raised a bug on this >>>>>>>>>>>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=3D13137 and >>>>>>>>>>>>>> will submit a patch as soon as feasible. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 31/05/2023 17:07, Adolf Belka wrote: >>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I have a blocking bug. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 29/05/2023 23:34, Adolf Belka wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 26/05/2023 16:28, Michael Tremer wrote: >>>>>>>>>>>>>>>>> Thank you very much for letting me know. I >>>>>>>>>>>>>>>>> wasn=E2=80=99t aware at all. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I reverted those changes in next and if the >>>>>>>>>>>>>>>>> build goes through I will merge the branch back >>>>>>>>>>>>>>>>> into master again. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Just as a reminder the reversion changes went >>>>>>>>>>>>>>>> through on next but are not yet reverted in >>>>>>>>>>>>>>>> master. This needs to be done before CU175 is >>>>>>>>>>>>>>>> released otherwise n2n connections will fail to >>>>>>>>>>>>>>>> work properly. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The reversions have been applied to master (Core >>>>>>>>>>>>>>> Update 175) and I did an update but have found that >>>>>>>>>>>>>>> the n2n connection when the end that had the client >>>>>>>>>>>>>>> upload has stopped working. This is definitely not >>>>>>>>>>>>>>> because of bug#11048 as all of that has been >>>>>>>>>>>>>>> reverted (confirmed by looking at the ovpnmain.cgi >>>>>>>>>>>>>>> file) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I have realised that what is happening is the same >>>>>>>>>>>>>>> as for the insecure roadwarrior certificate that >>>>>>>>>>>>>>> was created with openssl-1.1.1x would not work with >>>>>>>>>>>>>>> openssl-3.x. I fixed that with the addition of the >>>>>>>>>>>>>>> legacy option into the openssl command for that >>>>>>>>>>>>>>> client package download. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The same thing is happening with the n2n >>>>>>>>>>>>>>> connection. I will find the command that access the >>>>>>>>>>>>>>> .p12 file in the zip package and add the legacy >>>>>>>>>>>>>>> option to that. Presuming it works I will raise and >>>>>>>>>>>>>>> submit a patch to fix it. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I will also raise a bug for it and assign myself to >>>>>>>>>>>>>>> it. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -Michael >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 26 May 2023, at 14:33, Adolf Belka >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 24/05/2023 11:02, Michael Tremer wrote: >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> On 24 May 2023, at 09:47, Adolf Belka >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On 24/05/2023 10:07, Michael Tremer >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> It looks like we might not want to >>>>>>>>>>>>>>>>>>>>> release the forthcoming Core Update >>>>>>>>>>>>>>>>>>>>> before this. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> I did not hear any rumours about what >>>>>>>>>>>>>>>>>>>>> might be the issue, but I would say >>>>>>>>>>>>>>>>>>>>> that it wouldn=E2=80=99t hurt us to wait. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> What other outstanding issues do we >>>>>>>>>>>>>>>>>>>>> have that are currently blocking the >>>>>>>>>>>>>>>>>>>>> update? >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> The fix for Bug#13117 has been merged >>>>>>>>>>>>>>>>>>>> into master so that is no longer >>>>>>>>>>>>>>>>>>>> blocking. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> As mentioned to Peter, I recommend >>>>>>>>>>>>>>>>>>>> reverting my fix for Bug#11048 as some >>>>>>>>>>>>>>>>>>>> issues were found by myself (missed in my >>>>>>>>>>>>>>>>>>>> own testing) plus from other testers >>>>>>>>>>>>>>>>>>>> reporting in the forum. I am making >>>>>>>>>>>>>>>>>>>> progress on this but there are still some >>>>>>>>>>>>>>>>>>>> bits outstanding. The bug has been around >>>>>>>>>>>>>>>>>>>> for a long time so it won't hurt for it >>>>>>>>>>>>>>>>>>>> to wait till Core Update 176. >>>>>>>>>>>>>>>>>>> Okay. Let=E2=80=99s rather have the right fix than >>>>>>>>>>>>>>>>>>> a quick one. I agree! >>>>>>>>>>>>>>>>>> The reversion of the update.sh script was >>>>>>>>>>>>>>>>>> done two days ago but there are 4 other >>>>>>>>>>>>>>>>>> commits for the same bug fix that also need >>>>>>>>>>>>>>>>>> to be reverted. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D= 762c88ec4d85e3a4f7265b887f054cbe7703eb7c >>>>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D= 82822934ba769bca4235cd2a02f848cdc8511120 >>>>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D= 070abb0d011ff71e5aefd170dcb366d81bdf2497 >>>>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D= 18bece0edbd817933f48fdbffcffffd074e42c05 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> just to make sure that those don't get >>>>>>>>>>>>>>>>>> missed. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>>>>>>> I haven't found anything else that was a >>>>>>>>>>>>>>>>>>>> problem and I haven't seen any other >>>>>>>>>>>>>>>>>>>> issues mentioned in the forum that look >>>>>>>>>>>>>>>>>>>> to be caused by CU175. >>>>>>>>>>>>>>>>>>> That sounds good then! >>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>>>>>>>> -Michael >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> From: Tomas Mraz >>>>>>>>>>>>>>>>>>>>>> Subject: Forthcoming OpenSSL Releases >>>>>>>>>>>>>>>>>>>>>> Date: 24 May 2023 at 05:06:12 BST >>>>>>>>>>>>>>>>>>>>>> To: "openssl-project(a)openssl.org" >>>>>>>>>>>>>>>>>>>>>> , >>>>>>>>>>>>>>>>>>>>>> "openssl-users(a)openssl.org" >>>>>>>>>>>>>>>>>>>>>> , >>>>>>>>>>>>>>>>>>>>>> openssl-announce(a)openssl.org >>>>>>>>>>>>>>>>>>>>>> Reply-To: openssl-users(a)openssl.org >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> The OpenSSL project team would like >>>>>>>>>>>>>>>>>>>>>> to announce the forthcoming release >>>>>>>>>>>>>>>>>>>>>> of OpenSSL versions 3.0.9, 1.1.1u and >>>>>>>>>>>>>>>>>>>>>> 1.0.2zh. Note that OpenSSL 1.0.2 >>>>>>>>>>>>>>>>>>>>>> is End Of Life and so 1.0.2zh will be >>>>>>>>>>>>>>>>>>>>>> available to premium support >>>>>>>>>>>>>>>>>>>>>> customers only. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> These releases will be made available >>>>>>>>>>>>>>>>>>>>>> on Tuesday 30th May 2023 >>>>>>>>>>>>>>>>>>>>>> between 1300-1700 UTC. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> These are security-fix releases. The >>>>>>>>>>>>>>>>>>>>>> highest severity issue fixed in >>>>>>>>>>>>>>>>>>>>>> each of these three releases is >>>>>>>>>>>>>>>>>>>>>> Moderate: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> https://www.openssl.org/policies/secpolicy.html >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Yours >>>>>>>>>>>>>>>>>>>>>> The OpenSSL Project Team >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>>>>>> Sent from my laptop >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>=20 >>> --=20 >>> Sent from my laptop --===============2635640877064369966==--