Fix locale in fedora-*-minimal

[andrewdavidwong]

Qubes OS version (e.g., R3.1):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

fedora-24-minimal

---

When updating the fedora-24-minimal template, there are warnings of this type:

/etc/profile.d/lang.sh: line 19: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory

(Repeated for LC_COLLATE, LC_MESSAGES, LC_NUMERIC, and LC_TIME.)

And after the update is finished:

Failed to set locale, defaulting to C

[rustybird]

This can be fixed by installing the glibc-langpack-en package, or alternatively by running localectl set-locale LANG=C and restarting

[rustybird]

This can be fixed by installing the glibc-langpack-en package, or alternatively by running localectl set-locale LANG=C and restarting

[jpouellet]

Yeah, I noticed this too.

% env | grep LANG
LANG=en_US.UTF-8
% env | grep LC_
% strace -o trace man man > /dev/null
man: can't set the locale; make sure $LC_* and $LANG are correct
% grep locale trace                  
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "can't set the locale; make sure "..., 59) = 59
open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Changing /etc/locale.conf from LANG=en_US.UTF-8 to LANG=C also seems to work.

[jpouellet]

Yeah, I noticed this too.

% env | grep LANG
LANG=en_US.UTF-8
% env | grep LC_
% strace -o trace man man > /dev/null
man: can't set the locale; make sure $LC_* and $LANG are correct
% grep locale trace                  
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "can't set the locale; make sure "..., 59) = 59
open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Changing /etc/locale.conf from LANG=en_US.UTF-8 to LANG=C also seems to work.

[jpouellet]

@marmarek what do you think the appropriate path forward is here?

I propose installing glibc-langpack-en for fedora24 and only setting LANG=C for -minimal.

[jpouellet]

@marmarek what do you think the appropriate path forward is here?

I propose installing glibc-langpack-en for fedora24 and only setting LANG=C for -minimal.

[marmarek]

Seems like a good idea.

[marmarek]

Seems like a good idea.

[marmarek]

Hmm, looking the commit setting locale, it is done for gnome-terminal. Here are more details: #1033
But I've just checked and gnome-terminal seems to run just fine with either LANG=C or LANG=. So, maybe setting default locale isn't needed at all anymore?

On the other hand - changing this right now (as a stable update) isn't the best idea... So this would be (if at all) for Qubes 4.0. And for now LANG=C just for minimal template.

[marmarek]

Hmm, looking the commit setting locale, it is done for gnome-terminal. Here are more details: #1033
But I've just checked and gnome-terminal seems to run just fine with either LANG=C or LANG=. So, maybe setting default locale isn't needed at all anymore?

On the other hand - changing this right now (as a stable update) isn't the best idea... So this would be (if at all) for Qubes 4.0. And for now LANG=C just for minimal template.

[jpouellet]

Not the best idea because why? A desire to avoid churn for everybody for minimal benefit? Or some other reason?

[jpouellet]

Not the best idea because why? A desire to avoid churn for everybody for minimal benefit? Or some other reason?

[marmarek]

Risk of regression or other unwanted side effects - like the one with gnome-terminal mentioned above.

[marmarek]

Risk of regression or other unwanted side effects - like the one with gnome-terminal mentioned above.

[jpouellet]

Makes sense.

Sounds to me like that's an argument for just installing glibc-langpack-en instead of trying to switch to LANG=C? Or just leave this unresolved?

[jpouellet]

Makes sense.

Sounds to me like that's an argument for just installing glibc-langpack-en instead of trying to switch to LANG=C? Or just leave this unresolved?

[marmarek]

How many packages are pulled in by glibc-langpack-en on minimal template? If not many (for example just one), that's ok.

[marmarek]

How many packages are pulled in by glibc-langpack-en on minimal template? If not many (for example just one), that's ok.

[jpouellet]

Deps are small:

$ rpm -qR glibc-langpack-en
glibc = 2.23.1-11.fc24
glibc-common = 2.23.1-11.fc24
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

Install log on clean fedora-24-minimal here.

[jpouellet]

Deps are small:

