> It's pretty clear that the security models that were design into operating systems never truly considered networked systems
Andrew Tanenbaum developed the Amoeba operating system with those requirements in mind almost 40 years ago. There were plenty of others that did propose similar systems in the systems research community. It's not that we don't know how to do it just that the OS's that became mainstream didn't want to/need to/consider those requirements necessary/<insert any other potential reason I forgot>.
Yes, Tanenbaum was right. But it is a hard sell, even today, people just don't seem to get it.
Bluntly: if it isn't secure and correct it shouldn't be used. But companies seem to prefer insecure, incorrect but fast software because they are in competition with other parties and the ones that want to do things right get killed in the market.
Developers will militate against anything that they perceive to make their life difficult, eg anything that stops them blindly running ‘npm get’ and running arbitary code off the internet.
Well yeah, we had to fix some LLM that broke things at a client; we asked why they didn't sandbox it or whatever and the devs said they tried to use nsjail; could not get their software to work with it, gave up and just let it rip without any constraints because the project had to go live.
It's similar in spirit, but in Dafny one can express much more complicated and complex invariants which get checked at build time -- compared to eiffel where pre/post conditions are checked at runtime (in dev builds mostly).
Interestingly, though, you can have some runtime checking with Dafny as well as the formidable dependent type checking and formal verification that happens at build time.
That means that most of the proof can be done ahead of time with just some loose ends verified using an SMT prover at runtime.
They already charge for this separately (at least storage). Some compute cost may be justified but you'd wish that this change would come with some commitment of fixing bugs (many open for years) in their CI platform -- as opposed to investing all their resources in a (mostly inferior) LLM agent (copilot).
- github copilot PR reviews are subpar compared to what I've seen from other services: at least for our PRs they tend to be mostly an (expensive) grammar/spell-check
- given that it's github native you'd wish for a good integration with the platform but then when your org is behind a (github) IP whitelist things seem to break often
- network firewall for the agent doesn't seem to work properly
raised tickets for all these but given how well it works when it does, I might as well just migrate to another service
- Strong background in systems engineering, performance testing, or site reliability engineering.
- Fluency in Python and Linux fundamentals. Rust experience is a plus.
- Experience with distributed systems and database concepts (consistency, fault tolerance, transactions).
- Experience with CI/CD/Infrastructure as Code: GitHub Actions, Docker, Kubernetes.
- Hands-on experience running large-scale and long-running workloads, preferably in a cloud-native environment.
- Curiosity, rigor, and the ability to design experiments that simulate messy real-world conditions.
- 5+ years experience in solution architect, customer engineering or solution engineering roles.
- Strong background in distributed systems, databases, cloud infrastructure, and modern data platforms.
- Experience with data-intensive systems in production (e.g., Kafka, Delta Lake, Iceberg, Kubernetes, monitoring/observability stacks).
- Exceptional debugging and problem-solving skills, especially in customer-facing contexts.
- Excellent communication skills, both for customer-facing and internal interactions.
- Ability to write and maintain high-quality technical docs and playbooks.
Unfortunately, it's quite a big mess (as the article indicates), which leads to a steep learning curve for someone who "just wants to build some images".
And that's just half of it. Want to build an image on two native architectures (ARM64 and AMD64) and then make a multi-arch image out of them. Might blow someones mind on how complicated that is with 2025 docker technologies: https://docs.docker.com/build/ci/github-actions/multi-platfo...
Correct me if I'm wrong, but the problem here is not with GitHub Apps, instead CodeRabbit violated the principle of least privilege: ideally the private key of their app should never end up in the environment of a job for a client but rather a short lived token should be minted from it (for just a single repo (for which the job is running)) so it never gets anywhere near those areas where one of their clients has any influence over what runs.
There's also no reason why they needed to have write access to post code review comments. But for some reason they ask for it and you can't deny that part when hooking up their thing.
The bunny will often include patches in its replies that the PR author can commit. I've never been clear as to which of us is doing the committing but that could be the need for write access. (I always do it myself but I can see how some might prefer the convenience.)
They should really mass revoke that privilege because I can't see any upside to it. Unless they have a plan for some future state where they will want write access?
I agree, this seems like straight up bad design from a security perspective.
But at the same time, me as a customer of Github, would prefer if Github made it harder for vendors like CodeRabbit to make misstakes like this.
If you have an app with access to more than 1M repos, it would make sense for Github to require a short lived token to access a given repository and only allow the "master" private key to update the app info or whatever.
And/or maybe design mechanisms that only allow minting of these tokens for the repo whenever a certain action is run (i.e not arbitrarily).
But at the end of the day, yes, it's impossible for Github to both allow users to grant full access to whatever app and at the same time ensure stuff like this doesn't happen.
The private key isn’t a key in the “API KEY” sense, it’s a key in the “public/private key pair” sense. It’s not sent to github and there’s no way for them to know if the signing of the token used to make the call happened in a secure manner or not, because github doesn’t receive the key as part of the request at all.
GH Apps already use short-lived tokens that can be scoped per repo. You mint a token using your private key and exchange it for a token via API. Then you use that token and dispose of it. That's the only way to use GH Apps (User Access Tokens which are the same thing, but require user interaction) Those tokens always expire.
I'd rather GitHub finally fix their registry to allow these GH Apps to push/pull with that instead of PAT.
What "most" cases are you thinking of? Also don't forget that a binary that in release weights 10 MB, when compiled with debug symbols can weight 300 MB, which is way less practical to distribute.
Andrew Tanenbaum developed the Amoeba operating system with those requirements in mind almost 40 years ago. There were plenty of others that did propose similar systems in the systems research community. It's not that we don't know how to do it just that the OS's that became mainstream didn't want to/need to/consider those requirements necessary/<insert any other potential reason I forgot>.
reply