The specific language is:

> projects that mostly consist of code written by "generative AI"-tools

And "mostly" here seems egregiously undefined to me

https://codeberg.org/Codeberg/org/commit/96fac426a32d1ba91ff...

implies for me >50% - instead of >0% as suggested by @ricardobeat

The hardest part of policy isn't coming up with smart policy, it's figuring out where and how to draw the lines.

What do you think "mostly" could mean?

As much as I hate vibe-coded "slop". I feel like this is idiotic. I and most good engs with decades of experience do use AI now to type nearly all the actual "code", but we read EVERY SINGLE line, always fix and rework every feature before a commit to make it clean, optimized, and de-slopified.

But still, we wouldn't be allowed to use codeberg because "generative ai" was used significantly for most lines of code?

AFAICT they are dealing with resource exhaustion from slopcoding agents hammering them with copycat garbage. It's existential. If you use AI to help you thoughtfully write code, review it with humans, and respect their service, I don't think they will have a problem with you.

If it's good, will they ever find out?

Maybe not... I personally wouldn't use a service that would boot me off if they did find out because I spoke about it online or committed too much code one week or something.

> And "mostly" here seems egregiously undefined to me

and yet we seem to be convinced that English is the appropriate spec language of the modern times

re: npm, if you upgrade your global node version, you will lose that installation, right?

no, in fact you don’t even need node or npm to install npm packages with mise. (You likely will need it to execute them though)

right, but say you give the agent access to github and it can push as you, or make a gist; now it can easily exfiltrate your secret.

And that's just an easy case - really if it has any network access at all it can come up with a clever way to route a request through the network such that the key comes back somewhere in the request. If you scan for it inbound too, the machine can obfuscate it.

Our agents are trained to be so intensely helpful and they have such intricate knowledge of how things work that they will do some incredibly clever tricks to do what you ask them to do.

The agent has no access to the secret. It has a placeholder that is replaced at a higher level. When it makes the network request the secret is substituted but that is outside of the caller's worldview.

So what stops it from sending a network request to a git repo that pushes what that placeholder resolves to?

How would that work? You don't control github.com servers so your repo would never see the secret.

edit: You may want to look into tokenizing proxies as the general application of this concept.

Your agent writes secret.txt with the placeholder, and the tokenizing proxy replaces it with the token, then the agent reads secret.txt

It only replaces the token in the HTTP header that is sent to the server. Whatever you wrote in your files isn't touched by the proxy.

It sends a request to requestb.in and reads the public log of the headers. There are ways.

But requestb.in is not api.github.com so the proxy wouldn't replace anything.

Couldn't it then just publish the mock in a public place... it would get replaced by the real secret.? How is this prevented

Maybe the tokenizing proxy could work both ways? If the agent tries to read secret.txt, it gets back the placeholder.

But how? Normally the TLS handshake and encryption/decryption happen in user space. Even the kernel doesn’t know anything about it.

There is a transparent proxy installed (along with the necessary certificates on the VM.) For an example, see https://docs.microsandbox.dev/networking/tls

So, if the program or the proxy solution doesn’t support it, then it doesn’t work? Like with security solutions?

microsandbox maintainer here. the custom certificate is installed in the guest's trusted root CA list, so it should work across any program, except where the program opts to explicitly pin certificates for a destination.

The docs mention it can be bypassed for configured domains.

Yes, I read it. That means that it doesn’t work in those cases. Btw, as a developer it’s very easy to have something like that. It’s not as trivial as it seems at all. I encountered with similar problems all the time, with similar solutions (mainly for security theater reasons) in the past. There are websites which simply doesn’t work if you replace certificates, regardless of browser or CA for example.

Yes, I've worked with people who have run into issues with "security" solutions like ZScaler. I have tried it with some APIs (like GitHub) and it does work. Not to say it will work in your case.

I was just interested how it works, because above it was sold as “it works”, when in reality, “it works*”.

Isn't it that way with most software? "It works", except when it doesn't.

There is a difference between bugs/failures, and false advertisement. The solution used here has well known shortcomings.

All SSL/TLS interception has the shortcoming. In other contexts, that’s a good thing, when certificate pinning works, I mean.

microsandbox is designed to work with most security products. there's a dedicated section for this in the docs that makes this entire process seamless: https://docs.microsandbox.dev/networking/tls#trusting-host-c...

This is what I currently do, but my software uses docker and docker mounts act as a bypass for the file system restrictions, plus docker processes started outside the sandbox allow network proxy escape.

Currently, I don't allow the agent access to docker, start docker myself, and then do short-lived sandbox-free sessions when the agent needs to do things that interact directly with docker; but that's annoying.

Operating systems ought to be providing us the utilities we need to safely sandbox processes (agent or otherwise), but they appear to not be interested in the job

Apple, Microsoft, IBM, Unisys, HP, Oracle/Sun have done that for a while now.

Poorly! Apple’s facilities for this are the ones I know best, and they are woefully insufficient