Looks like it's that, plus vibe coding (in areas like crypto!) - https://kerkour.com/stdx

The whole "There are test vectors so we know it's correct" is a strong sign that this isn't actually safe to use and that indeed the people who built it (to the extent people actually did build it) have no idea what they're doing.

For anyone wondering why, test vectors only cover “did the encryption work”. It does not cover “did you maintain constant time guarantees” to prevent against side channel attacks as an example. Crypto is filled with all kinds of such pitfalls that aren’t covered by conformance tests.

Hence “strong sign this is built by people who have no idea what they’re doing” is accurate.

To save you a read of the original while still having enough context, here's the whole section on crypto:

> crypto: spec and test-driven development to the rescue

> Cryptographic code is famously hard, with many, many footguns haunting unsuspecting developers (and even experts!).

> But, cryptography also has something that you likely won't find in any other domain: an extensive public collection of test vectors, particularly for edge cases. Every algorithm specification come with a basic suite of test vectors, but there are also community-built wonders such as Wycheproof.

> These test vectors, combined with the official specification documents of the crypto algorithms were rather effective to guide the coding agents and avoid the worst hallucinations.

> Cost: ~ $30

> Time: multiple days of part-time work.

> I'm under no illusion that the crypto crate is currently bug-free, but if my experience told me anything, it's that even experienced programmers are shipping bugs in crypto libraries. So, for similar outcomes, but using 1/100 of the time and at maybe 1/1000 of the cost, I think it's a clear demonstratin of AI's effectiveness.

Yeah, terrifyingly clueless, don't use.

Uh, yeah, this is not the writing of someone with the experience to maintain a cryptography toolkit: https://kerkour.com/nist-cryptography-backdoor

(I’m more worried about judgement calls than implementation correctness, it’s not about AI.)

Hah, length-extension and CBC mode, famous NIST backdoors.

They have build.rs (https://doc.rust-lang.org/cargo/reference/build-scripts.html)

As someone who uses gitea, honestly it’s because I set it up a while ago and foregjo hasn’t offered anything compelling to force a switch, nor has gitea “enshittified” like the concerns around the fork raised.

Honestly, stay where you are

Do note rustfs has had a...questionable...security posture. See https://github.com/rustfs/rustfs/security/advisories/GHSA-h9... as a good example (hardcoded static token).

If you run (vibe-coded?) alpha software in production, assume security is compromised.

In fact, if you run software in production, assume security is compromised.

> So if the minio maintainers (or anybody that forks the project and wants to work it) can fix any security issues that may occur I don't see any problems with using it.

The concerning language for me is this part that was added:

> Critical security fixes may be evaluated on a case-by-case basis

It seems to imply that any fixes _may_ be merged in, but there's no guarantees.

Yes this is concerning for me too. Hopefully if they don't fix/merge security issues somebody will fork and maintain it. It shouldn't be too much work. I'd even do it myself if I was experienced in golang.

> That aside, I’m confused about the 250ms thing. You don’t have to hit a Google API to construct a signed URL. It should just be a signature calculation done locally in your server. [0]

I assume the additional latency is the initial cred fetch from the VM Metadata Service to perform that sign, no?

Slight correction, the sales org uses GitLab, mainly to segregate any “code” they build for customers. Internal AWS/Amazon teams use an internal git-backed UI.

The fact that there was no dogfooding in many years here tells everything one needs to know about CodeCommit.

If AWS forced their teams to "dogfood", it would quickly morph into the Testuo blob monster from Akira -- there are too many products/services popping up too quickly, and the amount of time and knowledge lost to the constant changes would be catastrophic.

Dogfooding is for simpler companies. It's also bullshit and best for product managers and sales. Let tech work with what's best for their specific internal environment.

> I believe they had intentions of selling this tech to other stores but it never really took off (maybe uniqulo is using it?)

They did, it's called "Just Walk Out" - https://www.justwalkout.com/ and https://aws.amazon.com/just-walk-out/ . I've seen it a bunch at airports, and occasional random city locations.

To add onto your comment, I've also seen it used at quite a few stadiums.

Man I’d kill for that to be in every grocery store.

Just put the “self checkout” on the cart/trolley and take them directly to your car. “SmartCarts” have to be a thing at some point. …and they will put video ads on them.

As an opposite point - the airports I've been to have been pretty easy to opt-out, though they usually have snippy comments about "saying it up front".

That being said, did your airport not have signs talking about the pilot, and it being optional? I would of pointed to that if I was told no.

It was very early in the pilot process, and I was trying to board an international flight. There was little or no signage, and the TSA staffer told me I could not opt out when I asked. Not a great experience. Since Senator Markey has been harping on this it has improved.

> Why can’t T-Mobile issue me a free “advertising” eSIM that doesn’t actually provide service (or provides a ridiculously small amount)

Not sure if you’ve checked, but they actually do. On the iOS, I downloaded the TMobile app and was given the ability for a trial eSIM.

We must applaud these efforts. This was introduced by someone who did not look at eSIM as a mere virtual replacement for SIM cards, but a new tool with new capabilities.