$ rpm -qR glibc-langpack-en
glibc = 2.23.1-11.fc24
glibc-common = 2.23.1-11.fc24
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

Install log on clean fedora-24-minimal here.

[andrewdavidwong]

I propose installing glibc-langpack-en for fedora24

Why? Is there a problem on fedora-24? I only noticed it on fedora-24-minimal.

only setting LANG=C for -minimal

This seems preferable to installing any additional packages, especially in the minimal template. More packages, larger attack surface, right?

[andrewdavidwong]

I propose installing glibc-langpack-en for fedora24

Why? Is there a problem on fedora-24? I only noticed it on fedora-24-minimal.

only setting LANG=C for -minimal

This seems preferable to installing any additional packages, especially in the minimal template. More packages, larger attack surface, right?

[marmarek]

Why? Is there a problem on fedora-24? I only noticed it on fedora-24-minimal.

Indeed non-minimal template have glibc-all-langpacks installed.

This seems preferable to installing any additional packages, especially in the minimal template. More packages, larger attack surface, right?

I don't think glibc-langpack-en enlarge attack surface in any way (unless it would pull in some other package that would do so) - it doesn't expose any additional interface - package brings in only some data (translations), not code. IMO the only concern here for minimal template is its size, but the package is relatively small (275k compressed, about 4MB uncompressed).

[marmarek]

Why? Is there a problem on fedora-24? I only noticed it on fedora-24-minimal.

Indeed non-minimal template have glibc-all-langpacks installed.

This seems preferable to installing any additional packages, especially in the minimal template. More packages, larger attack surface, right?

I don't think glibc-langpack-en enlarge attack surface in any way (unless it would pull in some other package that would do so) - it doesn't expose any additional interface - package brings in only some data (translations), not code. IMO the only concern here for minimal template is its size, but the package is relatively small (275k compressed, about 4MB uncompressed).

[andrewdavidwong]

I don't think glibc-langpack-en enlarge attack surface in any way (unless it would pull in some other package that would do so) - it doesn't expose any additional interface - package brings in only some data (translations), not code.

But the attack surface isn't just the code; it also includes the package maintainer(s), their signing keys, development machines, etc., any/all of which could be compromised, right? (In any case, I agree that this one package doesn't make much of a difference, but ceteris paribus, it seems preferable to adhere to principles.)

[andrewdavidwong]

I don't think glibc-langpack-en enlarge attack surface in any way (unless it would pull in some other package that would do so) - it doesn't expose any additional interface - package brings in only some data (translations), not code.

But the attack surface isn't just the code; it also includes the package maintainer(s), their signing keys, development machines, etc., any/all of which could be compromised, right? (In any case, I agree that this one package doesn't make much of a difference, but ceteris paribus, it seems preferable to adhere to principles.)

[jpouellet]

While I agree that simply having utf8 errno value -> string conversions and such should be totally fine, safe utf8 handling in general is quite difficult, and if using the C locale would cause programs to handle input as ASCII and bypass utf8 handling code paths, then perhaps there is something to be said for that.

For example, my IRC client displays all unicode characters as \u1234 instead of the actual character, and this did in practice save me from some font rendering bug on OS X a while back (the details of which have been lost to memory).

• https://websec.github.io/unicode-security-guide/
• http://www.unicode.org/reports/tr36/
• http://www.unicode.org/reports/tr39/
• http://seriot.ch/resources/talks_papers/i_love_unicode_softshake.pdf
• http://seriot.ch/resources/talks_papers/20141106_asfws_unicode_hacks.pdf
• https://www.schneier.com/crypto-gram/archives/2000/0715.html#9

Unicode is just too complex to ever be secure. -- Bruce Schneier

[jpouellet]

While I agree that simply having utf8 errno value -> string conversions and such should be totally fine, safe utf8 handling in general is quite difficult, and if using the C locale would cause programs to handle input as ASCII and bypass utf8 handling code paths, then perhaps there is something to be said for that.

For example, my IRC client displays all unicode characters as \u1234 instead of the actual character, and this did in practice save me from some font rendering bug on OS X a while back (the details of which have been lost to memory).

