Hello Jon,
Well, technically yes. We could simply create an “add-on” which makes the required change and then disappears after it has been installed once.
However, that would probably be a lot of hassle for only very few users actually installing it. So I won’t go down this route.
So far we didn’t have any complaints which means that we caught the problem quick enough for most people not noticing a thing.
Best, -Michael
On 12 Jun 2023, at 15:46, jon jon.murphy@ipfire.org wrote:
For a quick update, is it possible to create a "quick_update" add-on script?
User installs the pakfire "quick_update" add-on and the install.sh does a quick patch. It only executes the code in the install.sh if the patch is needed.
Jon Murphy jon.murphy@ipfire.org
On Jun 12, 2023, at 9:01 AM, Michael Tremer michael.tremer@ipfire.org wrote:
Hello Adolf,
On 12 Jun 2023, at 13:43, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
I am afraid somehow I made an error with the last patch I provided. I was sure I transferred the ovpnmain.cgi file from my virtual testbed system and created the patch for bug#13137 from that.
However after upgrading the virtual machines I am finding that the legacy bits are not being applied to legacy certs but to openssl-3.x certs.
It looks like I submitted the subroutine iscertlegacy from ovpnmain.cgi with the return values the wrong way round.
The sub routine was issued like
sub iscertlegacy { my $file=$_[0]; my @certinfo = &General::system_output("/usr/bin/openssl", "pkcs12", "-info", "-nodes", "-in", "$file.p12", "-noout", "-passin", "pass:''"); if (index ($certinfo[0], "MAC: sha1") != -1) { return 0; } return 1; }
but it should have been
sub iscertlegacy { my $file=$_[0]; my @certinfo = &General::system_output("/usr/bin/openssl", "pkcs12", "-info", "-nodes", "-in", "$file.p12", "-noout", "-passin", "pass:''"); if (index ($certinfo[0], "MAC: sha1") != -1) { return 1; } return 0; }
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 unless people edit their connections.
I have taken your change and committed it:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=0ebb271d1ec8b68f73db...
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 painful and therefore I am not going to do it. The chaos wouldn’t be worth 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’t patched) 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 next update and then everything is cool.
So, no need to panic. Bugs happen. We had a review process and didn’t catch it. That’s why we have updates :)
-Michael
Sorry, Adolf.
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 released! It updates OpenSSL to the 3.1 branch, features a kernel update as well as 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-update-175-released The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.