[Bug 31059] New: encryption_key config entry not generated when upgrading
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 Bug ID: 31059 Summary: encryption_key config entry not generated when upgrading Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: jonathan.druart+koha@gmail.com QA Contact: testopia@bugs.koha-community.org It's required for 2FA (from bug 28786) but it's not added to koha-conf.xml when upgrading. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=28911 Depends on| |28786 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28786 [Bug 28786] Two-factor authentication for staff client - TOTP -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 Chris Slone <cslone@camdencountylibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cslone@camdencountylibrary. | |org --- Comment #1 from Chris Slone <cslone@camdencountylibrary.org> --- Confirming that this does not get added to the koha-conf.xml. For anyone looking for what to add it would be: <!-- Encryption key for crypted password or sensitive data --> <encryption_key>__ENCRYPTION_KEY__</encryption_key> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Yeah, this is an annoyance. The same problem exists for quite a few different koha-conf.xml options :/. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- We could add something to the about page and future release notes here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #4 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- We need to script that add missing entries. It could be a simple (perl) misc script that is called at the end of the debian upgrade procedure. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #5 from Chris Slone <cslone@camdencountylibrary.org> --- I think a script like that would be great. Documentation would definitely help too, as the tags for wrapping the entry, or even the need for changing the config file at all, wasn't really in the release notes for the new feature (not that I saw, anyhow). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #4)
We need to script that add missing entries. It could be a simple (perl) misc script that is called at the end of the debian upgrade procedure.
I added a sample one on bug 28911 that I used as a once-off but it would need work to be used regularly like that. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=22857 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=30649 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=33934 CC| |david@davidnind.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #7 from Jonathan Druart <jonathan.druart@gmail.com> --- And... Why not simply doing it in a db rev? Fail the upgrade until the key exists in the config: we provide info about how to generate the key and add it to the config. A people doing the Koha upgrade is supposed to know how to run a command and edit a file on the server. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #8 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #7)
And... Why not simply doing it in a db rev? Fail the upgrade until the key exists in the config: we provide info about how to generate the key and add it to the config. A people doing the Koha upgrade is supposed to know how to run a command and edit a file on the server.
Hm, I hope noone does a major update unattended, but they might get stuck on this. Also, you'd need to restart things (Plack, Apache?) would the update continue fine from there? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #7)
And... Why not simply doing it in a db rev? Fail the upgrade until the key exists in the config: we provide info about how to generate the key and add it to the config. A people doing the Koha upgrade is supposed to know how to run a command and edit a file on the server.
I think this would cause a lot of headaches, but it's an interesting point. I still like the idea of a machine-generated config file that we can update (for example via a db rev). Or... koha-conf.xml becomes a generated file. We can have a separate file for local updates, and it can be used with program logic to generate the koha-conf.xml That could automatically keep koha-conf.xml up-to-date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- I have a Catalyst app that uses Catalyst::Plugin::ConfigLoader (and Config::JFDI for non-Catalyst purposes). It's great because I have a base config.yaml file which I manage in version control, and then each instance has its own config_local.yaml file. These then get merged together with the local file overwriting the base file at app startup time. That said, that doesn't have a mechanism either for auto-generated values. But if I wanted to add auto-generated values, I'd probably introduce them via that base config.yaml file. -- Anyway, just my 2 cents -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- (One last one... I'd love to split out the Zebra config from the rest of koha-conf.xml. The majority of koha-conf.xml is actually just Zebra config. As we embrace Elasticsearch more and more, it's feeling sillier and sillier to have most of koha-conf.xml be dedicated to Zebra...) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #12 from Jonathan Druart <jonathan.druart@gmail.com> --- What I suggested with the db rev was to have a quick solution for this problem. We can of course rethink the whole thing but it's 1 or 2 hours of work vs... X days :) (In reply to Katrin Fischer from comment #8)
(In reply to Jonathan Druart from comment #7)
And... Why not simply doing it in a db rev? Fail the upgrade until the key exists in the config: we provide info about how to generate the key and add it to the config. A people doing the Koha upgrade is supposed to know how to run a command and edit a file on the server.
Hm, I hope noone does a major update unattended, but they might get stuck on this. Also, you'd need to restart things (Plack, Apache?) would the update continue fine from there?
Yes, this would be part of the "info" we will display: Generate the key using this command, copy the output to the koha-conf into the correct tag, restart everything, try the update again. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #12)
What I suggested with the db rev was to have a quick solution for this problem. We can of course rethink the whole thing but it's 1 or 2 hours of work vs... X days :)
It's not a practical solution for many Koha implementers though. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #14 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to David Cook from comment #13)
(In reply to Jonathan Druart from comment #12)
What I suggested with the db rev was to have a quick solution for this problem. We can of course rethink the whole thing but it's 1 or 2 hours of work vs... X days :)
It's not a practical solution for many Koha implementers though.
Are we stuck then? I wanted to suggest an easy to implement solution for bug 35970. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #15 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I feel having the database update stuck doesn't feel right. Printing and info and adding to the about page would be preferred... in case of the JS files I have commented there. I guess the problem is, that we might break things too much to check the about page? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |victor@tuxayo.net --- Comment #16 from Victor Grousset/tuxayo <victor@tuxayo.net> --- IIRC <encryption_key> was outside of the DB so 3rd party service passwords and sensitive data would be safe against a DB only leak (like with an SQL injection). But for the purpose of asset versioning without leaking the version of Koha, would it work to have another encryption key in the DB for that use? It doesn't matter much if it gets eventually stolen with the DB. ---- Something else: I might have missed if there is this possibility: can we count for most cases on koha-conf.xml being writable by the update process? So <encryption_key> could be populated there and the rest of the cases without write permission would need manual intervention for the upgrade. Assuming there are, it might not be that bad to have a major upgrade needed a manual intervention. Since switching the update source would already be a manual intervention. A bonus is that every install would have an out of DB key so that opens the possibility of using it in password storage so an SQL injection would have absolutely no chance in being compromised. Whereas today, even with salt and heavy hashing algorithms, It's feasible to test at least hundreds of thousands of passwords from dictionaries of the most popular ones. But that whole thing relies on counting for most cases on koha-conf.xml being writable. There are signs that it might be writable. «Or... koha-conf.xml becomes a generated file» -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- (In reply to Victor Grousset/tuxayo from comment #16)
But that whole thing relies on counting for most cases on koha-conf.xml being writable. There are signs that it might be writable. «Or... koha-conf.xml becomes a generated file»
In koha-testing-docker koha-conf.xml looks like it's writeable by the owner and the owner is the Koha user. On my servers, it looks like koha-conf.xml is owned by root. According to debian/scripts/koha-create it should be owned by root... So that's fun. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #18 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Thanks for checking David.
According to debian/scripts/koha-create
So these are regular Debian or Ubuntu package installs? These are not the RHEL/CentOS installs with homemade packaging you had at some point? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- (In reply to Victor Grousset/tuxayo from comment #18)
Thanks for checking David.
According to debian/scripts/koha-create
So these are regular Debian or Ubuntu package installs? These are not the RHEL/CentOS installs with homemade packaging you had at some point?
Yeah, recent Debian package installs. (That said, there could've been sysadmin on top that changed things later. I haven't tested actually creating a new branch on a test server.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=31180 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 --- Comment #20 from David Cook <dcook@prosentient.com.au> --- Let's follow this up on bug 31180 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31059 Saiful Amin <saiful@semanticconsulting.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42861 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org