It’s Cannonical. They prefer implementing everything themselves fast, rather than developing a more sustainable project with the rest of the community over a longer timescale. When they do that, there will be very little buy-in from the wider community.

Others could technically implement another snap store for their own distro, but they’d have to build a lot of the backend that Cannonical didn’t release. It’s easier to use Flatpak or AppImage or whatever rather than hitch themselves onto Cannonicals’s homegrown solution that might get abandoned down the line like Mir or Ubuntu Touch.

It’s Cannonical. They prefer implementing everything themselves fast, rather than developing a more sustainable project with the rest of the community over a longer timescale. It makes sense that when they do that, there will be very little buy-in from the wider community. Much like Unity and Mir.

As you say - why would others put time into the less supported system? Better alternatives exist. If Canonical want their own software ecosystem, they’ll have to maintain it themselves. Which, based on Mir and Ubuntu Touch, they don’t have a good track record of.

They’re not converting it back into electricity, this is for industrial process heat. They have 100 units of electrical energy and 98 units go into whatever the industry needs to heat.

Lots of industries use ovens, kilns or furnaces. Mostly fueled by gas at the moment. Using electricity would be very expensive unless they can timeshift usage and get low spot prices. Since they need heat anyway, thermal storage is pretty cheap and efficient.

It’s heat though. They’re turning electricity into heat then moving that heat to where it’s needed, when it’s needed. Making heat from electricity is nearly 100% efficient, and pumping losses for moving fluids are going to be tiny compared to the the amount of heat they can move. They quote the heat loss in storage seperately as 1% per day. It seems reasonable.

I don’t know why you’re getting downvoted. It makes perfect sense that Cannonical made it’s own proprietary package ecosystem and while technically anyone can build their own snap store, ain’t nobody got time for that.

curl shit | sudo bash is just so convenient.

Plus it did land on the barge. Most of the debris should be there, though the remaining fuel would have mainly gone overboard. Probably the flight termination explosives also.

https://xkcd.com/927/

Adding more decoders means more overheads in code size, projects dependencies, maintanance, developer bandwidth and higher potential for security vulnerabilities.

You wouldn’t print a mouse.

Back in my day, mice had balls.

The only thing I can think of is if the sensor is a hall effect sensor that detects something (the switch?) being depressed by the hood. The sensitivity of the hall effect sensor might be tuneable. They may be able to reduce the sensitivity so it still detects a properly closed hood, but reports an improperly closed hood as open.

It’s annoying that the report just says it’s fixed in software without explaining how.

I think Github keeps all the commits of forks in a single pool. So if someone commits a secret to one fork, that commit could be looked up in any of them, even if the one that was committed to was private/is deleted/no references exist to the commit.

The big issue is discovery. If no-one has pulled the leaky commit onto a fork, then the only way to access it is to guess the commit hash. Github makes this easier for you:

What’s more, Ayrey explained, you don’t even need the full identifying hash to access the commit. “If you know the first four characters of the identifier, GitHub will almost auto-complete the rest of the identifier for you,” he said, noting that with just sixty-five thousand possible combinations for those characters, that’s a small enough number to test all the possibilities.

I think all GitHub should do is prune orphaned commits from the auto-suggestion list. If someone grabbed the complete commit ID then they probably grabbed the content already anyway.

Ah - Actually reading the article reveals why this is actually an issue:

What’s more, Ayrey explained, you don’t even need the full identifying hash to access the commit. “If you know the first four characters of the identifier, GitHub will almost auto-complete the rest of the identifier for you,” he said, noting that with just sixty-five thousand possible combinations for those characters, that’s a small enough number to test all the possibilities.

So enumerating all the orphan commits wouldn’t be that hard.

In any case if a secret has been publicly disclosed, you should always assume it’s still out there. For sure, rotate your keys.

Well, sort of. GitHub certainly could refuse to render orphan commits. They pop up a banner saying so but I don’t see why they should show the commit at all. They could still keep the data until it’s garbage collected since a user might re-upload the commit in a new branch.

This seems like a non-issue though since someone who hasn’t already seen the disclosed information would need to somehow determine the hash of the deleted commit.

You fraud.

As far as we know, the input was a file filled with zeroes

CrowdStrike have said that was not the problem:

This is not related to null bytes contained within Channel File 291 or any other Channel File.

That said, their preliminary incident review doesn’t give us much to go on as to what was wrong with the file.

You’re speculating that it was something easy to test for by a third party. It certainly could have been but I would hope it’s a more subtle bug which, as you say, can’t be exhaustively tested for. Source code analysis definitely would have surfaced this bug so either they didn’t bother looking or didn’t bother fixing it.

How would you prove that no input exists that could crash a piece of code? The potential search space is enormous. Microsoft can’t prevent drivers from accepting external input, so there’s always a risk that something could trigger an undetected error in the code. Microsoft certainly ought to be fuzz testing drivers it certifies but that will only catch low hanging fruit. Unless they can see the source code, it’s hard to determine for sure that there are no memory safety bugs.

The driver developers are the ones with the source code and should have been using analysis tools to find these kinds of memory safety errors. Or they could have written it in a memory safe language like Rust.

I’d have thought the cloud side would be pretty easy to script over. Presumably the images aren’t encrypted from the host filesystem so just ensure each VM is off, mount its image, delete the offending files, unmount the image and start the VM back up. Check it works for a few test machines then let it rip on the whole fleet.

Does anyone know how these Cloudstrike updates are actually deployed? Presumably the software has its own update mechanism to react to emergent threats without waiting for patch tuesday. Can users control the update policy for these ‘channel files’ themselves?