Hi Peter,
I have found that the code for the update.sh script for the Bug#11048 fix has a bug in it. The code looks for 'Encrypted' in the OpenSSL feedback for non password certs and 'error' for certs with a password.
I have found that with the OpenSSL3 version that some of the old certs without a password can end up also giving an error message so that both 'Encrypted' and 'error' are present. This means that an entry for that cert was placed in ovpnconfig twice for the same connection, once with pass and the second time with no-pass. It ends up only showing the first entry as the name is the same for both but this means that you end up with a connection with no password showing up like it has a password.
In the code grep needs to look for 'verify error' instead of just 'error' which will solve the above problem during the update.
I didn't find this when I did my testing, which I don't understand yet as I did the same sort of tests with the same sort of range of connections with and without passwords.
I think it would be a good idea to revert the patch set for the Bug Fix for Bug#11048 until I have sorted this all out and can confirm that with my testing.
Regards,
Adolf.
On 20/05/2023 09:00, IPFire Project wrote:
IPFire Logo
there is a new post from Peter Müller on the IPFire Blog:
*IPFire 2.27 - Core Update 175 is available for testing*
The forthcoming update, IPFire 2.27 - Core Update 175, is available for testing! Most noteworthy, it updates OpenSSL to the 3.1.0 branch, features a kernel update as well as other package updates and a variety of bug fixes are also included in this update.Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-175-is-available-for-testing
The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Hello Adolf,
thank you for your e-mail, your patches, and testing everything so thoroughly. Highly appreciated! :-)
Just to ensure I didn't miss anything: I interpret comment #3 in bug #13117 that this bug has been created as a follow-up to the behaviour observed in Core Update 175 (testing), related to the patchset submitted for bug #11048.
So, having amended your patchset for fixing #13117, my understanding is that that fixing #11048 does not need to be reverted anymore?
Thanks in advance for clarifying, and all the best, Peter Müller (under-caffeinated)
Hi Peter,
I have found that the code for the update.sh script for the Bug#11048 fix has a bug in it. The code looks for 'Encrypted' in the OpenSSL feedback for non password certs and 'error' for certs with a password.
I have found that with the OpenSSL3 version that some of the old certs without a password can end up also giving an error message so that both 'Encrypted' and 'error' are present. This means that an entry for that cert was placed in ovpnconfig twice for the same connection, once with pass and the second time with no-pass. It ends up only showing the first entry as the name is the same for both but this means that you end up with a connection with no password showing up like it has a password.
In the code grep needs to look for 'verify error' instead of just 'error' which will solve the above problem during the update.
I didn't find this when I did my testing, which I don't understand yet as I did the same sort of tests with the same sort of range of connections with and without passwords.
I think it would be a good idea to revert the patch set for the Bug Fix for Bug#11048 until I have sorted this all out and can confirm that with my testing.
Regards,
Adolf.
On 20/05/2023 09:00, IPFire Project wrote:
IPFire Logo
there is a new post from Peter Müller on the IPFire Blog:
*IPFire 2.27 - Core Update 175 is available for testing*
The forthcoming update, IPFire 2.27 - Core Update 175, is available for testing! Most noteworthy, it updates OpenSSL to the 3.1.0 branch, features a kernel update as well as other package updates and a variety of bug fixes are also included in this update.
Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-175-is-available-for-testing
The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
Hi Peter,
Thanks for the feedback. I appreciate it.
On 23/05/2023 00:18, Peter Müller wrote:
Hello Adolf,
thank you for your e-mail, your patches, and testing everything so thoroughly. Highly appreciated! :-)
Just to ensure I didn't miss anything: I interpret comment #3 in bug #13117 that this bug has been created as a follow-up to the behaviour observed in Core Update 175 (testing), related to the patchset submitted for bug #11048.
Bug #13117 was identified while I was working on evaluating the #11048 fix on CU175 Testing.
However #13117 applies to Core Update 175 totally separate from #11048.
So, having amended your patchset for fixing #13117, my understanding is that that fixing #11048 does not need to be reverted anymore?
It still would be good to revert #11048.
I have identified some issues I missed when putting the fix together and other feedback on CU175 Testing has flagged issues with net2net connections.
I have found a fix for some but need to solve all of them and also test them. I don't know how long that will take me and #11048 has been around for long enough that we shouldn't delay Core Update 175 because of it.
So if I create a tested confirmed solution quickly it could still be merged back into CU175 but if it takes longer it can go into CU176.
Regards, Adolf.
Thanks in advance for clarifying, and all the best, Peter Müller (under-caffeinated)
Hi Peter,
I have found that the code for the update.sh script for the Bug#11048 fix has a bug in it. The code looks for 'Encrypted' in the OpenSSL feedback for non password certs and 'error' for certs with a password.
I have found that with the OpenSSL3 version that some of the old certs without a password can end up also giving an error message so that both 'Encrypted' and 'error' are present. This means that an entry for that cert was placed in ovpnconfig twice for the same connection, once with pass and the second time with no-pass. It ends up only showing the first entry as the name is the same for both but this means that you end up with a connection with no password showing up like it has a password.
In the code grep needs to look for 'verify error' instead of just 'error' which will solve the above problem during the update.
I didn't find this when I did my testing, which I don't understand yet as I did the same sort of tests with the same sort of range of connections with and without passwords.
I think it would be a good idea to revert the patch set for the Bug Fix for Bug#11048 until I have sorted this all out and can confirm that with my testing.
Regards,
Adolf.
On 20/05/2023 09:00, IPFire Project wrote:
IPFire Logo
there is a new post from Peter Müller on the IPFire Blog:
*IPFire 2.27 - Core Update 175 is available for testing*
The forthcoming update, IPFire 2.27 - Core Update 175, is available for testing! Most noteworthy, it updates OpenSSL to the 3.1.0 branch, features a kernel update as well as other package updates and a variety of bug fixes are also included in this update.
Click Here To Read More https://blog.ipfire.org/post/ipfire-2-27-core-update-175-is-available-for-testing
The IPFire Project Don't like these emails? Unsubscribe https://people.ipfire.org/unsubscribe.
-
Adolf Belka -
Peter Müller