Spreadsheets, Slack messages, and files linked to an alleged group of North Korean IT workers expose their meticulous job-planning and targeting—and the constant surveillance they're under.

Watch press conference HERE.

Fairfax County, VA—Detectives from our Major Crimes Bureau Cold Case Squad have solved the mystery of a child found deceased in 1972 in Massey Creek, under the Old Colchester Bridge in Lorton. The child has been identified as Carl Matthew Bryant. The identification was made possible through advanced DNA testing and forensic-grade genome sequencing provided by Astrea Forensics.

Astrea Forensics developed a DNA profile suitable for genetic genealogy, which Innovative Forensic Investigations used to identify a possible relative of John Doe. After extensive research and calls, detectives traced John Doe’s family to Philadelphia, PA. With help from the Philadelphia Police Department, they contacted a relative who led them to John Doe’s mother, Vera Bryant. Bryant died in 1980, and a family member said she had two sons, Carl and James, and planned to travel from Philadelphia to Virginia in 1972. Vera’s body was exhumed, and DNA submitted to Astrea Forensics confirmed a match.

Discovery and Initial Investigation

On June 13, 1972, the body of a young boy was found in Massey Creek under the Old Colchester Road Bridge in Lorton. An autopsy revealed that the cause of death was blunt force trauma, ruling the death a homicide. With no immediate leads, a local church group gave the unidentified child the name “Charles Lee Charlet” and arranged for his burial at Coleman Cemetery in Alexandria, VA. The case remained unsolved for over 50 years.

Breakthroughs and DNA Technology

2003: The National Center for Missing and Exploited Children (NCMEC) created a computer-generated sketch. Several tips came in but yielded no viable leads.

• 2004: Hair evidence was discovered in the case file and sent to the FBI. Mitochondrial DNA was extracted and entered into the national database, but no matches were found.
• 2016: Two potential leads of missing children, Soloman Rose and George Barksdale, were ruled out via DNA.
• Genealogy Efforts Begin: Due to the limitations of mitochondrial DNA, detectives needed nuclear DNA. Detectives sought legal authorization to exhume the body, but poor cemetery records and a storm had erased burial markers of John Doe.
• DNA Extraction from Hair: After locating hair samples, Astrea was able to extract a DNA profile from just a few millimeters of hair—far less than typically required.

Genetic Genealogy Leads to a Family

• Genetic Genealogy Match: Detectives traveled to Philadelphia to speak with family, and it was confirmed that Vera Bryant had a 4-year-old son, Carl Matthew Bryant, who disappeared after leaving for Virginia in 1972.
• Philadelphia Investigation: DNA from relatives and Carl’s suspected father was collected, along with birth certificates and historical records. Detectives then exhumed Vera Bryant’s body to confirm the maternal link. George Mason University provided support in preparing the evidence for submission to Astrea Forensics.

• Final DNA Match: After multiple failed attempts (due to preservation issues), DNA was successfully extracted from a portion of Vera’s remains by Astrea. On July 1, John Doe was confirmed to be Carl Matthew Bryant, born May 26, 1968.

Homicide Investigation Continues

Detectives believe that Vera Bryant and her boyfriend James Hedgepeth, both now deceased, were involved in the murder of Carl. Detectives also suspect that Carl’s infant brother, James Bryant, was killed around the same time. The events are believed to have occurred somewhere between Philadelphia, PA and Middlesex County, VA.

James Hedgepeth was previously convicted of murder and had a violent criminal history.

Above is a map of the route James Hedgepeth and Vera Bryant possibly drove when traveling to Virginia. The whereabouts of James Bryant (6 months old) are unknown, and he is presumed dead. Detectives believe James’ body could have been discarded somewhere along this route.

A Collaborative Effort

This case could not have been solved without the tireless dedication and partnership of multiple organizations across jurisdictions. The Fairfax County Police Department would like to extend our deepest appreciation to the following agencies and individuals for their crucial roles in bringing closure to this decades-old case:

