If encryption_key is not set in $KOHA_CONF we are raising an exception. This key was only needed for a couple of feature, but now we are using Koha::Encryption from the update DB process, and so the upgrade fails with no more info than 'No encryption_key in koha-conf.xml'. We need to provide more detail in this error.
https://lists.katipo.co.nz/pipermail/koha/2023-June/059566.html https://lists.katipo.co.nz/pipermail/koha/2023-June/059581.html Additionally the following answer can be very confusing: """ I added the lines: <!-- Encryption key for crypted password or sensitive data --> <encryption_key>__ENCRYPTION_KEY__</encryption_key> The update went through without a problem. """ https://lists.katipo.co.nz/pipermail/koha/2023-June/059582.html We must reject "__ENCRYPTION_KEY__", just in case...
Created attachment 152074 [details] [review] Bug 33934: Add more detail to 'No encryption_key in koha-conf.xml' If encryption_key is not set in $KOHA_CONF we are raising an exception. This key was only needed for a couple of feature, but now we are using Koha::Encryption from the update DB process, and so the upgrade fails with no more info than 'No encryption_key in koha-conf.xml'. We need to provide more detail in this error. Additionally we reject "__ENCRYPTION_KEY__", in case people will simple copy/paste that Test plan: Apply the patch Edit $KOHA_CONf, remove the encryption_key entry (or blank) restart_all Go to the about page and enable 2FA => warning on the about page, and 500 server-side are displaying more info about how to generate the missing entry Edit $KOHA_CONF and set the value to __ENCRYPTION_KEY__ restart_all => Same messages Edit $KOHA_CONF and set a correct value restart_all => No error, everything is working correctly
Created attachment 152075 [details] [review] Bug 33934: Add more detail to 'No encryption_key in koha-conf.xml' If encryption_key is not set in $KOHA_CONF we are raising an exception. This key was only needed for a couple of feature, but now we are using Koha::Encryption from the update DB process, and so the upgrade fails with no more info than 'No encryption_key in koha-conf.xml'. We need to provide more detail in this error. Additionally we reject "__ENCRYPTION_KEY__", in case people will simple copy/paste that Test plan: Apply the patch Edit $KOHA_CONf, remove the encryption_key entry (or blank) restart_all Go to the about page and enable 2FA => warning on the about page, and 500 server-side are displaying more info about how to generate the missing entry Edit $KOHA_CONF and set the value to __ENCRYPTION_KEY__ restart_all => Same messages Edit $KOHA_CONF and set a correct value restart_all => No error, everything is working correctly Signed-off-by: David Nind <david@davidnind.com>
Testing notes (using KTD): 1. After removing the <encryption_key> entry in /etc/koha/sites/kohadev/koha-conf.xml and restarting, there is: - a warning in About Koha > System information about the encryption key missing - after enabling the TwoFactorAuthentication system preference, got to 'Manage two-factor authentication' for the koha user - you should get an error message pop up when trying to set up 2FA 2. If you try to add <encryption_key>__ENCRYPTION_KEY__</encryption_key> you will also get the warning and error message. 3. Changing __ENCRYPTION_KEY__ to something else will remove the warning and let you set up 2FA.
Created attachment 152076 [details] [review] Bug 33934: Add more detail to 'No encryption_key in koha-conf.xml' If encryption_key is not set in $KOHA_CONF we are raising an exception. This key was only needed for a couple of feature, but now we are using Koha::Encryption from the update DB process, and so the upgrade fails with no more info than 'No encryption_key in koha-conf.xml'. We need to provide more detail in this error. Additionally we reject "__ENCRYPTION_KEY__", in case people will simple copy/paste that Test plan: Apply the patch Edit $KOHA_CONf, remove the encryption_key entry (or blank) restart_all Go to the about page and enable 2FA => warning on the about page, and 500 server-side are displaying more info about how to generate the missing entry Edit $KOHA_CONF and set the value to __ENCRYPTION_KEY__ restart_all => Same messages Edit $KOHA_CONF and set a correct value restart_all => No error, everything is working correctly Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
All working as described. Did we work out a better way to accomplish the DB update that was causing issues? Anyway, this can go PQA as is.. scripts happy, works clearly. Passing
Removing the example from the release notes.
(In reply to Martin Renvoize from comment #6) > All working as described. Did we work out a better way to accomplish the DB > update that was causing issues? See bug 30649 comment 35.
Pushed to master for 23.11. Nice work everyone, thanks!
Very useful change [U+1F44D]
Nice work everyone! Pushed to oldstable for 22.11.x
Please keep in mind that this key shall not be shared!
For purists, taken from Crypt::CBC -pass,-key The encryption/decryption passphrase. These arguments are interchangeable, but -pass is preferred ("key" is a misnomer, as it is not the literal encryption key). So our "encryption key" is a misnnomer too :) It is a passphrase used to generate the real encryption key. We say now: We recommend one of at least 32 bytes. It should be formally at least 16 bytes (AES blocksize) in order to be safe. So 32 is fine. Shouid we enforce a minimum length in Koha::Encryption?
(In reply to Marcel de Rooy from comment #15) > For purists, taken from Crypt::CBC > > -pass,-key The encryption/decryption passphrase. These arguments > are interchangeable, but -pass is preferred > ("key" is a misnomer, as it is not the literal > encryption key). > > So our "encryption key" is a misnnomer too :) > It is a passphrase used to generate the real encryption key. That's true although I think colloquially it's all right to call it the encryption key. > We say now: We recommend one of at least 32 bytes. > It should be formally at least 16 bytes (AES blocksize) in order to be safe. > So 32 is fine. Shouid we enforce a minimum length in Koha::Encryption? Probably a good idea.