So everything was working fine for months, verification was successful for many months. This morning I woke up to the error message, which I was not able to fix in any meaningful way. In the online remote verification I removed the device and re-added it.

Is something broken with the latest GOS update? I swear I did not install anything new, and I am also lacking any clear instructions what to do when the verification fails... please help

    doffactory This morning I woke up to the error message

    What error message?

    doffactory I removed the device and re-added it

    If the Attestation website says Pinned OS: GrapheneOS (unmodified official release) then you're okay.

    Looks like you have a Pixel 7. You can also verify the boot key hash is the same as what's listed on the website here: https://grapheneos.org/install/web#verified-boot-key-hash. You can verify it's correct on your phone right as it's booting up or on the attestation website.

    On the attestation website, it should say: Pinned verified boot key hash: [The key listed on the GrapheneOS website, except in uppercase. For this hash, upper/lower case doesn't matter.]

      unwat Looks like you have a Pixel 7. You can also verify the boot key hash is the same as what's listed on the website here: https://grapheneos.org/install/web#verified-boot-key-hash. You can verify it's correct on your phone right as it's booting up or on the attestation website.

      Hey unwat, I have a question about this for you. If I can verify it visually like this as you said, then what is the usefulness of doing it via the auditor? Does the auditor provide continuous verification or something?

        User2288

        I'm not entirely sure. From what I understand based on what the lead developer has said about Auditor, it does more than Android Verified Boot.

        AVB uses the boot hash only to verify boot and I believe I remember reading the firmware? This page says AVB gets hashes of read-only partitions and checks them against expected hashes.

        From Auditor's website saying it does more than AVB:

        It builds upon the hardware-based verification of the operating system by chaining verification to the app to perform software-based sanity checks and gather additional information about device state and configuration beyond what the hardware can attest to directly.

        And this part kind of covers what extra stuff Auditor checks.

        The key attestation feature provided by the hardware-backed keystore provides direct support for attesting to device properties and bootstrapping the Trust On First Use model of the Auditor app with a basic initial verification chained up to a known root certificate. The latest version of key attestation provides a signed result with the verified boot state, verified boot key, a hash of all data protected by verified boot and the version of the operating system partitions among other properties. It also has support for chaining trust to the application performing the attestation checks, which is used by the Auditor app for bootstrapping checks at the software layer.

        So this is why I asked what the specific error was to help OP check if it's more of an informational thing than a real error. Some errors are easily fixed/explained, like for example this one: https://discuss.grapheneos.org/d/3113-invalid-number-of-auditor-app-signatures. The error they were getting sounds very bad, but it was caused by a known problem and fixed with a reboot. If the error continued to show up after a reboot, then that could mean something was really messed up.