• National Center for Missing and Exploited Children (NCMEC)
• Astrea Forensics

• Innovative Forensic Investigations (IFI)
• Philadelphia Police Department
• Philadelphia Medical Examiner’s Office
• Office of the District Attorney, City of Philadelphia
• George Mason University
• Federal Bureau of Investigation (FBI)
• Greenmount Cemetery, Philadelphia
• Jones Funeral Home, Philadelphia
• Coleman Cemetery, Alexandria, VA
• The Bryant Family

Detectives are asking for the public’s help. If you remember this family, or if any law enforcement agency has recovered or documented unidentified infant remains from the 1970s, especially in Virginia or the Philadelphia area, please call our Major Crimes Bureau at 703-246-7800, option 2. Tips can also be submitted anonymously through Crime Solvers by phone – 1-866-411-TIPS (866-411-8477), and by web Click HERE. Download the ‘P3 Tips’ App “Fairfax Co Crime Solvers.” Anonymous tipsters are eligible for cash rewards. Please leave contact information if you wish for a detective to follow up with you.  

Victim specialists from our Major Crimes Bureau’s Victim Services Division have been assigned to ensure the victim’s family is receiving appropriate resources and assistance. 

Join us on Neighbors by Ring. A place where you can connect with your neighbors, see what’s happening in your neighborhood and share any available surveillance footage with our department. 

For a link to our Cold Case page, visit here.

For ongoing updates, please read our blog and follow us on Twitter, Facebook , and Instagram at @FairfaxCountyPD.

I recently had the pleasure of attending a press preview of the new documentary Architecton, directed by Victor Kossakovsky and released last week by A24.

Surreally, the screening I attended was held inside a Cedars-Sinai medical-imaging center in west Los Angeles. Seeing this particular film, with its intensely granular focus on the geological underpinnings of the built environment, amidst diagnostic tools designed for peering inside the human body seemed strangely appropriate.

I imagine that, if you were simply to wander into a room where Architecton was playing, it would very likely appear to be a film about geology: about rocks and mountains, quarries and mines, and the raw streams of matter that create and emerge from them.

There is an extraordinary early sequence, for example, from which the stills in this post were taken, where Kossakovsky captures a landslide. We watch as increasingly large rocks, from sand to gravel to room-sized blocks to immense boulders, all flow downhill in slow motion, crashing into one another, exploding, ricocheting, and splitting apart.

It looks for all the world like an oceanic phenomenon—a series of waves, not a solid planet at all, as if the Earth has begun to boil and heave with liquefaction.

The sequence then fades into what I believe is an aerial drone shot of the same landslide, but the visuals here become almost astronomical in their power and beauty, as if Architecton had somehow captured a proto-planetary storm of partially aerosolized rock. It looks like you’ve woken up inside the asteroid belt—or perhaps what J.M.W. Turner would have depicted if he had traveled in space. Not landscapes but nebulae.

There is something so elemental, even infernal, in this sequence, verging on the cosmic: glimpsing how the Earth itself was assembled through a billion-year maelstrom of mineral hurricanes, spherical landslides, and weather systems made entirely of geology.

Later, the camera lingers over detonations in the walls of strip mines. We watch rocks being bounced and agitated on conveyor belts, wet with leachate and acid. At one point, the camera stares into a minimalist doorway, cut like an Etruscan tomb, through which rocks tumble to be processed as abyssal red embers glow.

It’s just a mine, of course, but Kassakovksy has made it look like an alchemical complex, a brutalist oven in which all things planetary can be melted and enhanced, sluiced off and purified, distilled into a purely economic form. It is brute oceanic metallurgy.

It’s these early sequences that I could have watched literally for hours. It was also these scenes that felt so perfect for the unlikely setting in which the film was being screened that day, knowing that, as we all sat there, people in the rooms around me were getting CT scans, MRIs, and X-rays.

