I don't have much experience with GitHub's CI offering. But if this is an accurate description of the steps you need to take to use it securely ... then I don't think it can, in fact, ever be used securely.
Even if you trust Microsoft's cloud engineering on the backend, this is a system that does not appear to follow even the most basic principles of privilege and isolation? I'm not sure why you would even try to build "supply-chain security" on top of this.
I would agree with this. I recently tried to figure out how to properly secure agent-authored code in GitHub Actions. I believe I succeeded in doing this[1] but the secure configuration ended up being so delicate that I don’t have high hopes of this being a scalable path.
Now, as other commenter pointed out, maybe this is just inherent complexity in this space. But more secure defaults could go a long way making this more secure in practice.
Out of curiosity, is there a build setup you have seen in the past that you think could be a good replacement for this complex GitHub CI setup? Asking for a friend ;)
Update: now I've finished reading the article, my impression is that complexity is mostly inherent to this problem space. I'd be glad to be proven wrong, though!
I think any of the webhook-based providers are better, because you can isolate your secrets. PRs go to a PR webhook that runs in an environment that just doesn’t have access to any secrets.
Releases go to the release webhook, which should output nothing and ideally should be a separate machine/VM with firewall rules and DNS blocks that prevent traffic to anywhere not strictly required.
Things are a lot harder to secure with modern dynamic infrastructure, though. Makes me feel old, but things were simpler when you could say service X has IP Y and add firewall rules around it. Nowadays that service probably has 15 IP addresses that change once a week.
The complexity comes from how the whole system is designed.
There’s no single repository or curated packages as is typical in any distribution: instead actions pull other actions, and they’re basically very complex wrapper around scripts which downloads binaries from all over the place.
For lots of very simple actions, instead of installing a distribution package and running a single command, a whole “action” is used which creates and entire layer of abstraction over that command.
It’s all massive complexity on top of huge abstractions, none of which were designed with security in mind: it was just gradually bolted on top over the years.
Yes, this problem space has inherent complexity, but no, this inherent complexity does not require Github's insanely insecure defaults and incoherent security model.
As a practical step, one could try using webhooks to integrate their github repo with literally any other CI provider. This would at least give you a single, low-coupling primitive to build your workflows on. It would not, in any way, eliminate the domain's inherent complexity (secrets, 3rd party contributions, trusted publishing, etc.), but it starts out safe because by default it doesn't do anything - it's just an HTTP call that gets fired under certain conditions.
This is no different from any package registry getting some packages compromised.
Not many of them allow for immutable relases. And if they do, nothing blocks you from releasing a patch version that will most likely be automatically pulled in by many many projects during build.
The whole dependencies ecosystem is currently broken. Thats why its so easy (relatively) to attack via supply-chain.
Only way to be really secured is to have own registry of vetted dependencies pinned to exact version and maintain own upgrade pipeline.
NOONE (beside google) is going to do that. Its too costly, you need two big teams just to handle that one part.
> NOONE (beside google) is going to do that. Its too costly, you need two big teams just to handle that one part.
And yet my team and I at stagex are building a decentralized code review system to handle this anyway. Not waiting around with our fingers crossed for the corpos to solve supply chain security for us. Has to be a community led effort.
> basic rules that had been in place for ages. Things like: [...]
I am going to add my favorite here, just to rant into the void. A dialog box's options must never be Ok/Cancel. These are not the same sorts of things. "Cancel" is a verb, "Ok" is a noun (in this context). Even if "Ok" is taken to mean the verb "acknowledge", it is still not an alternative to cancelling.
99% of these dialogs should be "[Verb]/Cancel": Change "Ok" to a verb or short phrase indicating the action that will be taken if you press it. Don't do the action if the user hits "cancel". The verb should be something specific like "Delete file" or "Terminate process" and not something useless like "proceed".
IMO the ubiquitous Yes/No/Cancel is even worse. No and Cancel are too conceptually close. Doesn't help that these usually show up when you're about to lose all your unsaved changes.
We've got big screens now! use more words! Save changes/Discard changes/Don't quit.
I understand those prompts perfectly fine, but they are panic inducing for e.g. my mom who has about a 50% chance of clicking the wrong button and losing work.
No, determinstic scheduling is not a property of async python.
Yes, the stdlib asyncio event loop does have deterministic scheduling, but that's an implementation detail and I would not rely on it for anything critical. Other event loops - for instance trio [1] - explicitly randomize startup order so that you won't accidentally write code that relies on it.
It's been a stable (and documented) behavior of the Python standard library for almost a decade now. It's possible it may change--nothing is ever set in stone--but that would be a large change in Python that would come with plenty of warning and time for adjustment.
And then one day, Astral creates a new Python implementation in Rust or something that is way faster and all the rage, but does this particular thing different than CPython. Whoops, you can’t use that runtime, because you now have cursed parts in your codebase that produce nondeterministic behaviour you can’t really find a reason for.
and then all the serverless platforms will start using Astral's new rust-based runtime to reduce cold starts, and in theory it's identical, except half of packages now don't work and it's very hard to anticipate which ones will and will not and behold! You have achieved Deno
Well, in my early days programming python I made a lot(!!) of code assuming non-concurrent execution, but some of that code will break in the future with GIL removal. Hopefully the Python devs keep these important changes as opt-ins.
How do you differentiate between something that "happens to work due to an implementation detail" and a "proper feature that's specified to work" in a language without a specification?
> What makes anyone start a new project and think “I know, I’ll use Azure!”?
Because your org is likely already paying for O365 and "Entra ID" or whatever they call it nowadays, and so it seems like this will all integrate nicely and give you a unified system with consistent identity management across all domains. It won't - omg, believe me it will NOT - but you don't find that out until it's too late.
> One of the few reliable barometers of an organisation (or their products) is the wtf/day exclaimed by new hires.
Wellllll ... my observations after many cycles of this are:
- wtfs/day exclaimed by people interacting with *a new codebase* are not indicative of anything. People first encountering the internals of any reasonably interesting system will always be baffled. In this context "wtf" might just mean "learning something new".
- wtfs/day exclaimed by people learning about your *processes and workflows* are extremely important and should be taken extremely seriously. "wtf, did you know all your junior devs are sharing a single admin API token over email?" for example.
> http.server isn't a production-ready webserver, so people use Flask [...]
Nit, but relevant nit: Flask is also not a production-grade webserver. You could say it is also missing batteries ... and those batteries are often missing batteries too. Which is why you don't deploy flask, you deploy flask on top of gunicorn on top of nginx. It's missing batteries all the way down (or at least 3 levels down).
Appreciate the nit. Had no idea that Flask wasn't production-grade. Yeesh.
I really don't miss this part of the Python world. When I started on backend stuff ~10 years ago, the morass of runtime stuff for Python webservers felt bewildering. uWSGI? FastCGI? Gunicorn? Twisted? Like you say, missing batteries all the way down, presumably due to async/GIL related pains.
Then you step into the Go world and it's just the stdlib http package.
Anyway, ranting aside, batteries included is a real thing, and it's great. Python just doesn't have it.
Consider that the insane growth in the cost of living - especially childcare - combined with wage stagnation means that now the vast majority of families have 2 parents with full-time jobs, keeping them away for their families for much longer than before. Consider that childcare is much, much harder to even get into now than in decades past. Consider also that "EdTech" means that nearly every child needs to be on an internet equipped-device at all times.
But sure, "Parents often give too little fucks for long term welfare of their children", that's definitely it. Parents just hate their kids! What a useful perspective you've brought to the discussion.
Look, I am in this category too, and all that high cost and parents far applies for me too. I live in Switzerland, country of many wonderful things in society but state helping young parents ain't one of the strong points, in contrary. Both me (cca senior banking position in IT) and my wife (doctor) have intense time consuming jobs. All family is very far and can rarely help.
Still, given all that, I don't do cheap excuses like that. Its pathetic and weak and simply untrue. Things are harder but thats it, not impossible like your side of argument wants to conveniently claim. Quality time well spent with kids is highly proportional to outcome of raising efforts. No way to hide from that simple fact, and nowhere to hide from results of parenting, everybody can see them in plain sight.
But if you setup your life so that pathetic things like career are your upmost importance and you have no time nor energy for anything else, those are your choices and thats fine. Just not getting why folks then have kids, just to skip on actually raising them and then whine how unruly they are, raised by toxic groups with no role models. Having and raising kids is not some fucking checkbox to tick and move on, its 20+ years full commitment and biggest achievement in one's life, or biggest failure. Worth some proper effort, no?
I'm like 3 sentences in and already things do not quite make sense.
> Calling [socket] operations in the wrong order [...] is undefined behaviour in C.
UB? For using a socket incorrectly? You sure about that?
> Documentation — trust the programmer to read the man page (C, Rust).
I'm sorry, are they saying that rust's socket interface is unsound? Looks to me like it's a pretty standard Rust-style safe interface [1], what am I missing?
Even if you trust Microsoft's cloud engineering on the backend, this is a system that does not appear to follow even the most basic principles of privilege and isolation? I'm not sure why you would even try to build "supply-chain security" on top of this.
reply