This is mainly a rant post.

I have to use Zscaler on my work PC. I use Sway (Moved from Gnome -> i3 -> sway).

Whenever Zscaler is launched, I used to get a weird error “proxy server not found” but it continued to work otherwise. Now at my company, we used a proxy at one time but we shifted to a no-proxy connection recently.

So I checked all my environment variables, output of set command. Everything was fine. People said it could be because of some weird compliance issue, or kernel etc etc. After a week or so, I gave up on debugging it because most of my work was fine with the 50% functional Zscaler.

One day, I opened Gnome instead of Sway to check something else, and saw that my proxy was on. This is the proxy set in Gnome Settings, not environment file.

I initially dismissed this finding because I thought Gnome is not active during sway so it should not affect it. But then i remembered it’s possible to access the gnome settings using gsettings from any distro.

I switched to Sway, and sure enough, when I ran gsettings get org.gnome.system.proxy.http host, I could see the proxy IP. I set it to null and behold! Zscaler was working perfectly.

I’m like “Who the hell designs software like this? The application should read the environment variables, not Gnome variables!”

Anyway, this was just a reminder to software makers to kindly follow the norms. Don’t design your software for one Distro. Follow the guidelines as mentioned in freedesktop.

  • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.social
    321·
    21 hours ago

    I hear your frustration. It can be annoying. There’s a reason for it, and that’s because environment variables are limited in their use by scoping: they’re only inherited from the parent to children, and they’re pass-by-value. This means that, from a child process, you can’t influence the variables for any other sibling, or the parent. There’s no way to propagate environment variables to anyone except new children you fork.

    This is a significant limitation. There is no work around using only environment variables. It’s a large part of why applications store scalar values in files: it’s (almost) the only environmentally agnostic way to propagate information to other processes.

    Herbstluftwm has herbstclient getenv and setenv, because ostensibly every user process is a child of the window manager, and it’s a convenient way to communicate scalar changes between processes. tmux has similar commands; in both cases, the source of truth is the parent application, not the environment. gsettings is just Gnome’s version; KDE has it’s own version. I’d be surprised if Sway didn’t.

    Environment variables are great, but they’re limited, and they are simply unsuitable for purposes. They’re also insecure: anyone with the right permissions can read them from /proc. The consequence is that it can be difficult to track down where settings are stored, especially if you’re still using some component of a desktop, which tend to manage all of their settings internally.

    We do have a global solution for Linux: the kernel keyring. It’s secure, and global. It is not, however, automatically persisted, although desktops could easily persist and restore values from the keyring when they shut down or start up. Every desktop I know just keeps it’s own version of what’s essentially the Windows registry.

    It’s a mess.