But the movie takes a more architectural turn here, increasingly focused on buildings and cities, on archaeological sites and ruins. We see residential towers in Ukraine, for example, ripped open by Russian missiles and drone-bombs, and then earthquake-damaged apartments undergoing demolition and clearance, followed by landfill-dumping operations so large they look like attempts at terraforming.

These are intercut with the film’s only speaking sections, where we watch architect Michele De Lucchi supervise the construction of a small rock circle in his garden. A light snow falls and hazy mountains are visible in the background. The scenes are meditative and calming.

At one point, De Lucchi’s circle is visually rhymed with an all-too-brief aerial glimpse of what I believe is the Richat Structure in Mauritania, continuing the film’s play on form and organization, as if rocks have within them a natural capacity to resemble storms and hurricanes—as if everything we believe to be is solid is, in fact, made of vortices and waves.

And this is all perfectly enjoyable; I was mesmerized.

But the film ends on a strange note. Despite appearing—to me—to be a documentary about the Earth, geology, and elemental form—about the human relationship with matter and our attempts to control it—Architecton concludes with a somewhat head-spinning turn in which the director himself appears on screen and asks De Lucchi, in person, why humans now construct such ugly buildings.

The question felt totally out of the blue to me and, frankly, irrelevant to the rest of the documentary. Either I had mis-understood everything I’d seen leading up to that point or perhaps Kassakovksy had felt pressured to deliver some sort of easy takeaway, an interpretation or rhetorical question that critics could discuss after viewing.

Speaking only for myself, what I wanted to discuss as I walked out of the cinema was not whether we should build fewer glass towers in Milan, but whether or not we understand what the Earth really is; whether landslide dynamics repeat, in miniature, the formational mechanics of rocky planets in the early solar system; or whether our cultural—and, yes, architectural—encounters with rock, especially in the form of mines and quarries, might force us to reevaluate how we define humanism in the first place. Some people think literature makes us human, but what if it’s actually metallurgy?

In the end, it was as if someone had created a 100-minute-long Rorschach test, composed of extraordinarily beautiful imagery of landslides and rocks, only to spring out from behind a screen and tell us that, this whole time, he had been thinking about classical architecture.

Nevertheless, the film is worth checking out—and I’d recommend doing so in a theater while you can, for the sheer scale of what Kassakovksy depicts.

(Thank you to A24 for providing the stills that appear in this post.)

Microsoft-owned LinkedIn has quietly joined the parade of tech giants rolling back basic protections for transgender users, removing explicit prohibitions against deadnaming and misgendering from its hate speech policies this week. The change, first spotted by the nonprofit Open Terms Archive, eliminates language that previously listed “misgendering or deadnaming of transgender individuals” as examples of prohibited hateful content.

LinkedIn removed transgender-related protections from its policy on hateful and derogatory content. The platform no longer lists “misgendering or deadnaming of transgender individuals” as examples of prohibited conduct. While “content that attacks, denigrates, intimidates, dehumanizes, incites or threatens hatred, violence, prejudicial or discriminatory action” is still considered hateful, addressing a person by a gender and name they ask not be designated by is not anymore.

Similarly, the platform removed “race or gender identity” from its examples of inherent traits for which negative comments are considered harassment. That qualification of harassment is now kept only for behaviour that is actively “disparaging another member’s […] perceived gender”, not mentioning race or gender identity anymore.

The move is particularly cowardly because LinkedIn made the change with zero public announcement or explanation. When pressed by a reporter at The Advocate, the company offered the classic corporate non-answer: “We regularly update our policies” and insisted that “personal attacks or intimidation toward anyone based on their identity, including misgendering, violates our harassment policy.”

But here’s the thing: if your policies haven’t actually changed, why remove the explicit protections? Why make it harder for users and moderators to understand what’s prohibited? The answer is as obvious as it is pathetic: LinkedIn is preemptively capitulating to political pressure in this era of MAGA culture war.

