Egregoros

But we are not done.

If you look sy my previous post, under the erroneous "You should use OAI" message, there's a little icon and the word "Explain." You can ask the #LLM to explain the warning. Here's the explanation that Claude Sonnet 4.0 has for that warning. For those of you who don't want to read a screenshot, the LLM has prompted itself with:

Explain CloudFront Distribution Resources have an S3 Origin configured without an Origin Access Identity (OAI). issue in 70-frontend-stack.yaml at [29]

And the LLM's response to its own prompt is:

This is a false positive security warning. The issue is incorrectly flagged because:

You ARE using access control - Line 16-23 creates an Origin Access Control (OAC), which is the modern replacement for OAI

OAC is properly configured - Line 38 attaches the OAC: OriginAccessControlId: !GetAtt CloudFrontOriginAccessControl.Id

S3 bucket policy enforces OAC - Lines 120-135 ensure only CloudFront can access the S3 bucket

The security scanner likely only checks for the legacy OriginAccessIdentity property and doesn't recognize the newer OriginAccessControlId. Your configuration is actually more secure than using the deprecated OAI.

The warning can be safely ignored - your setup uses the AWS-recommended OAC approach for securing S3 origins.

Thanks for wasting my time AND egregious amounts of electricity generating a pointless "high priority" security warning.

Here is a way that I think #LLMs and #GenAI are generally a force against innovation, especially as they get used more and more.

TL;DR: 3 years ago is a long time, and techniques that old are the most popular in the training data. If a company like Google, AWS, or Azure replaces an established API or a runtime with a new API or runtime, a bunch of LLM-generated code will break. The people vibe code won't be able to fix the problem because nearly zero data exists in the training data set that references the new API/runtime. The LLMs will not generate correct code easily, and they will constantly be trying to edit code back to how it was done before.

This will create pressure on tech companies to keep old APIs and things running, because of the huge impact it will have to do something new (that LLMs don't have in their training data). See below for an even more subtle way this will manifest.

I am showcasing (only the most egregious) bullshit that the junior developer accepted from the #LLM, The LLM used out-of-date techniques all over the place. It was using:

• AWS Lambda Python 3.9 runtime (will be EoL in about 3 months)
• AWS Lambda NodeJS 18.x runtime (already deprecated by the time the person gave me the code)
• Origin Access Identity (an authentication/authorization mechanism that started being deprecated when OAC was announced 3 years ago)

So I'm working on this dogforsaken codebase and I converted it to the new OAC mechanism from the out of date OAI. What does my (imposed by the company) AI-powered security guidance tell me? "This is a high priority finding. You should use OAI."

So it is encouraging me to do the wrong thing and saying it's high priority.

It's worth noting that when I got the code base and it had OAI active, Python 3.9, and NodeJS 18, I got no warnings about these things. Three years ago that was state of the art.

More moaning about #linux. I'm trying to get a discourse server off the ground. Why the fuck do they insist on installing non-OS stuff in the middle of all the OS stuff.

/var/discourse is not a good default. And then fucking docker wants to be /var/lib/docker. Never mind how /var/lib doesn't make any goddamn sense.

Related to my earlier discussion of hard drive partitioning. What I would like to do is have a volume that is not the operating system, but is instead all the application data. The discourse data, database, assets people upload, etc. That way I can have this nice virtual disk that encapsulates it. I could theoretically build a new node, attach this drive to the new node, and migrate the site. I can snapshot that drive more frequently than, say, the OS drive. Lots of benefits to encapsulating it.

But no. The discourse "easy installer" sprays shit all over /var. I'm gonna get some database down in /var/lib/docker/something and I'm going to get assets living in /var/discourse, and umpteen gajillion container images in /var/lib/docker.

But I also have fucking /var/log for OS logs, and /var/run for runtime information like PIDs, and /var/lock and /var/tmp. I think /var/most-important-app-on-the-system is NOT where you put application software. So my volume/filesystem to encapsulate discourse? Is that a big ass /var?

I love #FreeBSD because it is so well organized. They even go to trouble to make packages like postfix or apache fit the idiom, rather than let it install in /var/lib/opt/sbin/etc or some shit.

This public service announcement sponsored by Old Man Yells at Cloud, Inc.

This silly statement from #openai about #security drives me crazy. People talk about this all the time as if it means something.

‘files in ChatGPT as a whole are "encrypted by default at rest and in transit"’

What attack does that encryption at rest defeat? What hacker says “darn it! I would have gotten the data if it hadn’t been for that pesky encryption at rest?”

Think it over. Go ahead. I’ll wait.

Physical theft of hard drives/storage. That’s it. Encryption at rest at OpenAI, or any cloud, defeats the same singular attack that it defeats when you encrypt the hard drive on your laptop: if someone physically steals the device, they don’t get the data.

They can sell your data. They can store it (encrypted at rest) on a web site that has a vulnerability or incorrect security, and bad people can download the unencrypted data. They can share it with “partners” who misuse it. Encrypting at rest is NOT an important protection. Literally every other protection is more important.

https://www.darkreading.com/remote-workforce/chatgpt-health-security-safety-concerns