Hi,
I had a LEAP 42.3 distro and made a smooth upgrade to LEAP 15.0 using the online method. That is making a simple update of the repo’s and zypper dup the thing as explained in the documentation and not a clean install as I used to do for a long long time.
All went well until I tried to decrypt some gpg files I had on my pc since maybe version 12 something of OpenSuSE. Inever had a problem in OpenSuSE decrypting those files.
The files were encrypted with the symmetric method, no keys needed.
There are Multiple problems I was detecting while trying to debug this very serious problem.
I will report some but those are not the subject of this thread.
– First choosing in yast language and Portuguese does not work.
since when I log into a bash session and make:
bash$ locale -a
shows the option pt_PT.utf8
but on the cli/bash the command locale shows that there is no such pt_PT.utf8, but rather pt_PT.UTF-8 … this is a potential bug for the distro.
and the error
setlocale: LC_TYPE: cannot change change Locale (en_US.UTF-8, pt_PT.UTF-8) no such file
shows up every time I log either in X mode on in the terminal text mode (ctrl+alt+F1).
For me there is no problem since my keyboard layout is correct, Portuguese, and I never had problems using en_US.UTF-8 as the cahr set anyway. I just found the problem.
Second:
I noticed that everytime I log there is error on LC_CTYPE locale line since the default locale shows that :
LC_CTYPE = en_US.UTF-8, LC_ALL=en_US.UTF-8
that line is a bug for sure!
So I had to place in my ~/.profile the change on environment variables so I added the line:
export LC_ALL="en_US.UTF-8"
and now the correct locale shows up like:
:~> locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
The problem:
But the reason that brought me here was other.
I use accented characters on my passphrase. Always did. As well as some altgr characters and also of course shift+altgr and shift+accented characters.
That is, to expand a LOT the amount of characters space on symmetric gpg encrypted files.
Since if one only uses ascii words the amount of chars on that space is very limited.
(upper case, lower case, symbols on the keyboard).
I always add a lot of UTF-8 characters:
Namely using the altgr, altgr, and specially Composed characters. Meaning symbol+chars, symbol +shift+characters.
This increases very very much the amount of chars available and makes the passpharse way stronger the simply using ascii characters.
The problem is I upgraded from LEAP 42.3 to 15.0 and now none of my gpg encrypted files opens 
The result is always the dreadful bad session key … meaning …wrong passphrase.
This happened to me a LOT when moving such files and trying to open between different distros and computers since of course compose characters and altgr support varies once we change keyboard layout and specially Locale settings.
the strange thing is that I think this is solelly a problem of pinentry since I can see the characters I use when typing on the bash prompt.
I even used cli password entry did not work:
gpg -d --batch --passphrase ‘password’ encrypted_file
using a new file encrypted without algr and/or composed chars worked fine as expected with both pinentry and cli entry mode.
I also made a test that is using pinentry-curses.
Simply place a :
pinentry-program /usr/bin/pinentry-curses
on the file ~/.gnupg/gpg-agent.conf
and the ncurses version shows up with a strange behavior:
Every time I type a altgr or accented char the cursor moves two asteriscs on that prompt. As if pinentry does not even recognize or uses the system locale and does not understand a accented/altgr character!
(same for the other with shift+altg and shift+symbol+char).
Can anyone know what is going on with this strange behavior?
And don’t feel rushed to help guys 
I’m certain that my electricity provider company at the end of this month is going to fully understand when I call the late payment department saying:
"… I have my bank access codes inside a symmetric encrypted file with gpg, but there’s an issue with Character set encoding with gpg-agent or pinentry not fully acquiring environment variables to correctly translate keyboard strings of unicode UTF-8 input characters … I wonder if you guys don’t have a decryption department with multiple peta/exa-hash brute force capability since at least you guys have the electricity to run that thing … "
I’m truly sure they’ll be delighted to hear that.
Regards.
since changing that still did not solve my gpg encryption problem not even close.