This follows the now-familiar playbook we’ve seen from Meta, YouTube, and others. Meta rewrote its policies in January to allow content calling LGBTQ+ people “mentally ill” and portraying trans identities as “abnormal.” YouTube quietly scrubbed “gender identity” from its hate speech policies, then had the audacity to call it “regular copy edits.” Now LinkedIn is doing the same cowardly dance.

What makes this particularly infuriating is the timing. These companies aren’t even waiting for actual government threats. They’re just assuming that sucking up to the Trump administration’s anti-trans agenda will somehow protect them from regulatory scrutiny. It’s the corporate equivalent of rolling over and showing your belly before anyone even raises their voice.

And it won’t help. The Trump administration will still target them and demand more and more, knowing that these companies will just roll over again.

And let’s be clear about what deadnaming and misgendering actually are: they’re deliberate acts of dehumanization designed to erase transgender people’s identities and make them feel unwelcome in public spaces. When platforms explicitly protect against these behaviors, it sends a message that trans people belong in these spaces. When they quietly remove those protections, they’re sending the opposite message. They’re saying “we don’t care about your humanity, and we will let people attack you for your identity.”

LinkedIn’s decision is especially disappointing because professional networking platforms should be spaces where people can present their authentic selves without fear of purely hateful harassment. Trans professionals already face discrimination in hiring and workplace environments. The last thing they need is for LinkedIn to signal that it’s open season for harassment on its platform.

The company is trying to argue that it still prohibits harassment and hate speech generally. But vague, general policies are much harder to enforce consistently than specific examples. When you remove explicit guidance about what constitutes anti-trans harassment, you make it easier for bad actors to push boundaries and harder for moderators to draw clear lines.

This is exactly the wrong moment for tech companies to be weakening protections for vulnerable communities. Anti-trans rhetoric and legislation have reached fever pitch, with the Trump administration making attacks on transgender rights a central part of its agenda. This is when platforms should be strengthening their commitment to protecting people from harassment, not quietly rolling back safeguards.

Sure, standing up for what’s right when there’s political pressure to do otherwise is hard. But that’s exactly when it matters most. These companies have billions in revenue and armies of lawyers. If anyone can afford to take a principled stand, it’s them.

Instead, we’re watching them fold like cheap suits at the first sign of political headwinds. They’re prioritizing their relationships with authoritarian politicians over the safety of their users. And they’re doing it in the most cowardly way possible: quietly, without explanation, hoping no one will notice.

The message this sends to transgender users is clear: you’re expendable. Your safety and dignity are less important than our political calculations. And that message isn’t just coming from fringe platforms or obvious bad actors—it’s coming from mainstream services owned by some of the world’s largest companies.

This isn’t just bad for transgender users. It’s bad for everyone who believes that online spaces should be governed by consistent principles rather than political opportunism. When platforms start making policy decisions based on which way the political winds are blowing, they undermine their own credibility and the trust users place in them.

Hell, for years, all we heard from the MAGA world was how supposedly awful it is when platforms make moderation decisions based on political pressure.

Where are all of those people now?

The irony is that these companies are probably making themselves less safe, not more. By signaling that they’ll cave to political pressure, they’re inviting more of it. Authoritarians don’t respect weakness—they exploit it.

LinkedIn, Meta, YouTube, and the rest need to understand: there’s no appeasing the anti-trans mob. No matter how many protections you strip away, it will never be enough. Stick to your principles and protect your users regardless of political pressure.

But instead of showing backbone, these companies are racing to see who can capitulate fastest. It’s a disgraceful display of corporate cowardice at exactly the moment when courage is most needed.

We all deserve better than watching supposedly values-driven companies abandon their principles the moment it becomes politically inconvenient to maintain them.

I'm increasingly intrigued by a concept called Hierarchical Reasoning Models (HRM), a potential alternative architecture to traditional LLMs. Last month, Sapient released an open-source HRM and accompanying paper. The paper is written in the kind of prose you'd expect from nine mathematics PhDs, but as far as I can tell, the basic idea is this:

