81–90 of 211 posts
And we trust these people with the root CA cert in our Secure Boot?
In any case, you're free to remove Microsoft's certificates and enroll your own.
Earlier quoted context omitted.
one could also vibe-code vanilla, no dependencies.
You can vibe code safely for sure. I am not saying vibe coding is the issue. The issue is that a typical developer might be working on a lot more projects that run concurrently then they used to. And because of the various nature of the project the risk is significantly increased. Scale this across the workforce and you not just doubled the problem.
In the end it can just be a culture thing. A dev who was going to write docs and tests before is going to have a LLM generate docs and tests today. Same with safe practices and defensive coding. The machine does whatever you want from it, for most that's "just get the job done I don't care". So that's the output.
I strongly suspect this is a case of classic personal access tokens being used in an unclean way. If you are going to be handing tokens to AI agents on weird openclaw contraptions, you should try to use the fine grained variants. My GitHub account spans 3 organizations with wildly differing policies. The fact that classic tokens are even still allowed blows my mind a bit. You should be required to manually opt in eac…
Earlier quoted context omitted.
Azure are able to be targets of supply chain attack because of the supply chain ecosystem that they still own . It's not really a supply chain when it's still yours.
> It's not really a supply chain when it's still yours. I don't personally buy that, they offer a package manager in the form of nuget for example, if their products there are compromised, they're well withing normal reach to block THEIR packages, but why would they need to block the rest ? Maybe I'm missing something dumb
Nobody should do 'npm install' or 'pip install' on their machine. Using a proper sandboxing( https://github.com/ashishb/amazing-sandbox ) regularly will drastically limit the blast radius of these attacks.
> Nobody should do 'npm install' or 'pip install' on their machine. What alternative do you suggest? Do you mean not install outside a sandbox?
I strongly suspect this is a case of classic personal access tokens being used in an unclean way. If you are going to be handing tokens to AI agents on weird openclaw contraptions, you should try to use the fine grained variants. My GitHub account spans 3 organizations with wildly differing policies. The fact that classic tokens are even still allowed blows my mind a bit. You should be required to manually opt in eac…
It feels to me like AI agents should be their own security principals and use access tokens generated speficically for them on the repos or orgs that they need access to. Handing an AI agent an access token "minted" for a human's account feels to me like the new "write the password on a post-it".
Earlier quoted context omitted.
If an attacker can infect the post-install script of an npm package, they can also infect the package source code itself. So if you ever run the project outside the sandbox, you will still get compromised. It's like saying "I don't trust a software app with an installer, I just want a .zip with the binaries from the same source that I will run myself"
> they can also infect the package source code itself Which is where the concept of "safe levels" come in. I should be able to install this module in such a way where file operations and process operations are not available to it. That being said, presumably, this types of infiltration would seem to be _much_ easier to spot. "Why is this web framework calling 'spawn'?" > I just want a .zip with the binaries I want a…
> I should be able to install this module in such a way where file operations and process operations are not available to i
technically browser sandboxes, WASM, do this. but then you are very limited since you can only sandbox the whole app, and not one module, so if you need local file access, you need to open it up to the whole app and all it's modules
Earlier quoted context omitted.
I argued for years that we had too few workers for our total project count and management argued that most projects were idle and so it was fine to have so many per worker. Welp.
I think web-based IDEs like GitHub Codespaces (but even VSCode with tunnels) is part of the solution because at the very least you can get an isolated dev environment per project. I've been advocating for this for as long as I remember. Unfortunately, most developers don't like them so it is a though sell.
You make it sound like you are surprised, but everyone who has tried this knows it's crap and a band aid at best.
Earlier quoted context omitted.
Is the theory here that the browser cannot be co-opted to infect web-based repositories? Also: thinking of how yt-dlp can integrate with browser cookies now and the malware paths that opens up. (This is part of why Chrome wants HSM cookies, I expect: DRM and opsec!)
In this scenario the malware will not be on the device but in an isolated dev environment on a remote machine. So it will have access to whatever was configured in that repo but hopefully the project is isolated enough to ensure containment and prevent cross-pollination.