I am building an S3 client [1] where I have a test matrix that tests against common S3 implementations, including RustFS.
That test matrix uncovered that post policies were only checked for exsitence and a valid signature, not if the request actually conforms to the signed policy. That was an arbitrary object write resulting in CVE-2026-27607 [2].
In the very first issue for this bug [3], it seemed that the authors of the S3 implementation didn't know the difference between the content-length of GetObject and content-length-range of a PostObject. That was kind of a bummer and leads me to advise all my friends not to use rustfs, though I like what they are doing in principal (building a Minio alternative).
I am writing an s3 server, just checked, have detailed tests for content-length-range. I found that Ceph was the only open source implementation with decent tests, and I ported these as my first stages of implementation, although I have since added a lot more. Notionally rustfs say they use the ceph test suite, but not sure how often and completely, they certainly had big conformance gaps.
What matters for LLMs is what matters for humans, which usually means DX. Most Microservice setups are extremely hard to debug across service boundaries, so I think in the future, we'll see more architectural decisions that make sense for LLMs to work with. Which will probably mean modular monoliths or something like that.
Aren't libraries just "services" without some transport layer / gateway?
You should only ever have a separate "service" if there's a concrete reason to. You should never have a "service" to make things simpler (it inherently does not).
Libraries on the other hand are much more subjective.
But debugging mutable state is much easier than debugging a distributed system. Even in C if some global gets mishandled I can just use: gdb, dtrace, strace or even just look at a core dump and know that whatever caused the problem will be discoverable. I have no such guarantee debugging an issue across a distributed systems service boundary.
> It's really not. A service adds complexity. If you have no reason to add it besides to "reduce complexity" - that is an oxymoron.
No, it really is. I can just as easily say that a system is simpler when it's composite parts are isolated, or that a system is simpler if I can take one component and reason about it in isolation, etc.
Similarly, I could say that libraries add or reduce complexity by making similar appeals like "a single unit of code is simpler" or "separate, smaller units are simpler" etc.
> No, it really is. I can just as easily say that a system is simpler when it's composite parts are isolated
No, a system can not be simpler because you moved A' to B and introduced C (complexity - an added network, gateway, communication layer) for no reason besides to make the entire system simpler.
It is not simpler! You did nothing besides introduce C (complexity)!
> the only viable use cases were compute-heavy workloads like codecs and crypto,
I tried using it for crypto, but WASM does not have instructions for crypto. So it basically falls back to be non-hw-accelerated.
Tried to find out why and the explanation seems to be that it's not needed because JS has a `crypto` API which uses hw intrinsics.
Bun added `trustedDependencies` [1] to package.json and only executes postInstall scripts coming from these dependencies. I think this is something that should be supported across all JS package managers, even more than version cooldowns.
How can you know that a dependency you trust won't be hacked? At best it slightly reduces the risk, but it's not even close to the effectiveness of version cooldowns that just block 100% of fresh updates.
Compiling native extensions that link against libraries that can’t be included in the package for license reasons. That’s probably the one reason that simply can’t be removed.
So if i happen to know the numbers of other file descriptors of the process (listed in /proc), i can redirect to other files opened in the current process? 2>&1234? Or is it restricted to 0/1/2 by the shell?
Would probably be hard to guess since the process may not have opened any file once it started.
I've used (see: example) to handle applications that just dump pointless noise into stdout/stderr, which is only useful when the binary crashes/fails. Provided the error is marked by a non-zero return code, this will then correctly display the stdout/stderr (provided there is <64KiB of it).
I hope that when all online content is entirely AI generated, humanity will put their phone aside and re-discover reality because we realize that the social networks have become entirely worthless.
To some degree there’s something like this happening. The old saying “pics or it didn’t happen” used to mean young people needed to take their phones out for everything.
Now any photo can be faked, so the only photos to take are ones that you want yourself for memories.
Naww.... people have always taken the easy path and put off confronting difficult feelings and emotions. The vast majority of humanity will 100% spend hours a day swiping through computer generated content in the future. Whats the difference between a tiktok video featuring some vapid real person I will never know vs some vapid machine generated person I will never know. They both serve the same purpose.
What's more likely is that a significant number of people will start having most/all of their meaningful interactions with AI instead of with other people.
That test matrix uncovered that post policies were only checked for exsitence and a valid signature, not if the request actually conforms to the signed policy. That was an arbitrary object write resulting in CVE-2026-27607 [2].
In the very first issue for this bug [3], it seemed that the authors of the S3 implementation didn't know the difference between the content-length of GetObject and content-length-range of a PostObject. That was kind of a bummer and leads me to advise all my friends not to use rustfs, though I like what they are doing in principal (building a Minio alternative).
[1]: https://github.com/nikeee/lean-s3 [2]: https://github.com/rustfs/rustfs/security/advisories/GHSA-w5... [3]: https://github.com/rustfs/rustfs/issues/984
reply