How do you square advocating for the "Open Source Resistance" which touts "stop asking for permission" to do software and then saying "we need everything on MacOS to be signed and will be dropping packages that don't get Apple's permission"?
I'd consider donating, but I find that behavior to be part of squeezing free computing and participating in and advocating for the corporate erosion of ownership of one's hardware environment.
OSS Resistance is about not asking for time to do something yourself while removal of unsigned casks is about what they host in the official Homebrew/cask repo. You're free to make & use your own tap to use with Homebrew without asking, so there's not really anything to square between the two stances - any conflict all comes purely from your 3rd stance about signing in general.
I just threw them a small donation for supporting this software for so long, even if it's only 98% how I'd want the project to be run all these years myself.
I square them because both of them allow me to do lots of open source work and enjoy it.
Your signing point is not accurate. It doesn’t apply to all packages, only casks in the official tap. With casks the trust model, particularly on things that auto-update and don’t expose versions or checksums on download URLs, heavily relies on Apple’s security guardrails. We pushed against them for a while but Apple’s direction of travel made it clear that it was a waste of our energy and that we were at risk of compromising our users through doing so.
You can still automatically remove quarantine in third-party taps as desired, we’re just making it less easy to do so because we consider it a security feature that should require a deliberate bypass.
I don’t think anyone is obliged to donate to Homebrew but this sort of framing, assuming you use Homebrew, isn’t great. If you find what we do morally distasteful: go use something else. MacPorts, Mise and Nix are all good. This will be better for everyone than using us begrudgingly.
An ant traveling at constant speed on a "scrunched up section of a table cloth" will still take the same amount of time following the same path to get from A to B. Any material analogy requires some kind of stretching or compression.
Consider that since an LLM is really just an large encoding of data, the "proof" is in there already. All further work on it is effectively only rearranging words. Then all math an LLM is capable of is "done" and we have the "proof" in the LLM which by your definition is now "MUCH easier to understand" and this work is somehow sufficient.
You're confusing "contains information" with "has produced a result."
A proof being latent in an LLM is no more significant than a proof being latent in a book, a theorem prover, or the axioms themselves. Einstein's papers were latent in the genetic code of his parents and the environment of his time. That doesn't mean general relativity was "already done" before Einstein was born.
By your logic, no computation has ever accomplished anything because the output was always implicit in the inputs.
The entire purpose of computation is extracting information from representations where it's difficult to see into representations where it's easy to see.
So no, this isn't a problem with the original reasoning. It's a problem with yours.
But the agent could be trained on sensitive data that could leak which could enable a different attack.
Saying it's safe to "ignore" anything that exposes information is dangerous. You might as well claim social engineering isn't real as long as the person doesn't have direct access to the thing you want.
They are suggesting that you should assume the user has full access to the same tools as the agent, which is a helpful way to approach it. You mentioned the prompt side of things, and I think you should use a similar mindset there—just assume the user can read the entire prompt exactly as it’s sent.
You should also assume the user can read any data you send back from a tool call or data you add to a user response. If any part of the input or output is controllable by an attacker, you should be assuming some prompt injection is possible that allows them to access all data and tool calls the agent had and has access to.
Agreed. The agent and tools are different types of vulnerabilities. Both are important especially if you have dedicated finetuning (which won't be user dependent of course).
But also stuff like RAG: usually support agents have access to all internal support kbase material. Including stuff you don't want to leak verbatim. And there's other things to consider too like your agent being used to run other people's prompts. Not a data loss issue but could be a financial issue.
But yes I do agree that for the tools' security the agent shouldn't be considered as part of the security model. Any protections there are nice to have but shouldn't be relied upon.
This is exactly what I mean; if you give your agent access to some knowledge base through RAG; you should assume that this knowledge is now public information. If you don't want it to leak, design your agent so that it doesn't have access to it.
That's yet another class of attack and a pretty rare one. Very few agents run on fine-tuned models, but even for those that do, the same framing exists there. You should assume that anything that goes into the training data must be considered public information.
What's more is yt-dlp already has plugin support for 3rd party interpreters. They're just saying they don't want to deal with supporting bun themselves and the infrastructure for anyone else do use whatever they want is already there.
This is just the standard misguided entitlement people feel towards other people's projects supported by other people's time and effort. It's continually outrageous to me how people feel they can just volunteer other people's time and effort to support their own wants. The people who do the work are entitled to make their decisions and if you don't like it fork it yourself. This has been the way of this ecosystem since it started.
In the abstract, it’s hilarious to imagine the hackers keeping the data, then some time from now leaking it accidentally (or another hacker group hacks them) then them having to issue a public apology for not having kept the stolen data secure and having lied about shredding it.
However, they could use it as a last resort or as a final "gift" before getting arrested or switching identities.
They might be considered "trustworthy" right now to get companies to pay them money, but no one will know what will happen in a few years when this strategy won't work anymore.
Anyway, I hope this doesn't come at all, or as late as possible.
> but no one will know what will happen in a few years when this strategy won't work anymore.
Good point.
> Anyway, I hope this doesn't come at all, or as late as possible.
Same. As I said, I find the idea funny in the abstract, if it didn’t affect anyone or if it were a TV show, for example. But since it does affect real people…
Hackers have an incentive to destroy the data as promised, because if it becomes a trend where the data is leaked despite the ransom being paid, no one would pay ransoms in the future.
Obviously this doesn't stop hackers from selling the data anyway and say "it wasn't us, someone else got the same data through a different hack".
Not throwing shade at anyone here but the thought has definitely crossed my mind that we are recreating SAFe but for agents when looking at some of the orchestration setups out there. I think that it is better to not force the same hierarchical processes that worked for humans in large organizations onto agents and instead look at what they need to give better results and what their failure modes look like.
reply