On Wed, 21 Dec 2022 at 18:15:11 +0100, Adam Borowski wrote: > On Mon, Dec 19, 2022 at 07:08:09PM +0000, Simon McVittie wrote: > > On Fri, 16 Dec 2022 at 19:21:37 +0100, Adam Borowski wrote: > > > * The execution environment (usually init system or a container) must > > > default to UTF-8 encoding unless explicitly configured otherwise. > > > > Is this already true? This seems like the sort of thing which should be > > fixed in at least the major init systems and container managers before it > > goes into Policy, in the interests of not making those init systems and > > container managers retroactively buggy. > > I'm less knowledgeable about containers, but they appear to work. It might > be due to copying variables from the host or having template defaults...
There are three major categories of container that I'm aware of: 1. Full-system containers like lxc/lxd run a complete init system like systemd or sysv-rc for the container (they aim to behave like a lighter-weight alternative to VMs), so their init system would be responsible for making this work. This seems non-problematic for your proposed requirement: if an init system does the right thing on bare metal or in a VM, it will also do the right thing in lxc containers. 2. Per-service containers like the upstream-recommended use of Docker either have no init system at all, or a minimal reaper process like tini (they aim to behave like a heavier-weight alternative to chroots). chroot managers that have subsequently gained namespace functionality, like some uses of pbuilder and schroot, also work like this. I think these are the category that is most likely to have trouble complying with the requirement you propose, because the container manager is intentionally "hands-off" (mechanism more than policy), while the processes run inside the container are not under Debian's control (they are chosen by whoever wrote the Dockerfile or equivalent, and might come from either Debian or another distribution). 3. Per-app containers like Flatpak and Snap are not intended to emulate a whole system, so they are expected to inherit locale settings from the host system like a non-sandboxed app would. They shouldn't be a problem here, as long as your proposed requirement is worded in such a way that it is valid for these container managers to rely on the host system locale being correct (in other words, if someone using the legacy en_GB locale reports a bug "flatpak: does not set a UTF-8 locale", I should be able to close it with "This is not flatpak's job, set your host system locale to en_GB.UTF-8 instead"). podman and systemd-nspawn can be used as either the first category (like lxc) or the second (like Docker), depending how they were invoked. > Anyway, my aim is more to tell packages that they are allowed to misbehave > when the settings are missing than to hunt misuse scenarios. But, if such > a scenario is found, with the current Policy there is no recourse, while > if this rule is added it would be a bug. Not every bug necessarily needs to be a Policy violation. > I just tested Windows 11 notepad.exe: it defaults to UTF-8, and when > saving it allows "ANSI" "UTF-16 LE" "UTF-16 BE" "UTF-8" (default) and > "UTF-8 with BOM". Yes, that's the sort of UX that I think needs to be allowed. I would personally not expose that choice in the UI of an intentionally simple text editor like Notepad or gnome-text-editor, but I would expect similar behaviour in an editor with more elaborate programmer-oriented features, like vim, emacs, gnome-builder or kate. If iconv(1) or a similar program has an option for "UTF-8 with BOM" then that also needs to not be accidentally declared to be a Policy violation. smcv