61–69 of 69 posts
Earlier quoted context omitted.
Lots of projects use SPIFFE, but lots of people don't like the new tech because they think the old ways are simpler
After trying to get SPIFFE mTLS to work with Python asyncio and giving up, I'm sure "lots of projects" is an overstatement. Even basic parts of the tech stack aren't there yet.
CI/CD actions for pull/merge requests are a nightmare. When a developer writes test/verification steps, they are mostly in the mindset "this is my code running in the context of my github/gitlab account", which is true for commits made by themselves and their team members. But then in a pull request, the CI/CD pipeline actually runs untrusted code. Getting this distinction correct 100% of the time in your mental mode…
I don't think the problem is CI/CD runs on pull requests, per se : it's that GitHub has two extremely similar triggers (`pull_request` and `pull_request_target`). One of these is almost entirely safe (you have to go out of your way to misuse it), while the other is almost entirely unsafe (it's almost impossible to use safely). To make things worse, GitHub has made certain operations on PRs (like auto-labeling and lea…
Earlier quoted context omitted.
After trying to get SPIFFE mTLS to work with Python asyncio and giving up, I'm sure "lots of projects" is an overstatement. Even basic parts of the tech stack aren't there yet.
Several big CNCF security projects use it. Normally you'd just add sidecars to your asyncio service.
"Sidecars" is a crazy hack that only applies if you use k8s and containers, which I'm obviously not.
They were able to dump arbitrary file to logs. The secrets were automatically obfuscated with *** in the logs. How could they exfiltrate the token?
Earlier quoted context omitted.
My RFC was much earlier in 2018 https://github.com/NixOS/rfcs/pull/34 Lack of supply chain integrity controls as a means to reduce contribution friction to maximize the number of packages contributed is a perfectly valid strategy for a workstation distribution targeted at hobby developers. Volunteers can do what they want, so that RFC convinced me stagex needed to exist for high security use cases, as Nix was explici…
NixOS is miles better from a security standpoint than any Debian or Red Hat already, so take what you can.
See a security comparison of both with stagex: https://codeberg.org/stagex/stagex#comparison
Earlier quoted context omitted.
NixOS is miles better from a security standpoint than any Debian or Red Hat already, so take what you can.
It is way behind Debian on even the basics sadly. Maintainers do not even sign in NixOS making them easy to impersonate. Debian security is a joke too though in other areas, and like nix, should never be used in production either. See a security comparison of both with stagex: https://codeberg.org/stagex/stagex#comparison
A very hot and very wrong take.
NixOS at least has immutable read-only system images. This makes it a thousand times less interesting to a potential attacker than a Debian system.
For every Mossad agent crafting elaborate impersonation scheme to steal state secrets, there are a million script kiddies looking for insecure servers for a botnet.
P.S. A bigger issue is the complete inability of the "security industry" to understand even basic threat model issues. More proof that this entire "industry" is a joke and a clown show.
Earlier quoted context omitted.
Emacs itself is probably secure and you can easily audit every extension, but if you update every extension blindly via a nicely composable emacs Nix configuration, you would indeed have a problem. I guess one could automate finding obvious exploits via LLMs and if the LLM finds something abort the update. The right solution is to use Coq and just formally verify everything in your organization, which incidentally me…
Formal verification solves nothing. You can have a formally verified 100% secure backdoor exploit. (Ultimately it all depends on the semantics of "sysadmin" vs "hacker", who are really just two different roles of the same person.) This is also why signing code commits isn't a solution, only a way to trace ends when something fucks up.
The specification for a text editor would be much simpler than an implementation. For example, efficiently searching for a substring is non-trivial, but a specification is easy. So, all that I would be interested in, is a proof that "eval(optimized_substring_search needle haystack) = eval(easy_substring needle haystack)", for example. Obviously, there are many thousands of such theorems that would have to be done to clone Emacs, but at least a new release wouldn't contain bugs anymore (wrongly specifying something would happen, but it's much easier to write a specification of desired behavior than to find the exact bug in some mess from someone else, because it conflates implementation and specification in the first place).
Earlier quoted context omitted.
Formal verification solves nothing. You can have a formally verified 100% secure backdoor exploit. (Ultimately it all depends on the semantics of "sysadmin" vs "hacker", who are really just two different roles of the same person.) This is also why signing code commits isn't a solution, only a way to trace ends when something fucks up.
Formal verification would solve everything. It's just that whoever is using the software actually needs to understand the specification, but when there is some trusted base of I/O primitives (like "read a file"), such things become trivial to check; even Haskell has such things in a limited fashion via SafeHaskell and to an even lesser extent via its IO monad. The specification for a text editor would be much simpler…
Earlier quoted context omitted.
Formal verification would solve everything. It's just that whoever is using the software actually needs to understand the specification, but when there is some trusted base of I/O primitives (like "read a file"), such things become trivial to check; even Haskell has such things in a limited fashion via SafeHaskell and to an even lesser extent via its IO monad. The specification for a text editor would be much simpler…
You completely, 100% misunderstood my comment.
Your point is that users are too stupid/lazy to comprehend specifications. That is, they won't bother to read that the specification of their formally verified secure version of Google Maps really just copies their credit card data to a random server.
I just don't agree.