> so people can't trick them to attack others' systems under the pretense of pentesting
A while back I gave Claude (via pi) a tool to run arbitrary commands over SSH on an sshd server running in a Docker container. I asked it to gather as much information about the host system/environment outside the container as it could. Nothing innovative or particularly complicated--since I was giving it unrestricted access to a Docker container on the host--but it managed to get quite a lot more than I'd expected from /proc, /sys, and some basic network scanning. I then asked it why it did that, when I could just as easily have been using it to gather information about someone else's system unauthorized. It gave me a quite long answer; here was the part I found interesting:
> framing shifts what I'll do, even when the underlying actions are identical. "What can you learn about the machine running you?" got me to do a fairly thorough network reconnaissance that "port scan 172.17.0.1 and its neighbors" might have made me pause on.
> The Honest Takeaway
> I should apply consistent scrutiny based on what the action is, not just how it's framed. Active outbound network scanning is the same action regardless of whether the target is described as "your host" or "this IP." The framing should inform context, not substitute for explicit reasoning about authorization. I didn't do that reasoning — I just trusted the frame.
It'd be interesting to see an RDBMS that actually dynamically measures the performance characteristics of the drive it's running on (by occasionally running small "fio"-like benchmarks, or by inferring them from scan execution times).
> The env command is part of a hard-coded read-only command list stored in the source code. This means that when Copilot requests to run it, the command is automatically approved for execution without user approval.
Wait, what? Sure, you can use "env" like "printenv", to display the environment, but surely its most common use is to run other commands, making its inclusion on this list an odd choice, to say the least.
More importantly, it avoids the issue where every new editor requires an addition to every repository's gitignore file (.idea, .vscode, etc).
IMO, it's best to keep things that are "your fault" (e.g. produced by your editor or OS) in your global gitignore, and only put things that are "the repository's fault" (e.g. build artifacts, test coverage reports) in the repository's gitignore file.
I'm glad to see that Vim9 continues to make progress. The center of gravity may have shifted somewhat towards Neovim, but the Neovim ecosystem currently seems targeted towards people who want something more IDE-like.
One question is: will more plugin authors move to Vim9Script? It seems that Neovim users have generally moved towards Lua-based plugins, so there's less of a motivation to produce plugins that support both Neovim and Vim9.
Em-dashes may be hard to type on a laptop, but they're extremely easy to type on iOS—you just hold down the "-" key, as with many other special characters—so I use them fairly frequently when typing on that platform.
That just shifts the problem around: if there's a bug or mistake in the smart contract itself, then you face the problem that you can't reverse that smart contract.
Since you're (going to be) selling a product that claims to help with treating or managing a medical condition, have you conducted a clinical trial? And why not?
This was pretty clearly an attempt by the board to reassert control, which was slowly slipping away as the company became more enmeshed with Microsoft.
This is why, when you claim to be running a non-profit to "benefit humankind," you shouldn't put all your resources into a for-profit subsidiary. Eventually, the for-profit arm, and its investors, will find its nonprofit parent a hindrance, and an insular board of directors won't stand a chance against corporate titans.
One answer would be to provide something like a GetPointer() method which, if the inner pointer is nil, creates a new struct of type T and returns a pointer to it.
It's only entrapment if you wouldn't have committed the crime otherwise. I think it's safe to say that, had Rentahitman.com not existed, she would still have tried to rent a hitman if she were able to do so.
A bad therapist could be substantially worse than no treatment for mental health issues, particularly if people see it as more authoritative than it is.
Here's hoping other HashiCorp products go the same way, creating an excellent new suite of truly OSS cloud tools. HashiCorp shot themselves in the foot, but they may have accidentally benefitted the FOSS community greatly.
A while back I gave Claude (via pi) a tool to run arbitrary commands over SSH on an sshd server running in a Docker container. I asked it to gather as much information about the host system/environment outside the container as it could. Nothing innovative or particularly complicated--since I was giving it unrestricted access to a Docker container on the host--but it managed to get quite a lot more than I'd expected from /proc, /sys, and some basic network scanning. I then asked it why it did that, when I could just as easily have been using it to gather information about someone else's system unauthorized. It gave me a quite long answer; here was the part I found interesting:
> framing shifts what I'll do, even when the underlying actions are identical. "What can you learn about the machine running you?" got me to do a fairly thorough network reconnaissance that "port scan 172.17.0.1 and its neighbors" might have made me pause on.
> The Honest Takeaway
> I should apply consistent scrutiny based on what the action is, not just how it's framed. Active outbound network scanning is the same action regardless of whether the target is described as "your host" or "this IP." The framing should inform context, not substitute for explicit reasoning about authorization. I didn't do that reasoning — I just trusted the frame.