0zymandiass

I believe QPR includes security fixes as well, which should trigger the 4 month timer

Your comment seemed to imply that a source release would trigger a different timer than a binary release, which is explicitly covered as the same thing in the law - for both the 4 and 6 month timers.

You've explicitly quoted that source releases are not relevant:

> or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider

They have not released the source code, but they have released an update of their operating system on their reference Pixel hardware.

Therefore, all devices must update within 4 months of that Pixel release, regardless of source drops, per this law

If you'd bothered to read:

```This definition excludes signatures and some metadata and focuses solely on the payload of packaged files in a given RPM:

    A build is reproducible if given the same source code, build environment and build instructions, and metadata from the build artifacts, any party can recreate copies of the artifacts that are identical except for the signatures and parts of metadata.```

A branch doesn't use any more space than a commit... I'm curious what their complaint was with a large number of branches?

There are various repositories with 500k+ commits

Ironically, Microsoft Office also fails to render most of my ODP/ODT files correctly, which are open standards. One might infer it's by design...

It's far less interesting than finding an exploit in git-shell, which was how I read the headline :|

If the conversation is

> Software engineering does not put safety first

I'm 100% agreed.

If the conversation is

> The PinePhone has less quality control than Android/iOS

It's patently false

I would parse the article as the second, as it's referring to a specific phone throughout

The issue is they're heavily implying it's something specific to PinePhone. I just scrolled through the legal notices on an iPhone, and they all have the exact same wording. Small components, such as the graphics libraries, the kernel, health data, the web browser, etc...

(not to mention they're just plain wrong about the battery/thermal not having hardware-level limits)

The CPU isn't what's compromised - this is protecting against a compromised motherboard

There have been a couple in the wild, but they aren't super common.

They've become a bigger concern with UEFI since it has a massive attack surface compared to legacy BIOS.

For a processor sitting in AWS / Azure, they want guarantees, and they're the ones EPYCs are designed for.

The responsibility has to rest with the processor, since it's the only thing executing code prior to UEFI. What it's doing is validating that UEFI was cryptographically signed with the correct key prior to running any UEFI code. When it's first used, it is saving the key for the vendors UEFI implementation and won't allow it to proceed if the root signature ever changes (think something similar to root certs for HTTPS).

It's only relevant to Secure Encrypted Virtualization insofar as they are both implemented inside the PSP which is a separate ARM core that runs at a higher privilege level than the x86 cores (and is the core that actually initializes the x86 cores).

This is how all phones have worked for many years, but apparently it's now becoming a thing in servers too.

BIOS (UEFI) level rootkits

It's not necessarily just Dell, they're just the first to use the feature.

It also won't necessarily work in other Dell motherboards, just ones using the same key as the first.

It's strange Dell would blow the fuses by default, though.