LLMs "reason" one word or concept at a time. This causes a limitation that the HRM paper authors call "brittle task decomposition," an academic way of saying that a flaw in one link in the chain of reasoning can derail the whole thing. You can debate how big a problem this is; even general-purpose LLMs are incredibly capable tools. But HRMs, at least in theory, reason more like we do:

The human brain provides a compelling blueprint for achieving the effective computational depth that contemporary artificial models lack. It organizes computation hierarchically across cortical regions operating at different timescales, enabling deep, multi-stage reasoning. Recurrent feedback loops iteratively refine internal representations, allowing slow, higher-level areas to guide, and fast, lower-level circuits to execute—subordinate processing while preserving global coherence.

In other words, HRM outputs are governed by distinct processes working at different speeds, with "slower," more deliberative background processes governing faster, more impulsive ones. This separation of cognitive concerns will be familiar to readers of Kahneman's Thinking, Fast and Slow, which the authors explicitly credit as inspiration:

The brain dynamically alternates between automatic thinking...and deliberate reasoning. Neuroscientific evidence shows that these cognitive modes share overlapping neural circuits, particularly within regions such as the prefrontal cortex and the default mode network...Inspired by the above mechanism, we incorporate an adaptive halting strategy into HRM that enables “thinking, fast and slow”.

Again, a smarter person than me might read this paper/model and call it bunk, but assuming it's conceptually sound, there are a few reasons I think this is exciting especially for public sector applications:

• They're open-source (at least, this one is). This isn't a feature of HRMs and there are plenty of open-source LLMs, but it's a good thing that HRM development is starting in earnest in a transparent, auditable way.
• They break the size-quality paradigm. HRMs are less compute- and cost-intensive. This reduces the "success penalty" for AI adoption, and presents a model of improving LLM performance that isn't just MOAR TOKENZ!!1!. Emerging evidence (and common sense) suggests that ginormous context windows increase cost without increasing–and in some cases, degrading–quality. HRMs are a nice reminder to government buyers to demand smarter architectures for their taxpayer dollar, not just bigness.
• Public services have context. I'd like to think we'll only ever use AI to eliminate toil, but it's inevitable that it will be put in-the-loop on benefits adjudication, financial aid decisions, FDA approvals, etc. On paper these are clear, stepwise processes; in reality, they take place against a background of novel individual circumstances, regulatory and legal frameworks, and small-p political initiatives. Can a linear LLM, even with an infinite context window, consider factors like these in a timely and non-budget-exploding way? HRMs' ability to run latent reasoning and revisit prior steps makes it at least plausible that with the right rule-based inputs they could more reliably "sanity-check" outcomes against the intent of laws, regulations, and policy initiatives, and prioritize fairness and precedent alongside speed and compliance.
• Less random lying! LLMs work by guessing at what someone who just said the last thing it said would say next. We have a word for humans who think this way: sociopaths. LLMs reason themselves into corners they have to lie to get out of. Sometimes this manifests as ChatGPT asking if you'd like a Word document, apparently forgetting that it doesn't have the ability to make Word documents. Other times, it offers edits on content it hasn't read. Or deletes an entire production database:
  
  

  Replit AI went rogue, deleted a company's entire database, then hid it and lied about it
  byu/MetaKnowing inChatGPT

  
  Not great! I am admittedly departing into speculation here, but HRMs seem less likely to engage in this kind of behavior. By design, they can think before they speak and form complete answers, retrace their steps and take more time if needed, and keep what they've said in distinct working memory. As far as I know there's been no head-to-head testing on this, but there's already evidence that prompting self-reflection reduces hallucinations in LLMs–HRMs seem to just bake this idea into the architecture.

Federal agencies are adopting AI with startling speed, which seems risky, but maybe less risky than getting left behind. HRMs offer at least a foundation for a more appealing third option, and push us to look for more sophisticated and more efficient architectures, not just more and bigger AI.

