Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

Valve (Steam) begin a direct collaboration with Arch Linux

By -
Last updated: 30 Sep 2024 at 10:33 am UTC

This is some pretty exciting news! The Arch Linux team have announced a new direct collaboration with Valve (Steam). Something that's not too surprising, since Valve do fund a lot of open source work, and SteamOS for Steam Deck is built directly on Arch Linux so working more closely together makes a lot of sense.

Posted to the Arch developer mailing list by Levente Polyak, the Arch Linux leader:

We are excited to announce that Arch Linux is entering into a direct collaboration with Valve. Valve is generously providing backing for two critical projects that will have a huge impact on our distribution: a build service infrastructure and a secure signing enclave. By supporting work on a freelance basis for these topics, Valve enables us to work on them without being limited solely by the free time of our volunteers.

This opportunity allows us to address some of the biggest outstanding challenges we have been facing for a while. The collaboration will speed-up the progress that would otherwise take much longer for us to achieve, and will ultimately unblock us from finally pursuing some of our planned endeavors. We are incredibly grateful for Valve to make this possible and for their explicit commitment to help and support Arch Linux.

These projects will follow our usual development and consensus-building workflows. [RFCs] will be created for any wide-ranging changes. Discussions on this mailing list as well as issue, milestone and epic planning in our GitLab will provide transparency and insight into the work. We believe this collaboration will greatly benefit Arch Linux, and are looking forward to share further development on this mailing list as work progresses.

[RFCs]: https://rfc.archlinux.page/

The secure signing enclave could certainly be an interesting one. What do you think Valve and the Arch team will be cooking up with that? This is something that could perhaps be a useful change for anti-cheat to have a more secure platform on Arch and so SteamOS / Steam Deck, and potentially get more games to enable it for us.


Update 28/09/24 - 14:13 UTC: Arch Linux packager and Valve collaborator Campbell Jones, mentioned to me:

The enclave is essentially intended to be a way for us to PGP-sign packages with a single signing key instead of how we do it right now, which is with one personal key per packager. It will not benefit Proton or the anti-cheat situation in any way and is completely unrelated.

Article taken from GamingOnLinux.com.
62 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. You can also follow my personal adventures on Bluesky.
See more from me
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
49 comments Subscribe
Page: «3/3
  Go to:

LoudTechie 28 Sep 2024
The enclave is essentially intended to be a way for us to PGP-sign packages with a single signing key instead of how we do it right now, which is with one personal key per packager.

My assumption is this requires building on build servers instead of building on maintainers' machines like they currently do.

Nah, in cryptography we already have a solution for that.
Key signing.
The basic idea is:
The user gets the public key of the central(root) private key.
you generate your key pair, the root key signs a file containing at least your public key and any data we want to transfer with it(signing date, name, phone number, limits, etc.), you sign your code with your key, you distribute with the signed code the signed document, the user first confirms the document with the root key, than they confirm your code with the key contained in the file.

This is how encryption works on the web.
Take for example GOL.
If you click on the lock above you find if you understand what your looking at:
Liam generated a key pair.
Google Trust Services signed his public key with their private key.
The Root key of google signed the Google Trust Services key.
Your OS or browser(if you're using a firefox fork) confirms the trust worthiness of the Root key.
hell0 28 Sep 2024
The enclave is essentially intended to be a way for us to PGP-sign packages with a single signing key instead of how we do it right now, which is with one personal key per packager.

My assumption is this requires building on build servers instead of building on maintainers' machines like they currently do.

Not necessarily. In all likelihood, the enclave will not decide whether it should sign off a package on its own. Which means there should be a way for maintainers to say "this package is authorised and should be signed". This can be done in many ways, including maintainers uploading packages they built themselves (and signed with their own key) to the enclave.

To be clear: they will likely want to move builds to dedicated servers for various reasons, but having an enclave does not make it a hard requirement.


Last edited by hell0 on 28 Sep 2024 at 10:23 pm UTC
marcoshalano 28 Sep 2024
You're not right but not that wrong either: use a single key to sign all packages is a step to create a way to generate security and consistent images for the console, something related with SBoM, I think.
But my first thought was the same as yours.
ElectricPrism 1 Oct 2024
It is nice to see Valve involved at every level of the Linux Platform. All of these improvements up and down the stack are so much more effective and optimized. It would be nice to see if Valve can solve the anti-cheat using signatures though as always I trust their intuition. They have been true stewards of the source and companions over the years.
R Daneel Olivaw 1 Oct 2024
  • Supporter
This is so fascinating. Personally just for my own selfish sake, I wish it were a different distro that wasn't rolling (I'm just ready to exit the rolling release rollercoaster), but I completely understand why they're doing this. And it's wonderful! This should do lots of great things for the linux community and gaming.
CyborgZeta 2 Oct 2024
I no longer use Arch (Arch-based, in my case), but I think it's good to see Valve continue to be good members of the community.
fenglengshun 3 Oct 2024
just general Remote Desktop stuff).
Server RDP or desktop RDP? And what issues?

