Last time I was starting vanishing of Ethan Carter, but even though it was playable, the experience wasn't free of stutters, whereas windows ran flawlessly.
In any case, it is always nice to jump back and check out how far Linux has come.
I'm of course ignoring the fact that a lot of Linux distros still do not have Secure Boot enabled by default, and therefore do not enforce any kernel driver signing policy.
Can the same certificate be used to cause supply chain attacks?
As for Windows packages, there are several "package" systems:
- AppInstaller (winget): A SHA256 hash is included in the application manifest. I might be wrong, but I do not believe the manifests are signed afterwards. Packages are verified upon installation.
- MSIX packages: They are signed and timestamped with a publisher certificate. They are verified upon installation.
- Executables: Not really packages as such, but PS1 scripts and .EXE executables support Authenticode signatures. They are verified upon execution.
As for Linux, there are several package systems:
- DPKG/DEB: Built-in support for verification with hashes generated at install time. Packages can be GPG signed for stronger security, but it is disabled by default. Repository metadata is often GPG signed.
- RPM: Like DEB above it supports verification with MD5. It also has GPG integration. I believe it is disabled by default as well.
Linux does unfortunately not have support for signatures of ELF executables.
Fortunately. This whole pseudo security brings nothing.
People scream about right to repair. When certificate is revoked or has expired your computer will stop working. It's that simple.