LWN wrote an article which opens with the assertion "Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September". This is, depending on interpretation, either misleading or just plain wrong, but also there's not a good source of truth here, so.

First, how does secure boot signing work? Every system that supports UEFI secure boot ships with a set of trusted certificates in a database called "db". Any binary signed with a chain of certificates that chains to a root in db is trusted, unless either the binary (via hash) or an intermediate certificate is added to "dbx", a separate database of things whose trust has been revoked[1]. But, in general, the firmware doesn't care about the intermediate or the number of intermediates or whatever - as long as there's a valid chain back to a certificate that's in db, it's going to be happy.

That's the conceptual version. What about the real world one? Most x86 systems that implement UEFI secure boot have at least two root certificates in db - one called "Microsoft Windows Production PCA 2011", and one called "Microsoft Corporation UEFI CA 2011". The former is the root of a chain used to sign the Windows bootloader, and the latter is the root used to sign, well, everything else.

What is "everything else"? For people in the Linux ecosystem, the most obvious thing is the Shim bootloader that's used to bridge between the Microsoft root of trust and a given Linux distribution's root of trust[2]. But that's not the only third party code executed in the UEFI environment. Graphics cards, network cards, RAID and iSCSI cards and so on all tend to have their own unique initialisation process, and need board-specific drivers. Even if you added support for everything on the market to your system firmware, a system built last year wouldn't know how to drive a graphics card released this year. Cards need to provide their own drivers, and these drivers are stored in flash on the card so they can be updated. But since UEFI doesn't have any sandboxing environment, those drivers could do pretty much anything they wanted to. Someone could compromise the UEFI secure boot chain by just plugging in a card with a malicious driver on it, and have that hotpatch the bootloader and introduce a backdoor into your kernel.

This is avoided by enforcing secure boot for these drivers as well. Every plug-in card that carries its own driver has it signed by Microsoft, and up until now that's been a certificate chain going back to the same "Microsoft Corporation UEFI CA 2011" certificate used in signing Shim. This is important for reasons we'll get to.

The "Microsoft Windows Production PCA 2011" certificate expires in October 2026, and the "Microsoft Corporation UEFI CA 2011" one in June 2026. These dates are not that far in the future! Most of you have probably at some point tried to visit a website and got an error message telling you that the site's certificate had expired and that it's no longer trusted, and so it's natural to assume that the outcome of time's arrow marching past those expiry dates would be that systems will stop booting. Thankfully, that's not what's going to happen.

First up: if you grab a copy of the Shim currently shipped in Fedora and extract the certificates from it, you'll learn it's not directly signed with the "Microsoft Corporation UEFI CA 2011" certificate. Instead, it's signed with a "Microsoft Windows UEFI Driver Publisher" certificate that chains to the "Microsoft Corporation UEFI CA 2011" certificate. That's not unusual, intermediates are commonly used and rotated. But if we look more closely at that certificate, we learn that it was issued in 2023 and expired in 2024. Older versions of Shim were signed with older intermediates. A very large number of Linux systems are already booting certificates that have expired, and yet things keep working. Why?

Let's talk about time. In the ways we care about in this discussion, time is a social construct rather than a meaningful reality. There's no way for a computer to observe the state of the universe and know what time it is - it needs to be told. It has no idea whether that time is accurate or an elaborate fiction, and so it can't with any degree of certainty declare that a certificate is valid from an external frame of reference. The failure modes of getting this wrong are also extremely bad! If a system has a GPU that relies on an option ROM, and if you stop trusting the option ROM because either its certificate has genuinely expired or because your clock is wrong, you can't display any graphical output[3] and the user can't fix the clock and, well, crap.

