https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078
--- Comment #3 from David Cook <dc...@prosentient.com.au> --- (In reply to Victor Grousset/tuxayo from comment #2) > > The tricky thing is that we don't currently have a way of noting which key > > was used to encrypt which field. > > As long as there is one key at the time, it's not needed. The update process > should be one transaction to guaranty that though. That's not going to scale. If you have a large number of amount of data, that's going to be slow, require downtime, and potentially put unnecessary load on the database server. Large transactions are rarely a programmer's friend. That said, it would be easier in the short-term and for small databases. So certainly better than nothing. > > However, we have no easy way to change key should that key be leaked or > > found to be to simple to crack > > > It's generated so cracking shouldn't be an issue. As for a leak, yes a > webserver misconfiguration or a vulnerability in Koha or another app on the > same server could expose the config file while still having the DB unleaked. Theoretically we might learn of new computing methods that mean the generated key is too weak, and we need to employ a different algorithm. What Martin is saying is that there's no way to currently re-encrypt using a stronger/unknown key. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