(as a curious person who runs a GNOME-based RDP server)
Desktop. I mainly used Rustdesk + TeamViewer + AnyDesk, for redundancy in case of connectivity weirdness. Last I tested, unattended access is wonky on KDE and unattended login doesn't work on Wayland at all.
I won't lie, as a Bazzite user who builds my own custom image, I kind of wished that Valve would switch to a an rpm-ostree or similar infrastructure. I would love to have SteamOS images, with my own tools pre-baked in.
IMHO, OSTree is a very bloated software that steps on things that systemd can do. Even GNOME OS tries to replace it with parts of systemd.

I think that SUSE immutable systems are better focused. transactional-update seems smaller than OSTree and Snapper manages the snapshots. Moreover, in SUSE and openSUSE immutable systems you can rollback things the /etc folder, while with OSTree you only can rollback through the system images. In Aeon Desktop the automatic updates are scheduled with a systemd timer.

Finally, with Aeon Desktop you have a rolling release system, while with Fedora you have a point release system if you don't use the rawhide repo, but rawhide is nothing more than an experimental repo.

I like Fedora, but if you try Aeon Desktop, you can see that it's a lighter system than Silverblue, although the presence of x86_64-v3 packages in Aeon Desktop may be influencing.
I don't disagree that it's bloated, but it is bloated in a way that doesn't bother me and for a benefit that I think is worth it.

For me, I just don't like messy packages list. Even in a Distrobox, it bugs me when I have packages that I don't intend to use, that isn't part of the default. The biggest benefit of OSTree for me is their infrastructure- if you take a look at Blue Build system (the now independent image builder aspect of Universal Blue), the effect is that you have a semi-declarative OS image where I can cleanly and clearly put in "Take Bazzite as base, and add these packages." Then Github will build them, and keep 90 days history of them, while my devices has previous image as fallback.

What really made an impression on me was when mainline Kinoite was having an issue once. I just trace each day's image, found when the issue started, test the upstream ublue Kinoitr image of that day, then test the ublue image's upstream in mainline Kinoite... I can just say "Here, this is where the problem started, and it's likely because of this commit." That was a great bug reporting experience, likely both on my and the devs' end. I liked that, and that's why I have a strong feeling towards rpm-ostree.
const 3 Oct 2024
As I switch locations quite often and have some dedicated devices for specific jobs, repairing these issues cost me days in the last years.
I've run into the issue several times, but so far it could always be fixed with a quick pacman -S archlinux-keyring

Did you try that?
Sure, it's always the first thing to try, but sometimes even that failed. There are similar commands to try after that and at some point you might actually need to force things manually...
There were also updates where arch had already partly updated and then failed on some critical package because of an outdated keyring, but I think that has been fixed in pacman for a while now.
I also still have some machines with manjaro in play that I haven't bothered switching, yet and there you have to bother with multiple keyrings.


Last edited by const on 3 Oct 2024 at 10:26 pm UTC
pleasereadthemanual 4 Oct 2024
Desktop. I mainly used Rustdesk + TeamViewer + AnyDesk, for redundancy in case of connectivity weirdness. Last I tested, unattended access is wonky on KDE and unattended login doesn't work on Wayland at all.
Oh, well, you're probably screwed for unattended login on anything except GNOME when it comes to Wayland. There's wayvnc for Sway but there's no real unattended login for that.

I can say GNOME RDP works very well for servers on Wayland.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register