IME, CORS is pretty straightforward in prod but can be a huge pain in dev environments, so you end up with lots of little hacks to get your dev environments working (and then one of those hacks leaks back into prod and now you have CORS problems in prod).
This. This is a result of not having proper environments and engineering practices in place and so the team or engineer is free to just wing it and add hacks around security best practices because the Security Team (tm) is elsewhere and they never understand the ask. They know PKI and certificates, access card identity, maybe Cisco for their "cyber security" but that's usually where it ends. Yet somehow, they are in charge of CORS and TLS and Sast/Dast scans and everything else that should be baked into the pipelines and process. Resulting in an engineer saying f'it and adding an `if localhost` hack or something. CORS is one example but there are many others in pretty much every area of security. OAuth, CORS, LDAP, Secrets, Hashing, TOTP, you name it. Each has a plethora of packages and libraries that can "do" the thing but it always becomes a hairball mess to the dev because they never understood it to begin with.
The hypothesis you're referring to is something like "if everyone uses a 7-day cooldown, then the malware just doesn't get discovered for 7 days?", right?
An alternative hypothesis: what if 7-day cooldowns incentivize security scanners, researchers, and downstream packagers to race to uncover problems within an 7-day window after each release?
Without some actual evidence, I'm not sure which of these is correct, but I'm pretty sure it's not productive to state either one of these as an accepted fact.
Reading this, I was surprised to learn that I now consider the idea of working on old-school conventional weapons almost, like, quaint.
What with all the ways our new military/techno-industrial complex is working to automate murder, surveillance and terror at scale ... it makes me nostalgic for that old-fashioned artisanal state-sanctioned murder, made in small batches by real humans.
That reminds me of a sci-fi quote, where one of the main characters is discussing a murderous antagonist, putting their evil into a broader context:
> "He was just a little villain. An old-fashioned craftsman, making crimes one-off. The really unforgivable acts are committed by calm men in beautiful green silk rooms, who deal death wholesale, by the shipload, without lust, or anger, or desire, or any redeeming emotion to excuse them but cold fear of some pretended future. But the crimes they hope to prevent in that future are imaginary. The ones they commit in the present--they are real."
You may have gotten caught up in the hype. It's still intelligence, logistics, bullets, missiles, and airplanes (etc.)
The beginnings of "automated murder" were anti-aircraft weapons that implemented a kind of mechanical computer that beat humans in predicting where aircraft were going to be (you have to shoot at where the plane is going to be when your bullets get there). Look up Norbert Wiener.
For a century it's been automation assisted, none of this is new, it's just been improving consistently. They had UAVs in WWI for gods sake. (flying things without people in them, used in war)
Judging by the graphics used in the launch event, it may actually be miniLED. Perhaps they aren't mentioning this so people don't compare their max 700 nits full screen brightness to other vendors' >1000 nits full screen brightness.
Floating-point non-determinism issues usually come from one of these sources:
- Inconsistent use of floating-point precision, which can arise surprisingly easily if e.g. you had optional hardware acceleration support, but didn't truncate the intermediate results after every operation to match the smaller precision of the software version and other platforms.
- Treating floating-point arithmetic as associative, whether at the compiler level, the network level, or even the code level. Common violations here include: changing compiler optimization flags between versions (or similar effects from compiler bugs/changes), not annotating network messages or individual events with strictly consistent sequence numbers, and assuming it's safe to "batch" or "accumulate" deltas before applying them.
- Relying on hardware-accelerated trigonometric etc. functions, which are implemented slightly differently from FPU to FPU, since these, unlike basic arithmetic, are not strictly specified by IEEE. There are many reasons for them to vary, too, like: which argument ranges should be closest to correct, should a lookup table be used to save time or avoided to save space, after how many approximation iterations should the computation stop, etc.
It's weird, because I'm not aware of any OSS licenses or authors who say "you are expected to upgrade to the most recent release of this package as soon as it comes out so that you'll get infected with any malware it might contain."
Good thing the internet is here to lecture me about all the secret obligations I have incurred by creating and using open source software!
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.
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.
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.
> 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.