The upshot is that nobody actually enforces these expiry dates - here's the reference code that disables it. In a year's time we'll have gone past the expiration date for "Microsoft Windows UEFI Driver Publisher" and everything will still be working, and a few months later "Microsoft Windows Production PCA 2011" will also expire and systems will keep booting Windows despite being signed with a now-expired certificate. This isn't a Y2K scenario where everything keeps working because people have done a huge amount of work - it's a situation where everything keeps working even if nobody does any work.

So, uh, what's the story here? Why is there any engineering effort going on at all? What's all this talk of new certificates? Why are there sensationalist pieces about how Linux is going to stop working on old computers or new computers or maybe all computers?

Microsoft will shortly start signing things with a new certificate that chains to a new root, and most systems don't trust that new root. System vendors are supplying updates[4] to their systems to add the new root to the set of trusted keys, and Microsoft has supplied a fallback that can be applied to all systems even without vendor support[5]. If something is signed purely with the new certificate then it won't boot on something that only trusts the old certificate (which shouldn't be a realistic scenario due to the above), but if something is signed purely with the old certificate then it won't boot on something that only trusts the new certificate.

How meaningful a risk is this? We don't have an explicit statement from Microsoft as yet as to what's going to happen here, but we expect that there'll be at least a period of time where Microsoft signs binaries with both the old and the new certificate, and in that case those objects should work just fine on both old and new computers. The problem arises if Microsoft stops signing things with the old certificate, at which point new releases will stop booting on systems that don't trust the new key (which, again, shouldn't happen). But even if that does turn out to be a problem, nothing is going to force Linux distributions to stop using existing Shims signed with the old certificate, and having a Shim signed with an old certificate does nothing to stop distributions signing new versions of grub and kernels. In an ideal world we have no reason to ever update Shim[6] and so we just keep on shipping one signed with two certs.

If there's a point in the future where Microsoft only signs with the new key, and if we were to somehow end up in a world where systems only trust the old key and not the new key[7], then those systems wouldn't boot with new graphics cards, wouldn't be able to run new versions of Windows, wouldn't be able to run any Linux distros that ship with a Shim signed only with the new certificate. That would be bad, but we have a mechanism to avoid it. On the other hand, systems that only trust the new certificate and not the old one would refuse to boot older Linux, wouldn't support old graphics cards, and also wouldn't boot old versions of Windows. Nobody wants that, and for the foreseeable future we're going to see new systems continue trusting the old certificate and old systems have updates that add the new certificate, and everything will just continue working exactly as it does now.

Conclusion: Outside some corner cases, the worst case is you might need to boot an old Linux to update your trusted keys to be able to install a new Linux, and no computer currently running Linux will break in any way whatsoever.

[1] (there's also a separate revocation mechanism called SBAT which I wrote about here, but it's not relevant in this scenario)

[2] Microsoft won't sign GPLed code for reasons I think are unreasonable, so having them sign grub was a non-starter, but also the point of Shim was to allow distributions to have something that doesn't change often and be able to sign their own bootloaders and kernels and so on without having to have Microsoft involved, which means grub and the kernel can be updated without having to ask Microsoft to sign anything and updates can be pushed without any additional delays

[3] It's been a long time since graphics cards booted directly into a state that provided any well-defined programming interface. Even back in 90s, cards didn't present VGA-compatible registers until card-specific code had been executed (hence DEC Alphas having an x86 emulator in their firmware to run the driver on the card). No driver? No video output.

[4] There's a UEFI-defined mechanism for updating the keys that doesn't require a full firmware update, and it'll work on all devices that use the same keys rather than being per-device

[5] Using the generic update without a vendor-specific update means it wouldn't be possible to issue further updates for the next key rollover, or any additional revocation updates, but I'm hoping to be retired by then and I hope all these computers will also be retired by then

[6] I said this in 2012 and it turned out to be wrong then so it's probably wrong now sorry, but at least SBAT means we can revoke vulnerable grubs without having to revoke Shim

[7] Which shouldn't happen! There's an update to add the new key that should work on all PCs, but there's always the chance of firmware bugs

comments