• https://websec.github.io/unicode-security-guide/
• http://www.unicode.org/reports/tr36/
• http://www.unicode.org/reports/tr39/
• http://seriot.ch/resources/talks_papers/i_love_unicode_softshake.pdf
• http://seriot.ch/resources/talks_papers/20141106_asfws_unicode_hacks.pdf
• https://www.schneier.com/crypto-gram/archives/2000/0715.html#9

Unicode is just too complex to ever be secure. -- Bruce Schneier

[marmarek]

Updated template uploaded to the repository.

[marmarek]

Updated template uploaded to the repository.

[entr0py]

Hmm, looking the commit setting locale, it is done for gnome-terminal. Here are more details: #1033
But I've just checked and gnome-terminal seems to run just fine with either LANG=C or LANG=. So, maybe setting default locale isn't needed at all anymore?

Not sure what I'm doing differently but gnome-terminal does not run for me in fedora-24-minimal with LANG=C. Installing glibc-langpack-en, followed by localectl set-locale LANG=en_US.utf8 solves the issue. If glibc-langpack-en is left out for space considerations, perhaps a note could be added to fedora-24-minimal documentation?

Also, not to play favorites, maybe uninstall glibc-langpack-zu (South African isiZulu) from the default template? :-P

$ localectl list-locales
C.utf8
zu_ZA
zu_ZA.utf8

[entr0py]

Hmm, looking the commit setting locale, it is done for gnome-terminal. Here are more details: #1033
But I've just checked and gnome-terminal seems to run just fine with either LANG=C or LANG=. So, maybe setting default locale isn't needed at all anymore?

Not sure what I'm doing differently but gnome-terminal does not run for me in fedora-24-minimal with LANG=C. Installing glibc-langpack-en, followed by localectl set-locale LANG=en_US.utf8 solves the issue. If glibc-langpack-en is left out for space considerations, perhaps a note could be added to fedora-24-minimal documentation?

Also, not to play favorites, maybe uninstall glibc-langpack-zu (South African isiZulu) from the default template? :-P

$ localectl list-locales
C.utf8
zu_ZA
zu_ZA.utf8

[andrewdavidwong]

Also, not to play favorites, maybe uninstall glibc-langpack-zu (South African isiZulu) from the default template? :-P

$ sudo dnf remove glibc-langpack-zu
Dependencies resolved.
Error: The operation would result in removing the following protected packages: dnf, systemd.

Odd.

[andrewdavidwong]

Also, not to play favorites, maybe uninstall glibc-langpack-zu (South African isiZulu) from the default template? :-P

$ sudo dnf remove glibc-langpack-zu
Dependencies resolved.
Error: The operation would result in removing the following protected packages: dnf, systemd.

Odd.

[entr0py]

Ah, now it makes sense. I didn't get that error because I installed glibc-lanpack-en before removing zu. It must be that one langpack is required and that's why zu was not removed from the template in the first place.

[entr0py]

Ah, now it makes sense. I didn't get that error because I installed glibc-lanpack-en before removing zu. It must be that one langpack is required and that's why zu was not removed from the template in the first place.

[andrewdavidwong]

Yes, you're right. After installing glibc-lanpack-en, I was able to remove glibc-langpack-zu. Since we have to have one installed anyway by default, it might as well be glibc-lanpack-en. What do you think @marmarek?

[andrewdavidwong]

Yes, you're right. After installing glibc-lanpack-en, I was able to remove glibc-langpack-zu. Since we have to have one installed anyway by default, it might as well be glibc-lanpack-en. What do you think @marmarek?

[marmarek]

Makes sense. Interesting why glibc-langpack-zu is chosen by default...

[marmarek]

Makes sense. Interesting why glibc-langpack-zu is chosen by default...

[andrewdavidwong]

This is also a problem on fedora-25-minimal.

[andrewdavidwong]

This is also a problem on fedora-25-minimal.

[Polygonbugs]

This also applied to fedora-26-minimal.

[Polygonbugs]

This also applied to fedora-26-minimal.