google_1p_code fails every entry in the current log. The target in cmd/verifier/verifier.go points only at developers.google.com/android/binary_transparency/google1p, whose checkpoint has been at size 134 since 2026-03-30. The README lists https://www.gstatic.com/android/binary_transparency/google1p/jwt/2026/01/ as the latest shard. It's at 226 entries with none shared with the old log (192 Messages, 20 as.oss, 7 contactkeys, 7 safetycore). For example, this payload returns FAILURE: payload not verified in any log:
4bc401f3273c355a06b44cf4c0fc91e2943b8cb9b8685f0f2fda1eb409b4d7c5
SHA256(Signed Code Transparency JWT)
com.google.android.apps.messaging
322660063
It verifies after three changes: add gstatic.com/android/binary_transparency/google1p/jwt/0 to the origins in internal/checkpoint/checkpoint.go, add a target for the new base URL with the same key under that name, and use tileHeight: 8 for it (1 gets a 404 on tile/1/7/000.p/1). Keeping the old log as a fallback target, the way google_1p_apk does, would cover both. The google1p log_details page also still points at the old checkpoint and package_info.txt.
Cache cleanup never removes anything. In internal/tiles/reader.go:264 the loop lists targetDir but builds the path to remove as filepath.Join(abtCacheDir, entry.Name()), so os.Remove targets a file that doesn't exist. I put an image_info.txt_1000 dated January into <cache>/pixel/, ran --log_type=pixel to download image_info.txt_1109, and the old file was still there. For google_1p_apk each change in the 2026/01 tree size leaves another 210 MB package_info.txt_<size> behind.
Smaller: the 30 second Timeout on httpClient (reader.go:123) covers reading the body, so fetching the 210 MB package_info.txt needs about 56 Mbps. It failed with context deadline exceeded here while another download shared the link, and passed in 11 seconds without one.
google_1p_codefails every entry in the current log. The target incmd/verifier/verifier.gopoints only atdevelopers.google.com/android/binary_transparency/google1p, whose checkpoint has been at size 134 since 2026-03-30. The README listshttps://www.gstatic.com/android/binary_transparency/google1p/jwt/2026/01/as the latest shard. It's at 226 entries with none shared with the old log (192 Messages, 20 as.oss, 7 contactkeys, 7 safetycore). For example, this payload returnsFAILURE: payload not verified in any log:It verifies after three changes: add
gstatic.com/android/binary_transparency/google1p/jwt/0to the origins ininternal/checkpoint/checkpoint.go, add a target for the new base URL with the same key under that name, and usetileHeight: 8for it (1 gets a 404 ontile/1/7/000.p/1). Keeping the old log as a fallback target, the waygoogle_1p_apkdoes, would cover both. The google1plog_detailspage also still points at the old checkpoint andpackage_info.txt.Cache cleanup never removes anything. In
internal/tiles/reader.go:264the loop liststargetDirbut builds the path to remove asfilepath.Join(abtCacheDir, entry.Name()), soos.Removetargets a file that doesn't exist. I put animage_info.txt_1000dated January into<cache>/pixel/, ran--log_type=pixelto downloadimage_info.txt_1109, and the old file was still there. Forgoogle_1p_apkeach change in the 2026/01 tree size leaves another 210 MBpackage_info.txt_<size>behind.Smaller: the 30 second
TimeoutonhttpClient(reader.go:123) covers reading the body, so fetching the 210 MBpackage_info.txtneeds about 56 Mbps. It failed withcontext deadline exceededhere while another download shared the link, and passed in 11 seconds without one.