Mailpile password not accepted after system upgrade

[JackDca]

Symptoms:

My "production" Mailpile has been running on my old Debian Stretch system for years. I recently created a new Debian Buster system (not a dist-upgrade). I made sure that the user numbers in the new Buster/etc/passwd matched the ones in the old Stretch system. Then I copied my entire home directory, including the Mailpile program directory and homedir, from the old system disk image to corresponding places in the directory hierarchy of the new system. The Mailpile program is the latest master from Github and uses virtualenv. The homedir was first set up in 2017 and its Mailpile password has never been changed.

When I ran Mailpile on the new system, the web interface returned "Oops, wrong password. Try again?".

I then exited Mailpile and ran it again, but this time attempted to log in with the CLI instead of the web interface. The CLI gave me

Bad passphrase for None
login error: Invalid password, please try again
Elapsed: 16.046s (login: Invalid password, please try again)

{
    "login_banner": "", 
    "login_failures": [
        1612190878, 
        1612191572
    ]
}

However, when I tried using a different homedir copied from the old Stretch system (a small one that I created in 2018 and whose password has been changed at least once since then), its password was accepted and Mailpile functioned normally on the new Buster system.

I tried a using new copy of the Mailpile program, checking it out from Github and setting up a new virtualenv. This did not correct the problem with the "production" Mailpile password.

Workaround:

I booted the old Stretch disk image, ran Mailpile, changed the Mailpile password, shut down, and copied the workdir from the old Stretch system to the new Buster system, which I then booted. Now the new password is accepted and my production Mailpile runs normally on Buster.

Conclusion:

A Mailpile password created with an old version of Mailpile on one version of an OS may not be accepted if the homedir is copied to a system with a different version of the OS. The problem was corrected (in this case!) by changing the Mailpile password using the current version of Mailpile on the old OS before copying the homedir to the new system. It was fortunate that I had kept a bootable copy of the old Stretch disk image! Otherwise there would have been no obvious way to recover.

It is desirable for the Mailpile homedir to be relocateable since the user may want to copy it for backup or system upgrade purposes, as mentioned in the discussion on #2233.

Possible cause:

Even in a virtualenv setup, Python uses the OS's copies of Python modules if they are available. Also it uses non-Python packages like GnuPG and OpenSSL. Possibly one or more of these packages was updated between the time in 2017, when the password was created, and the present. This may have had the observed effect. Still, it is strange that periodic updates to the packages and to the Mailiple code on the old Stretch system did not cause a problem.

[JackDca]

I just reread #2038 Broken locale causes invalid password? which also involved moving the homedir to another environment. Could this actually be caused by the same problem that is reported here, not the "broken locale"?

[h3artbl33d]

Does the console of your browser (assuming you use Mailpile through the web interface) throw any errors?

[JackDca]

Good question, I didn't think to look. I now am no longer in a position to reproduce the problem.

However, as mentioned above, the CLI login command also gave an error. (I have edited my original post to clarify this.) So I don't think it's the web interface.

[h3artbl33d]

Ah, right. I had a login issue with a proxied instance (nginx reverse proxy), due to some internal changes in recent Chromium versions. But that is unrelated if you had the error in the CLI as well.

As to the issue itself, I am curious to what caused it. I agree that an upgraded dependency (whether a Python module or something like GPG/OpenSSL) is likely. But right now, it is merely guesswork.

[JackDca]

Further details:

For unrelated reasons, I wanted to restore and work with an old backup of my production Mailpile homedir, one which preceded the password update and upgrade to Buster described above. I was no longer able to boot my old Stretch system.

I restored the old homedir backup to a directory on my new Buster system, ran Mailpile on the restored homedir and tried to log in with the old password. As would be expected, this yielded an Invalid password result. Then I copied file mailpile.key from the production Buster homedir to the restored homedir, and ran Mailpile on the restored homedir. Now I was able log in with the new password.