From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Forthcoming OpenSSL Releases (new blocking bug from openssl-3.x) Date: Wed, 07 Jun 2023 12:17:29 +0200 Message-ID: In-Reply-To: <5629CE53-62A8-4090-9835-EAC5586AFE1F@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5982330355289516702==" List-Id: --===============5982330355289516702== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michel, On 07/06/2023 10:50, Michael Tremer wrote: > Hello, >=20 >> On 6 Jun 2023, at 22:51, Adolf Belka wrote: >> >> Hi Peter, >> >> 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 co= ntainers imported >>> from IPFire systems running OpenSSL 1.1.1x. >>> As discussed yesterday, I tested the same functionality for IPsec, both f= or N2N and roadwarrior >>> connections. For both cases, an IPFire installtion running Core-Update 17= 5 Development Build >>> master/3d2beee7 was able to import PKCS12 containers created on an IPFire= installation running >>> Core Update 174 without any error message whatsoever, and the IPsec conne= ctions could be established >>> afterwards. >>> As far as I am aware, all blocking issues with Core Update 175 are now re= solved, and this >>> update can finally be released! @Michael, a draft for its release announc= ement should be with >>> you already. >> >> I am afraid there is still some more work I am involved in. I realised tha= t we did not have the providers legacy default line in the roadwarrior client= 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. >> >> So I am working on some patches that will identify the connection certific= ates that were created with openssl-1.1.1x and those with openssl-3.x and thi= s will be stored as a key for each connection. Then when using any of the ope= nssl pkcs12 commands, those that are uploading existing certificates will use= -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. >=20 > You don=E2=80=99t need to store this in the CSV file. >=20 > You can simply create a new function in the CGI file that takes the path of= the p12 file and runs the command with it: I can see that but the benefit of having it in the ovpnconfig csv file is tha= t in future you can easily see if you have an old based certificate if newer = problems occur with the old version. >=20 > openssl pkcs12 -info -nodes -in file.p12 -passin pass: -noout >=20 > 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. >=20 > Then you can just call the function when you need to know whether this is a= legacy certificate. >=20 > It=E2=80=99s not super fast when iterating over hundreds of connections, bu= t we currently only need this when exporting the ZIP file which does not crea= te that much extra overhead. It also needs to be run if the user uploads a client certificate into IPFire.= That is an option within IPFire when creating a client connection, even if t= he vast majority of people don't use it. That uploading expects a pkcs12 file= which it then extracts the required certs, key etc from. If that openssl com= mand does not have -legacy in it then the extraction will fail. If -legacy is there in the cert and key extraction routines does that still w= ork if the uploaded certificate has been created with openssl-3.x? I will tes= t that out. If yes then the upload openssl commands could have -legacy as standard as it = wouldn't make any difference then. >=20 >> For the openssl pkcs12 command that is creating a new connection certifica= te, it will always not use -legacy so that any new certificates that are crea= ted will always be the newer ones. If you use -legacy with the pkcs12 creatio= n command then the version will be the same as was created with openssl-1.1.1= x even though openssl-3.x is running on IPFire. >> >> When existing connection certificates expire (default is 760 days) then wh= en a new connection certificate is created it will also always be the openssl= -3.x version. >> >> Over time the old openssl-1.1.1x certificates will disappear. >> >> I will also look at doing the same thing with the net2net connection certi= ficates so only old ones imported will have the providers legacy default adde= d at the end of the n2nconf file. >=20 > You can use the same function as above, as it does not care whether the PKC= S12 file belongs to a RW or N2N connection. >=20 >> The patches I will supply will be based on the nightly build from last nig= ht so none of my existing patches need to be reverted. >> >> I will also go back and modify the backup.pl restore function so that it a= lso checks the openssl generation of all the connection certs and where requi= red adds the providers legacy default to the .ovpn config. >=20 > 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 pa= ckage flow. I will check that out in my testing. Regards, Adolf. >=20 >> I am working to get it done as soon as possible. >=20 > -Michael >=20 >> >> Regards, >> >> Adolf. >> >>> To echo Erik, many many thanks for all the hard work, and dealing with th= e massive headache >>> the transition to OpenSSL 3.x has induced! >>> All the best, >>> Peter M=C3=BCller >>>> True, >>>> thanks to all for this. >>>> >>>> Best, >>>> >>>> Erik >>>> >>>> Am Dienstag, dem 06.06.2023 um 17:23 +0200 schrieb Adolf Belka: >>>>> Hi Michael, >>>>> >>>>> 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. >>>>> >>>>> So what we discussed is the case. Any new connection from CU175 >>>>> onwards >>>>> will work with a system with OpenSSL-3.x >>>>> >>>>> It was what we hoped for and expected but it is good to have it >>>>> confirmed. >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> >>>>> On 06/06/2023 11:33, Michael Tremer wrote: >>>>>> Thank you. >>>>>> >>>>>> I just created a page to explain this problem: >>>>>> >>>>>> https://wiki.ipfire.org/configuration/services/openvpn/openssl-3-trans= ition >>>>>> >>>>>> Please feel free to edit if I forgot to mention something. >>>>>> >>>>>> 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. >>>>>> >>>>>> -Michael >>>>>> >>>>>>> On 4 Jun 2023, at 20:14, Adolf Belka >>>>>>> wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> Sorry it took a bit longer than I had hoped for. >>>>>>> >>>>>>> Please let me know if there are any problems with what I have >>>>>>> produced and I will work to sort them out. >>>>>>> >>>>>>> I am not aware of any other blocking bugs for CU175 at this point >>>>>>> in time. :crossed_fingers: >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Adolf. >>>>>>> >>>>>>> >>>>>>> On 02/06/2023 21:35, Adolf Belka wrote: >>>>>>>> The poster found the following reference >>>>>>>> >>>>>>>> https://serverfault.com/questions/857131/odd-error-while-using-opens= sl >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Adolf. >>>>>>>> >>>>>>>> >>>>>>>> On 02/06/2023 21:28, Adolf Belka wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> On 02/06/2023 19:54, Adolf Belka wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Just when you thought it was safe to get back in the water >>>>>>>>>> - aaaaah. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> I reproduced this on CU175 Testing build master/9797af30 >>>>>>>>>> and confirmed that it did not happen in CU174. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>> Someone else in that thread about the IPSec Root/Host >>>>>>>>> certificate creation has suggested adding >>>>>>>>> >>>>>>>>> "unique_subject =3D yes" >>>>>>>>> >>>>>>>>> into /var/ipfire/certs/index.txt.attr >>>>>>>>> >>>>>>>>> have tried that and it does solve the problem. >>>>>>>>> >>>>>>>>> However now have the dilemma of which solution to use, the >>>>>>>>> unique_subject or the legacy option in the openssl commands. >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> 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? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Adolf. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So I will also submit a patch set for the vpnmain.cgi file >>>>>>>>>> where all openssl commands have the legacy option added. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Adolf. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 31/05/2023 20:53, Adolf Belka wrote: >>>>>>>>>>> Hi Michael, >>>>>>>>>>> >>>>>>>>>>> On 31/05/2023 20:43, Michael Tremer wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Adolf. >>>>>>>>>>>> >>>>>>>>>>>> I will halt the update for now and let=E2=80=99s take some more >>>>>>>>>>>> time to figure this one out. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> -Michael >>>>>>>>>>>> >>>>>>>>>>>>> On 31 May 2023, at 19:42, Adolf Belka >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> I have figured out how to solve the problem. I have >>>>>>>>>>>>> to add "providers legacy default" into the n2n client >>>>>>>>>>>>> configuration file. >>>>>>>>>>>>> >>>>>>>>>>>>> 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. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Adolf. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 31/05/2023 17:07, Adolf Belka wrote: >>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have a blocking bug. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 29/05/2023 23:34, Adolf Belka wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I reverted those changes in next and if the >>>>>>>>>>>>>>>> build goes through I will merge the branch back >>>>>>>>>>>>>>>> into master again. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> 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) >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will also raise a bug for it and assign myself to >>>>>>>>>>>>>> it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Michael >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 26 May 2023, at 14:33, Adolf Belka >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 24/05/2023 11:02, Michael Tremer wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> On 24 May 2023, at 09:47, Adolf Belka >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 24/05/2023 10:07, Michael Tremer >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> It looks like we might not want to >>>>>>>>>>>>>>>>>>>> release the forthcoming Core Update >>>>>>>>>>>>>>>>>>>> before this. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> What other outstanding issues do we >>>>>>>>>>>>>>>>>>>> have that are currently blocking the >>>>>>>>>>>>>>>>>>>> update? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The fix for Bug#13117 has been merged >>>>>>>>>>>>>>>>>>> into master so that is no longer >>>>>>>>>>>>>>>>>>> blocking. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D7= 62c88ec4d85e3a4f7265b887f054cbe7703eb7c >>>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D8= 2822934ba769bca4235cd2a02f848cdc8511120 >>>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D0= 70abb0d011ff71e5aefd170dcb366d81bdf2497 >>>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D1= 8bece0edbd817933f48fdbffcffffd074e42c05 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> just to make sure that those don't get >>>>>>>>>>>>>>>>> missed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> These releases will be made available >>>>>>>>>>>>>>>>>>>>> on Tuesday 30th May 2023 >>>>>>>>>>>>>>>>>>>>> between 1300-1700 UTC. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> These are security-fix releases. The >>>>>>>>>>>>>>>>>>>>> highest severity issue fixed in >>>>>>>>>>>>>>>>>>>>> each of these three releases is >>>>>>>>>>>>>>>>>>>>> Moderate: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> https://www.openssl.org/policies/secpolicy.html >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yours >>>>>>>>>>>>>>>>>>>>> The OpenSSL Project Team >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>>>>> Sent from my laptop >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>>>> >>>> >> >> --=20 >> Sent from my laptop >=20 >=20 --===============5982330355289516702==--