After OAuth2 setup for accounts all passwords started to show incorrectly. Lengths of the passwords became too big. It's also a problem to decode passwords from passwordstorerc and passwordstorerc.bak using old method for such accounts. Unsetting OAuth2 also don't help to recover passwords.
You seem only to be describing what is expected to happen. Where are these passwords shown? If you think you are not mistaken, please explain your points in greater detail.
>Where are these passwords shown? Configuration -> Edit accounts... -> Edit {preferences of any selected account after OAuth2 setup} -> Basic -> Password {under Server information with Protocol: POP } -> {Click} Show password. The result is wrong long password there. I only chose OAuth2 for receiving (not sending) ATM. Sending is left with Authentication method: Automatic. I didn't select master passphrase also: use_master_passphrase=0 session_passwords=0 master_passphrase= but there are not empty long master_passphrase_salt=... and master_passphrase_pbkdf2_rounds=50000 inside ~/.claws-mail/clawsrc. There are also the following long strings under [account:7] inside ~/.claws-mail/passwordstorerc: oauth2_access_expiry {AES-256-CBC,50000}... recv {AES-256-CBC,50000}... send {AES-256-CBC,50000}... oauth2_refresh {AES-256-CBC,50000}... Accounts with OAuth2 no longer have short passwords started with "recv !". Unfortunatelly I couldn't recover password from this account:7 even after reading https://git.claws-mail.org/?p=claws.git;a=blob;f=doc/src/password_encryption.txt;h=f618378d3e2349e8b277053f7bcfa8d3f1e0c0ae;hb=3674865761a7d909ac4bff505a624b175d842c41 Old method to decrypt doesn't work for AES-256-CBC: https://github.com/b4n/clawsmail-password-decrypter I tried first to use openssl in shell for decryption: openssl base64 -d -nosalt -nopad -in passwordstorerc|openssl enc -d -aes-256-cbc -nosalt -nopad -pbkdf2 -iter 50000 -K 706173736b6579300a -iv $(openssl rand -hex 8) -p But something is wrong with it. Maybe because of shell don't have binary variables like in Python (PASSCRYPT_KEY = b'passkey0').
what does /Tools/Network Log say about your connection negotiation?
All connections there work without any problems (OAuth2 and simple ones) except account:7, which is expired after 7 days ("Authorizations by a test user will expire seven days from the time of consent." https://support.google.com/cloud/answer/10311615#publishing-status&zippy=%2Ctesting ) and I couldn't recover password for it. Do you need network logs for some accounts?
So if everything works, where is the problem again?
>So if everything works, where is the problem again? All passwords for OAuth2 accounts are shown incorrectly inside Configuration -> Edit accounts... -> Edit {preferences of any selected account after OAuth2 setup} -> Basic -> Password {under Server information with Protocol: POP } -> {Click} Show password. The result is wrong long passwords there. The real passwords are short and different and I can login using web Google interface with short passwords (except account:7 for which I couldn't recover it). But I can't get real password for account:7 from Account preferences UI. Other passwords for OAuth2 accounts I've got from very old backup of ~/.claws-mail/accountrc (they were represented there in "password=!..." old form base64 using DES.MODE_CFB). I usually used Account preferences UI "Show password" to get passwords. But after OAuth2 setup it's no longer possible due to incorrect representation there.
I think this is just the intended behaviour of OAuth2 being seen. A user's password is no longer stored when using OAuth2. The password field is instead used to store the OAuth2 token, which is of limited time validity and specific to just a mail login, therefore probably of lower security value than the original password. The OAuth2 token is usually much longer than the original password. Decoding an OAuth2 token will not retrieve the original password. The only way I can see this being a real bug is if the OAuth2 token is so long that the password field cannot accommodate and store it correctly. If that's happening it would require a fix to lengthen the maximum string length that field could store. (Posts on the Users mailing list indicate that this is not what's happening)
>The only way I can see this being a real bug is if the OAuth2 token is so long that the password field cannot accommodate and store it correctly. The length of this field is OK. Although it doesn't store password anymore. So, it probably should be renamed as OAuth2 token. >A user's password is no longer stored when using OAuth2. Is there any way to restore password for account:7 back? If there's no any ways to do that then you probably should inform users that their passwords will be erased after migration to OAuth2. I tried to restore settings of account:7 by removing any OAuth2 settings in options of account and its password still hasn't been backed.
At least inform users on OAuth2 FAQ page that they will loose passwords from their accounts. And it is better to backup passwords from accounts before migrating into OAuth2. https://www.claws-mail.org/faq/index.php/Oauth2