You are not logged in.
Pages: 1
For those who didn't see the news:
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/
I think this is super interesting, but I have some questions, mostly about the "secure signing enclave" mentioned there. That's not a term I'm familiar with. Can anyone in the know shed more light on that? Is that related to the build service infrastructure, and more generally is there an overarching goal for this collaboration?
I can surmise that this is all related to SteamOS, but what specifically is Valve hoping to get from this?
Offline
Found on another discussion (video, 42 minutes): https://media.ccc.de/v/all-systems-go-2 … nvironment
I have not watched it yet.
Offline
Valve wants a more rebust chain of trust for the packages it uses and maybe quicker / reliable updates.
The combination of a build service with the secure signing enclave will mean that package maintainers can submit a changed PKGBUILD to the build server and it automatically builds and signs the package ready for inclusion in a repository.
No need for maintainers to build on their own machines or develop their own automation tooling for builds. A simple build server already exists, but that simply provides resources, as in bring your own build automation tools and signing has to be done manually by the maintainer.
Edit: That video should explain it better, though.
Last edited by progandy (2024-09-28 10:13:25)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
I see, that makes sense.
Offline
Pages: 1