Encryption keys after update

I have been updating for years by deleting everything but uploads, unzipping the newest stable release, and then unzipping an archive with my config.php and a couple of template files. I just set up a new survey which ran fine, and saved the responses, but then died on a 500 error page with a message that the encryption keys had changed and the data was lost.

Turns out there's an application/config/security.php file created when encryption is first used (which hasn't ever happened that I know of) that stores the keys. Due to my updating method (which is still what's suggested in the manual, by the way) I have apparently been deleting this file every month when I upgrade, and it's been regenerating. However, this is now causing the 500 error at the end of my surveys.

I've created several new ones, all with the same result. It doesn't seem to matter that no fields are encrypted, and whether the info is anonymized or not, and so on. One long text question, no storage about the participant (IP, timings, etc) and the same error.

I'm happy to save the current security.php and just make that part of what I restore, but I would need to be able to fix whatever causing the system to think I care about encryption.

Just to elaborate, NO questions have encryption set. I've found LSSodium.php which generated the error I'm seeing, and it should only be used if encryption is in place. It isn't, or at least not in any option I can see (question attributes, and I'm using an open survey, so no participants table).

Right. I've managed to just disable the sodium library, as well as the exception thrown within it. This seems to have cleared up the issue, though obviously in a temporary and probably not advisable way.

I don't think this is probably going to help much, but the edited file is attached. I see where the function to check for a valid decryption is, but not what it's checking against. Is there a field in the DB that I can delete (maybe along with security.php) and just take this back to scratch, and then save security.php during future updates?

First of all, this is the second time I've actually posted here, and you folks are right on the ball. Very impressive.

@c_schmitz : I see that the manual does say that now, but of course it didn't when I last read it. I guess it'd be an idea to check it again, especially after major version changes. I didn't think of the SMTP password, but it might be worth mentioning that no emails were being sent. It's an open survey, so no participant email address, and neither of the admin notifications is turned on. Anyhow, I'll restore the original LSSodium.php and try that for a non-kludgy fix.


@DenisChenu : That might be a good idea, but if you're just modifying it silently behind the scenes it wouldn't have helped me in this case. I basically have a zip of the stuff I need to restore, and I just delete everything except uploads, unzip the new version, and then unzip my stuff and overwrite where needed (templates, etc). Maybe I need to revisit this, but I have 5 installs going, so plucking individual files from sub-sub-sub folders (in the case of the templates) is pretty annoying. Now that I know to include security.php with my "stuff" to restore, I should be fine again, at least until the next change along these lines.

Anyhow, once again, thanks for being so quick with the solution.

I think you may be overestimating how often people read the manual when things appear to be fine. Much like terms of service and update changelogs. Unfortunate, but there it is.

That makes sense. I'm desperately looking for a way not to feel dumb.

Ideally, this could be in config.php, and that file could sit in the root. It's a pain having to not delete a file (or files) buried in the hierarchy. But that might be asking too much, as well as obviously messing with the well-organized approach.