mikesir87
The main reason a "proxy-managed" env var is set is because most CLI tools assume if the env var is set, auth is set. If the env var is unset, it will assume auth needs to occur. Fortunately, most don't do a pattern matching on what the value actually is.
Read more about the secrets handling here - https://docs.docker.com/ai/sandboxes/security/credentials/
Kits provide the ability to also define new credentials and how to inject them into new services (connect to internal systems, etc.).
One of the demos I run is how easy it is to circumvent the harness limits. For example, I can configure a harness not to access file `secrets.txt`. But, then I can immediately have it create a Python file that can read any file and have it read `secrets.txt`.
At the end of the day, "please" isn't security. You want to know that the agent can only do and access the things it should access.
Example: sbx run claude ./ ../another-project:ro
There's also an ability to create kits where you can setup credential injection into other services as well.
Note that Compose files using the previous model declarations (using providers) will still work.
"During that period" refers to the 30-day period. During that time, the images are accessible. After the 30-day period, they will still be pull-able, but not able to be updated.
> Given these statements directly contradict each other
Actually... they aren't contradictory. The organization data will be retained for 30 days and is subject to deletion. That data includes the teams, memberships, etc. But, it wasn't clear what we were going to do about the images. Keeping the public images is important as many other images build on top of them.
> It feels like they changed the actual strategy
We recognize it might feel that way, so apologies. But, that's part of where we are recognize it wasn't clear the technical details... we didn't talk at all about the images. After the feedback, we recognized this, so wanted to make that clear.
In Compose, the "server" service is running using the image that is produced by that build. It's then handed off to the new Wasm runtime, where the module is extracted and executed. Hope that helps! Feel free to follow up with more questions!
With this preview, we are leveraging the OCI specification that defines how to build an image. Linux/Windows containers are the most common use of this specification, but many other types of artifacts exist (OPA policies, Helm charts, etc.).
When using any of these other artifact types, tooling has to know how to use that specific artifact type and run it (eg, extract the image and run it as a container or extract the Helm chart and deploy it). In our Wasm use case, we are doing the same thing... package and ship a Wasm module and we'll extract it and run it on the new Wasm runtime. That runtime then "converts" the Wasm module into native machine code for the OS you're running on.
> If this is the case I'd leave docker outside the name of the technology. I imagine the confusion.
That's great feedback! While most know us as "the container company", our mission doesn't even talk about containers. We want to help all developers succeed by reducing app complexity. We can certainly do more to help educate folks between the different types of workloads you might be running. We're still very early on in this process, so stay tuned (and keep the feedback coming)!
There are a few limitations right now, some of which lack of built-in garbage collection and multi-threading. You also have to use a language that can completely compile to Wasm, making it hard (sometimes impossible) to leverage already built libraries/binaries.
But... the tech is growing rapidly and we're excited for it! Happy to dive in or answer more questions if you'd like!
But... certainly a neat idea to think about what Wasm-based applications could possibly look like/run in the browser!
As far as Wasm itself, it's designed to provide a fast, lightweight, secure, and portable binary format. While it was originally designed to help bring native code to the browser, it's quickly spreading to the server side. Many folks are using it for edge/IoT, but it's growing into other areas (saw demos today of even using it in databases as psuedo stored procedures). Happy to dive in more if you have more questions!