> AI slop nothing burger. The “exploit” has nothing to do with coding agents.
It's pretty small potatoes, but it is a harness ~bug that they treat this so poorly. It getting triggered before some of them even ask you if you trust the directory is pretty bad.
Pretty simple really: do the ads for the frying pan make the direct claim that the pan will put you on the path to becoming highly paid chef? Perhap opening a Michelin-starred restaurant with the skills your new pan has unlocked?
"you can cook better food" and "you can drastically improve your economic situation" are two very different promises (or implications) that should be held to very different standards.
Yep, this is the thesis behind them. I wish people engaged more fully with this argument: it’s possible to believe that security vendors won’t do a good job of upholding their side of the bargain, but I’ve yet to see anybody argue that rather than making a faulty universalization argument against cooldowns.
> How many people are paying security firms to test these things during the cooldown period?
More than I think should be, frankly. More than enough for a sustainable industry.
As for “which firms”: if you Google any of the recent dependency compromises, you’ll see their names. My rough guess is that there are somewhere between 12 and 20 active players in the “supply chain security” space, and they generally compete for mindshare with blogspam. That’s not to say their scanning results aren’t good, though.
Anything that isn't blatantly obvious zero effort malware is gonna wait for the cooldown to expire and then gradually introduce backdoors or vulnerabilities in subsequent versions once the project has gained trust.
I think you’re talking about something different than the median case here: the kinds of malware that cooldowns are effective against are attacking already trusted projects, e.g. via repository compromise.
I think it remains to be seen whether the economics of this kind of “supply chain” compromise support a stealthier actor profile: the whole reason to compromise an OSS project rather than exploit a single victim’s browser or phone is to smash-and-grab en masse. That’s a fundamentally noisy and delay-sensitive attacker profile.
If this is the idea, why don't we let the dedicated security firms and/or automated scanners find the vulnerabilities before the release?
You need an early release in the "given enough eyeballs all bugs are shallow" world because you need the eyeballs, but if you count on specialists and scanners no general availability release is necessary and hence no cool down.
Because this isn't about guarding against general vulnerabilities. This is about guarding against a class of supply chain attack where an attacker compromises the packaging system in a way that they slip in a malicious release.
It is true if everyone waits a cooldown (I don't like this name, but that's another thing) period, then it doesn't solve anything, but as others have pointed out, just because you don't build off the cooldown doesn't mean you and others aren't watching the releases.
Closing the window makes the burden of hiding the exploit higher, which is I think objectively an improvement of security posture.
Currently we release software to the public early and let people find vulnerabilities after release. A few early updaters get burned but the rest of us is saved. This cannot go on.
One idea to get out of this mess is to use cooldowns. But this idea only works if what GP said is true: Vulnerabilities are mostly found by (paid) specialists and advanced tools and not the general user populations.
My point is that, if that is true we do not need to release insecure software. Do the magic before the release and no one gets hurt.
the we/you are different in each case. say I maintain some package, foo, and I want to publish foo-3.5 which contains a security issue. in the cooldown scenario I push the new version to the package repository (rubygems/pip/npm/whatever), and the package manager when asked to `install foo` continues reporting 3.4 as the latest version until the cooldown period has passed. this happens automatically for all packages and all end users. simultaneously, a security firm could look at the log of new package submissions and take a closer look at anything that triggers their "this is an important/widely used package" filter, and if they find something during the cooldown period the new release could be removed from the repository without anyone having installed it.
in the "find the vulnerability before release" scenario, how do I push version foo-3.5? is it my responsibility as the package author to find a security firm and have them audit it before submitting to the repository? should the org owning the repository shunt my package update to a holding pen until it can be vetted, and if so do they have to pay a designated security firm and give them special access to the holding pen, or can anyone reads the incoming packages and help vet them? and if no one has looked at a package in a while do you delay it indefinitely or so you let it time out and be released? that's basically back to the cooldown idea, only implemented on the server rather than the client, and therefore not letting individual clients tune what they believe is a good cooldown time.
I was investigating that for entirely unrelated reasons just yesterday and the answer so far seems to be "none". You can patch the server to serve the locally built frontend and it all works just fine.
I believe it’s slightly different in that I can declare a value (or parameter) of type T and know that it can’t be null/invalid.
Consider this Java method:
void frobnicate(bar Bar)
{
// is bar null? Who knows?
}
To get the same behavior in Helix, one would have to declare the parameter type as “Bar?”. If the parameter type is plain “Bar”, callers can still pass you a “Bar?”, but presumably you’d get an NPE at the call site and not somewhere further down the stack.
I’ve never heard of this language before today and don’t have an opinion on it, but I do find the Questionable Types interesting: sort of collapsing Option and Result into one very concise notation.
You get safety for the non-questionable types. But it seems like if you're going to have questionable types, you're better off not letting users silently treat them as if they aren't questionable and then risk crashing at runtime.
One simple idea* would be an option to exclude certain React elements from auto translation. That would allow users to handle these specific cases “manually” while still reaping the benefits of the automated system the other 99% of the time.
we've added support for both these cases actually! :)
1. `data-lingo-skip` - excludes a jsx node from i18n
2. `data-lingo-override-<locale code>` - overrides version in <locale code> language with a custom value
3. also `data-lingo-context`
2. I have had good luck using pragma comments for that kind of thing: a way to communicate to the infrastructure without the target system seeing it
3. From the "malicious compliance department," I would also accept "include it but in a tautological way" (tenant_id = :ten_id or tenant_id <> :ten_id)
Echoing the comment below (above), since we can fingerprint queries using the Postgres parser, we can create an allow list and a more fine-grained ruleset.
> Since XHP executes on a server that emits HTML, the most that you can do relatively seamlessly is to replace parts of an existing markup with the newly generated HTML markup from the server by updating innerHTML of some DOM node.
It’s a very long post so maybe I missed it, but does Dan ever address morphdom and its descendants? I feel like that’s a very relevant point in the design space explored in the article.
I’m curious, are you running GoodJob in the same database as the application? For smaller scale stuff this is super convenient, but I wonder if it will become a problem at higher loads.
Followed by:
> Delivery is worth being precise about, because git never carries this. Cloning a hostile URL does nothing, and neither does fetch or pull.
AI slop nothing burger. The “exploit” has nothing to do with coding agents.
reply