> It is telling about what we prioritize in our society.
No it's not.
It's a measure of what people want accomplished, are least interested in doing themselves, and feel capable of reviewing enough to delegate to a known lair.
Permission and timing gotchas in /tmp predate snap and systemd. It's why things like `mkstemp` exist.
I remember cron jobs that did what systemd-tmpfiles-clean does before it existed. All unix daemons using /tmp run the risk of misusing /tmp. I don't know snap well enough to say anything about it makes it uniquely more susceptible to that.
The exploit doesn't rely on the path being predictable though.
As I read it the .snap is expired and pruned, then the exploiter makes their own .snap in /tmp, then snap-confine assumes that the new .snap is the old one and executes with elevated privileges.
So, the path can be from mkstemp, or a sha-256 of your significant others fingerprint, it doesn't matter; until it expires it's plaintext in the /tmp listing.
{Wild, ignorant speculation follows ... hashing the inode and putting a signed file in the folder bearing that hash, then checking for that ... something that works but along those lines might be appropriate. (We know the inode for the 10 days we're waiting for /tmp/.snap to get pruned; time that might be used to generate a hash collision, so my off-the-cuff suggestion is definitely no good. It feels like there's a simple solution but everything I can think of fails to KPA, I think -- perhaps just use dm-crypt for the /tmp/.snap folder?}
Or just assert the UID and GID of /tmp/.snap before using. Of course, you'd want to open(2) /tmp/.snap and use fstat(2) on a descriptor (not just pass the path, /tmp/.snap, to stat(2)), then use mkdirat, openat & friends consistently.
Yes, it does. The attacker knows that snap is going to look in /tmp/.snap/, instead of e.g. /tmp/.snap.FjBz8oEWaU/ (which isn't guessable in advance) so when /tmp is flushed, he just has to recreate /tmp/.snap/ before snap-confine does, and drop his payload there.
> The arguments I've heard against it are almost all slippery-slope (e.g. "they're gonna do this first, and then add ID requirements next year, because that's what I fear will happen.")
And the arguments for it don't promise to fight tooth and nail not to make sure it's not slippery. If the slope does turn out to be slippery, today's proponents will be tomorrow's Hindsight Harrys (e.g. "the cat's already out of the bag, if you cared so much you should have fought this back when we all saw it coming").
> By late 2024, FedRAMP reviewers concluded that they had little choice but to authorize the technology — not because their questions had been answered or their review was complete, but largely on the grounds that Microsoft’s product was already being used across Washington.
The article talks a lot about conflicts of interest, but this is the line I went looking for. A bureaucracy fighting itself over goal prioritization, and what's a necessary roadblock vs red tape is the less sexy but more meaningful problem at the core of this.
Once the government decided they wanted the product, they were going to find a patsy.
If you "went looking for" this line, you're just reading into the statements your preconceptions.
I on the other hand have no expectation, and so it's not clear whether the "bureaucracy fighting itself" is a cause or a symptom. You're implying it's a cause and the solution is "less red tape". But it could be just a symptom of conflicts of interest, and less red tape just leads to more efficient corruption.
Again, you're just reading into it what you already believe in.
> the core gameplay loops work just fine without it.
Of course it's functional, it has to string people along for enough time to get them to start paying.
That doesn't mean grinding a system tuned to get you hooked enough to give up and pay is a 'just fine' as a game. It's openly deliberate malicious design.
These smell like the kind of metrics that cause someone to feel informed and then to miss the forest for the trees. The kind of data for a "data driven" decision maker who will just invent a narrative to explain the numbers, and then do what they wanted to do all along.
> These smell like the kind of metrics that cause someone to feel informed and then to miss the forest for the trees. The kind of data for a "data driven" decision maker who will just invent a narrative to explain the numbers, and then do what they wanted to do all along.
> We need to increase reliability in the kernel, so the kernel team should fire the top 5 bug-introducers, to reduce the amount of bugs being introduced (https://pebblebed.com/blog/kernel-bugs-part2/05_author_analy...). Linus has got to go.
You've cut bugs being introduced while also reducing development costs by slashing team size. You deserve a promotion and an increase in equity.
117 people meet this criteria. And the impact is dramatic:
It’s strange to me to think of “bugfixes” in terms of a commodity. Different problem spaces between subsystems and thus different types of (and surfaces for) bugs; different contributor mixes; different number of eyes on them; different potential impacts…
> CAN bus drivers top the list [of bug lifetime by subsystem]. These are used in automotive and industrial systems. Critical infrastructure with few maintainers watching.
…or maybe higher-quality initial submissions, with most of the easy bugs already wrung out of them, so only subtle bugs remain (thus fewer to fix).
Or adequately vigilant maintainers but low diversity of systems running that code, thus fewer users/situations where the bugs manifest, so they go unreported. Or poorer telemetry so an ordinary rate of latent bugs but they go undetected.
Could be any, probably a little of all, can’t really tell from the analysis; and each cause would suggest a different response to improve quality.
I’d expect an LLM to use correct grammatical number in the first sentence that you quoted. As written, the demonstrative ‘this’ has singular number but ‘criteria’ plural.
>PMs coding unlocks a whole new category of work, mainly addressing the long tail of cool ideas/small optimisations that ordinarily would not be addressed
So you get to cowboy code, but I don't. I see how it is.
> Premium to be able to "Jump Ahead to parts other users think are valuable".
This is Google's euphemism for building a SponsorBlock equivlient into youtube. It just sounds terrible if they come out and tell you that in addition to removing their ads, they're selling an adblocker. They don't want you adblocking their ads, but they'll gladly charge you to do it to someone else.
> Maybe the people on charge have personally invested heavily in Kick?
Twitch is owned by Amazon. AWS sells the streaming tech Twitch uses to Kick.
Amazon would probably rather sell IVS to Kick than try and figure out how to make Twitch profitable. Or the just don't care enough to notice the people at Twitch are just LARPing at business.
Yeah the other story I refer to isn't using time as an excuse to block architectural improvements though. We get time for both new features and tech debt.
But if your idea blows out the quarter it had bettet be game changing!
No it's not.
It's a measure of what people want accomplished, are least interested in doing themselves, and feel capable of reviewing enough to delegate to a known lair.
reply