alt Hacker News> .41 and .42 were triggered directly from the repository. One was triggered by the UltralyticsAssistant account and included a human bypass, which strongly suggests that the attacker controlled (and maybe still controls) that bot account.
Ah, but if they controlled the bot then didn't they have other problems too? If that is the case, then disregard my comment. I was under the impression that this was not the attacker.
> That would be search.sigstore.dev, unless I'm misunderstanding what you mean.
No, that's it in theory I suppose. I did try this but when I used the commit I thought triggered the release (cb260c243ffa3e0cc84820095cd88be2f5db86ca) I did not see it show up.
> Ah, but if they controlled the bot then didn't they have other problems too?
Yep — my theory is that this all starts with the insecure trigger + template injection, and that the attacker exfil’d the bot’s PAT and stale PyPI API token at that point. The first round of attacks used the bot PAT and cache poisoning, and then the attacker pivoted to the PyPI token once the first vector was closed off.
> I used the commit I thought triggered the release (cb260c243ffa3e0cc84820095cd88be2f5db86ca) I did not see it show up
I think I know what’s happening there: that search UI only indexes by commit for attestations produced by gitsign, not every attestation containing a commit. I used it by finding the entry IDs from the release action logs on GitHub Actions, but if/when those are flushed someone who doesn’t already know them will need to seek the log in order to find the attestations.
That’s not ideal; the search.sigstore.dev service would ideally have more indices like crt.sh does.