It's very typical to have a retainer / insurance to bring in "emergency" incident responders beyond your existing team. Not saying that's the case here but it wouldn't be surprising.

Isn't this very typical? Also, what is the proposal?

This ignores that by publicly releasing the patch is motivated.

> The author of iTerm2 initially didn’t consider it severe enough to warrant an immediate release, but they now seem to have reconsidered.

It's funny that we still have the same conversation about disclosure timelines. 18 days is plenty of time, the commit log is out there, etc.

The whole "responsible disclosure" thing is in response to people just publishing 0days, which itself was a response to vendors threatening researchers when vulns were directly reported.

Would it be possible to do somethign like editions for proc macros, or have crates establish "this is a v2 proc macro" or something? There are a lot of things I'd love to see change in a v2 but it'd all be breaking.

Yes, I think here are workable designs.

I think that they arguably do when they publish to a registry. I think that crosses a bridge from "I'm just writing software" and "I'm publishing software for consumption". Arguably, to be clear, I don't have very strong feelings, but I think there is a distinction between "I've placed code online" and "I've explicitly published it for use".

Sorry I'm just gonna copy some of this directly from tweets about sandboxing that I'd written.

I think it is a mistake to say "cargo build does not need to be sandboxed because cargo test is not". A very tricky part of sandboxing is sandboxing code you don't own. I own what code runs in tests, I do not own what code runs in cargo/ build scripts.

I can take responsibility for isolation in test/ci/prod. Those are tractable problems because I can design my tests/prod code to be friendly to sandboxing. I can not do that with build scripts or proc macros, I can't actually do much at all.

The solution for "sandbox cargo" ends up being "sandbox the entire dev environment", which is a very difficult problem to solve - you lose tons of performance, UX, and the security is lacking due to how much gets placed into the sandbox.

I strongly feel that cargo is in a much better position to help me out here. I can't even know if an update to a crate happened that suddenly added a build script without additional tooling.

As for typosquatting,

> If you think you can remember the URLs for each package you use, you’re probably wrong.

Most people aren't using urls so I don't get this. The issue is typing `cargo add reqwest`. Typosquatting algorithms solve this.

I did some math.

If crates.io had adopted a policy of "no crates within edit distance of one", 15% of crates would have been blocked across all time.

+Exception for same author: 14%

+Exclude <=4: 9%

+Swap from edit distance to actual typo detection algorithm: 5%

5% of crates would have needed a name change across all time. That number will likely decrease drastically as existing names are taken.

Yes, Rust needs radically more funding in these areas. Companies need to step up. Sandboxing, typo squatting, better auditing tools (ie: I need to know when `cargo udpate` adds a dep with a new build script, etc), TUF, etc, all need to be priorities.

Legitimately, I have had to stay away from certain linting tools because of how slow they are. I'll check this out.

cfn-lint is due for one of these rewrites, it's excruciating. I made some patches to experiment with it and it could be a lot faster.

Appreciate it! cloudformation isn't in scope today but the perf approach (tree-sitter + parallel file walk + rule pre-filtering) transfers, so happy to check it out.

You didn't click the link. Who are you to say that they aren't solving actual problems? You might not be their target. The whole article is dedicated to explaining why they're building their product.

The article does a bad job at that, because it remains rather vague and doesn’t explain the concrete problems they are trying to solve, that aren’t either already solved by Git-linked issue trackers, or would be better solved by improving support in Git itself (like for stacked branches).

Building UI and auxiliary features on top of Git is a crowded space, it’s not clear what compelling innovation they are bringing to the table.

You can think that because you've read the article.

I'm sure VCs give money to friends but I didn't know any investors when I raised millions. They invested money because they thought it was a good idea.

More like an idea decently likely to be resold for more.

Good ideas are a decent subset, but you could also have a bit of "Greater Fool Theory" compliant ideas.

Sure, but that doesn't really change anything. The poster plainly states:

> Money is not given to good ideas (though, it doesn’t hurt). Money is given to friends.

I have an obvious counter example. I'm sure money is invested for all sorts of reasons to all sorts of people. I'm also sure that money is not exclusively invested based on friendships, and I'm quite sure that money is at times invested based on the merits of an idea. Obviously those merits have to correspond to the ability to form the basis of a successful company, unless it's a philanthropic investment.

What I meant is that yes, good ideas will get funding, if they like you and if you are a good ROI (though, not all are required). This also may allow you to enter the clique/network. However, a lot of this money circulates between the same network. Convincing the right person of the value of your idea can enable you to join the network and access that money at a much, much lower threshold later on.

Obviously, it is not that cut and dry, but it is kind of impressive how much of the money circulating around is between the same people. I’m not really condemning it. I think it is a natural consequence because humans trust other humans they know. People should be more aware of it and need to make sure they keep it in check. Otherwise, you eventually start getting high on your own supply.