Good news: The Dell firmware update utility definitely checks whether update executables are signed.

Bad news: Dell is posting unsigned update executables to their website labeled “critical” which then fail to install due to the good news

This firmware update has been periodically failing since I got this laptop from work several weeks ago, and only today did I put in the effort to track down where it was hiding the logs with the real reason. This suggests that not only do they have a process issue that meant an unsigned update got posted, but they have no ability to detect that there’s a 100% failure rate to install after downloading it
@0xabad1dea conspiracy theory: it's the same update they uploaded to Windows Update and WU will install it without signature checking 🦋
@0xabad1dea People keep being upset about "telemetry". But that's the kind of telemetry that you'd want as someone pushing software to people.
@phil 100%, there should always be a chance to say no to telemetry but even if only a fraction of users consent, the 100% failure rate among reporters should be quickly raising a huge red flag somewhere
@0xabad1dea @phil
They might even have one laptop themselves, suitably instrumented 🤷‍♀️
@sabik @phil I can at least understand why they don’t have canary end user laptops set up, because since this is firmware updates, they’d need one for every hardware configuration they’ve shipped in the last decade to reliably catch every issue of this class

@0xabad1dea @sabik @phil is it actually unreasonable for one of the largest hardware integrators on the planet to have some 5-6 figure number of machines configured to run integration tests?

They initially developed all those configurations and allow-listed them as options.

They sell countless millions in warranty and support contracts… isn’t *some* part of the business relying on that compatibility not being broken by first-party updates?

@rvalue @phil @sabik @0xabad1dea They are indeed running the risk of screwing up a support contract at some point or another by letting this lie, indeed.

Or possibly they refuse to provide support contracts that includes this except on very specific hardware for which they actually do what they should've been doing.
@phil @0xabad1dea @sabik Now I’m envisioning the annual Dell all-hands meeting where they run some sort of lottery to find out who will be using the oldest and cruddiest computers for the next year.
@0xabad1dea @phil @sabik > they’d need one for every hardware configuration they’ve shipped in the last decade to reliably catch every issue of this class

Which they really should have, in fact.
@0xabad1dea @phil Telemetry is not needed here at all. The failure would be detected if they even tested the update on a single machine they owned. No need to look at machines they don't own.
@0xabad1dea @phil "Telemetry" is *always* outsourcing your testing expenses onto your users/customers.

@dalias @0xabad1dea No, not always. Having run a big distro within an enterprise, there is no way to test all the combinations your clients have wrt (local) configuration. And machines update from very different base configs. And operations fail in the field.

This does not excuse vendors from skipping acceptance testing as well as they can possibly do it, of course.

This was probably a case of the latter, sure.

@phil @dalias I have to agree that this specific issue really should have been caught in internal testing, and also agree that diagnostic telemetry of the “hey the update failed, here’s the error code” sort will always turn up things that even a very good testing program will miss. I remember once reading an article about Skyrim’s bugginess that pointed out it received more play time in the first 24 hours of release than it did with literal years of a dedicated testing team. So many edge cases per minute
@phil @0xabad1dea There's no need for telemetry for this. They could just keep a number of test machines for everything they release, for just such purposes.
@0xabad1dea they could have gone the crowdstrike route and just bricked the laptop when processing the unsigned update.
@0xabad1dea Juniper support once promised me that it was totally expected for update validation to fail and I should just force it. I was _shocked_ when the forwarding plane didn't come up post update. (Box was in pre-deployment testing otherwise I wouldn't have done something so silly)
@0xabad1dea i literally just gave that away last week, but that would certainly be an explanation for the update loop that happened every time I booted into windows (which was rare) on my Dell XPS13 9650 from 2016 🫣
@0xabad1dea Something something Crowdstrike something something lack of testing something something circle of life
@0xabad1dea May I ask which laptop model it is and which OS it's running? I've never had an issue with the Dell Command Update utility failing to install an update. And we are (almost) exclusively using Dell devices.
@niemalsnever this is the error, it very well may only be this exact update that’s broken. I got some replies confirming they were seeing the same thing. (And someone offered to poke the responsible team directly, so with a little luck, it’s fixed or being fixed right now)
@0xabad1dea Thanks a lot. Fortunately those aren't any of the models we use, though it's interesting that both those models have the same BIOS.
I guess this finally got resolved recently, because my work laptop wanted to install a dozen updates from Dell that presumably all depend on the one that was unsigned and uninstallable for months
@0xabad1dea so, you went ahead and patched out the signature check, right?
@0xabad1dea can I have details please; privately if needed. I can certainly shout at the correct people.
@0xabad1dea @mkj Don’t mind me. I’ll be over here banging my head against a brick wall
@0xabad1dea Sometimes I question always buying HPs... then I look over at the Dells...
Maybe not the best, but never had issues with the things.
@0xabad1dea you can't have everything right :)
@0xabad1dea once with experts… 😹
@0xabad1dea That’s some Manjaro level incompetence 😵
@0xabad1dea task failed successfully