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.
> 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.
> 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.
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.
Just because the protocol has a formal set of proofs, doesn't mean it's production ready. The very fact that the only releases are snapshots and not eligible for CVE's makes me weary of utilizing this in a non-testing environment.