From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: URGENT - Re: IPFire 2.27 - Core Update 175 released
Date: Mon, 12 Jun 2023 15:01:47 +0100
Message-ID: <5D5A7D74-1865-43C1-B7EF-6F3FF4B6B3F1@ipfire.org>
In-Reply-To: <59987c52-5d65-72d6-8c30-5ed17db1c5f8@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8722974029965367100=="
List-Id: <development.lists.ipfire.org>

--===============8722974029965367100==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello Adolf,

> On 12 Jun 2023, at 13:43, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>=20
> Hi Michael,
>=20
> I am afraid somehow I made an error with the last patch I provided. I was s=
ure I transferred the ovpnmain.cgi file from my virtual testbed system and cr=
eated the patch for bug#13137 from that.
>=20
> However after upgrading the virtual machines I am finding that the legacy b=
its are not being applied to legacy certs but to openssl-3.x certs.
>=20
> It looks like I submitted the subroutine iscertlegacy from ovpnmain.cgi wit=
h the return values the wrong way round.
>=20
>=20
> The sub routine was issued like
>=20
> sub iscertlegacy
> {
>         my $file=3D$_[0];
>         my @certinfo =3D &General::system_output("/usr/bin/openssl", "pkcs1=
2", "-info", "-nodes",
>         "-in", "$file.p12", "-noout", "-passin", "pass:''");
>         if (index ($certinfo[0], "MAC: sha1") !=3D -1) {
>                 return 0;
>         }
>         return 1;
> }
>=20
> but it should have been
>=20
> sub iscertlegacy
> {
>         my $file=3D$_[0];
>         my @certinfo =3D &General::system_output("/usr/bin/openssl", "pkcs1=
2", "-info", "-nodes",
>         "-in", "$file.p12", "-noout", "-passin", "pass:''");
>         if (index ($certinfo[0], "MAC: sha1") !=3D -1) {
>                 return 1;
>         }
>         return 0;
> }
>=20
> I don't know how I managed to do that error but I did.

No reason to panic. The good thing is that everything will continue working u=
nless people edit their connections.

I have taken your change and committed it:

  https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D0ebb271d1ec8b=
68f73dbd396b0f3a0aa4a50a501

> How can we deal with that now?

I will start a build and as soon as that is done, I will replace the updater.

Then there is the problem with the installation images. Replacing those is pa=
inful and therefore I am not going to do it. The chaos wouldn=E2=80=99t be wo=
rth it. Because generally creating connections on a new system and importing =
it to any other that is properly patched (or a new one that isn=E2=80=99t pat=
ched) should be working fine.

That only leaves us with a very small amount of people being affected by this=
 in real terms. For those we will have to ship this change again with the nex=
t update and then everything is cool.

So, no need to panic. Bugs happen. We had a review process and didn=E2=80=99t=
 catch it. That=E2=80=99s why we have updates :)

-Michael

>=20
> Sorry,
> Adolf.
>=20
>=20
> On 12/06/2023 12:45, IPFire Project wrote:
>> IPFire Logo
>> there is a new post from Michael Tremer on the IPFire Blog:
>> *IPFire 2.27 - Core Update 175 released*
>>    Finally, the next update, IPFire 2.27 - Core Update 175, has been relea=
sed! It updates OpenSSL to the 3.1 branch, features a kernel update as well a=
s a large number of package updates and a variety of bug fixes.
>> Click Here To Read More <https://blog.ipfire.org/post/ipfire-2-27-core-upd=
ate-175-released>
>> The IPFire Project
>> Don't like these emails? Unsubscribe <https://people.ipfire.org/unsubscrib=
e>.


--===============8722974029965367100==--