I would feel more comfortable running curl bash from a trusted provider than doing apt get from an unknown software repo. What you are trying to do is establish trust in your supply chain, the delivery vehicle is less important.
What you said is the key infra needs to get compromise. I do not need to own the PKI that issued the certs, I just need the private key of the signer. And again, this is something that happens. A lot. A software publisher gets owned, then their account is used to distribute malware.
Not sure how else to explain this. Look at the CISA bulletin on Shai-Hulud the attacker published valid and signed binaries that were installed by hundreds of users.
"CISA is releasing this Alert to provide guidance in response to a widespread software supply chain compromise involving the world’s largest JavaScript registry, npmjs.com. A self-replicating worm—publicly known as “Shai-Hulud”—has compromised over 500 packages.[i]
After gaining initial access, the malicious cyber actor deployed malware that scanned the environment for sensitive credentials. The cyber actor then targeted GitHub Personal Access Tokens (PATs) and application programming interface (API) keys for cloud services, including Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.[ii]
The malware then:
Shai-Hulud via the GitHub/user/repos API.If I can control your infra I can alter what is a valid signature. It has happened. It will happen again. Digital signatures are not sufficient by themselves to prevent supply chain risks. Depending on your threat model, you need to assume advanced adversaries will seek to gain a foothold in your environment by attacking your software supplier. in these types of attacks threat actors can and will take control over the distribution mechanisms deploying trojaned backdoors as part of legitimately signed updates. It is a complex problem and I highly encourage you to read the NIST guidance to understand just how deep the rabbit hole goes.
Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
Signatures do not help if your distribution infra gets compromised. See Solarwinds and the more recent node.js incidents.
Yes this has risks. At the same time anytime you run any piece of software you are facing the same risks, especially if that software is updated from the internet. Take a look at the NIST docs in software supply chain risks.
As a security professional it amuses me that you think non-AI generated code is manually reviewed for security. Either you are committed to code quality or you are not. If you are you have automated testing, standard architectural patterns and vulnerability scanning. Peer reviews are great but do not scale and are far from comprehensive.
Just think of all the TPS reports you could process with that sweet setup.
I’ll just leave this here:
RALPH WIGGUM
Open source, spec-driven, and community-led. Ralph Wiggum turns AI agents into reliable builders with clear specifications, autonomous loops, and deployment-ready results.
Not only unironic but explained in the doc you referenced:
“However Rust does not prevent general race conditions.
This is mathematically impossible in situations where you do not control the scheduler, which is true for the normal OS environment.”
They were responding to the React.js vulnerability which is a 10/10 severity, sky is falling event so there really was little choice.
Moral from the original ACM paper: “The moral is obvious. You can’t trust code that you did not totally create yourself. (Especially code from com- panies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possi- bility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware mi- crocode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.”
You can tunnel over SSL with stunnel. TCP latency can be brutal though.
Looks like this happened:
OpenSSH server has had built-in support for WebAuthn keys since 8.2.
What type of key do you have. Yubikey 5 supports multiple protocols including some you can use with SSH:
SSH would need to implement webauthn to support FIDO.
I like S3 because I only pay for what I use and it has auto storage tiering.
You should name it Hawk, so people can call it Hawk-Tui.
I run Emby and MythTV on a Beelink Mini PC. It is a little pricey compared to some of the options you mentioned but not by too much. It works really well and is very quiet:
https://www.amazon.com/Beelink-SER5-5560U-500GB-Computer/dp/B0B3WYVB2D
That makes a lot of sense. Not sure how that would work on Windows where users typically run with admin credentials. Yes, I cannot modify the boot loader, but with admin credentials I can do many malicious things to your traffic in between the browser and the OS, up to and including attaching a debugger to your browser process to see kernel memory.
I know it is possible for Linux to pass secure boot in some cases, so in theory it could be possible for there to attestation on Linux systems, but this suffers from the same flaw as Windows since users have root access.
In the end the only thing this will do is prevent someone from using curl or cli tools to access a site that requires attestation. Will this prevent bots? I am not certain. You could in effect guarantee a 1-1 relationship of users to TPM/Secure Enclaves. This would slow down bot farmers, but not stop them.
Chinese bot farm with 100’s of physical smartphones -> https://youtu.be/aSESD6rm54o
Take a look at Shai Hulud. All the attacker had was the key.