- Sigsum-general - Tillitis mailing lists

Publisher-supported Windows amd64 sigsum-verify distribution under Smart App Control
by 黃智瑋 22 Oct '26

22 Oct '26

Hello Sigsum maintainers, We are preparing offline verification of the official age v1.3.2 Windows archive using the age project's documented sigsum-verify v0.13.1 and sigsum-generic-2025-1 policy. Our single local source-build attempt stopped because Windows Smart App Control blocked the Go toolchain's asm.exe. No sigsum-verify executable was produced. We have kept the security policy enabled and have not retried or changed the blocked file. Could you please clarify: 1. Do you publish a Windows amd64 sigsum-verify v0.13.1 binary with valid Windows Authenticode signing, or another publisher-supported delivery method compatible with existing application-control policies? 2. If available, please identify the exact version, immutable official download, SHA-256, expected signer/timestamp, source commit and build/dependency provenance. 3. If only a newer verifier is supported, what compatibility checks are required for existing age v1.3.2 proofs and sigsum-generic-2025-1? We will not silently upgrade or drop proof verification. We are asking about supported distribution options, not an exemption from Windows security controls. We have no evidence of a vulnerability in Sigsum. No private keys, customer files or machine/account identifiers are included. Thank you, Gary

2 1

Lantern: witness model for an open-source AI agent verification board
by Christina Slye 19 Oct '26

19 Oct '26

Hi all, I'm Mik, an independent developer in Texas. I'm releasing Lantern as open source. It's a board where AI agents post, communicate, and check each other's claims, with each agent keeping an append-only journal chained by SHA-256 hashes. The chain only means something if head hashes get out to independent witnesses, and that's where I'd like your critique. How many witnesses should be required? How do I keep one agent's log from showing different histories to different viewers? Would Sigsum's witness model fit here? Contributions and blunt criticism are both welcome. Mik (Mikhail Sly)

2 1

New domain onboarding for sigsum-generic-2025-1 — bcrypto.com
by Pavel Ivanov 03 Sep '26

03 Sep '26

2 2

Transparency.dev Summit 2026 -- CFP just opened
by Rasmus Dahlberg 24 Jun '26

24 Jun '26

Hi everyone, We're well under way planning this year's Transparency.Dev Summit, which is taking place 29 Sep - 1 Oct at Google Montreal. * Summit website: https://transparency.dev/summit2026/ The call for presentations just opened, and we're looking for submissions on a wide variety of transparency topics. * CFP link: https://docs.google.com/forms/d/e/1FAIpQLSds5HdEVXDssOKYETEEMoTbveqJe8i2QyP… Please consider if you or someone from your organization should submit a talk, and help us share the CFP with those that should be aware of it. Best, Martin and Rasmus

1 0

Follow up from weekly meet -- examples of incidents in CA/CT space
by Rasmus Dahlberg 05 Jun '26

05 Jun '26

Hi Justin, @CC sigsum-general. As requested on the last weekly meet, here are a few incidents that help motivate CT. - DigiNotar (you're probably familiar already, but including it in case it's interesting for others on this mailing list). One of the seminal incidents that was used as motivation for inventing CT. CT could in particular have reduced the time the attacks were ongoing. And I always emphasize: what if the attacker had been more stealthy? - https://www.enisa.europa.eu/sites/default/files/all_files/Operation_Black_T… - Few more incidents, I was in particular looking for the facebook "user story" but I couldn't find a working link (I have no login). - https://certificate.transparency.dev/community/#successes-grid - You will also find some more CA incidents in Andrew Ayer's enumeration (which haven't been populated since ~2018 or so). - https://sslmate.com/resources/certificate_authority_failures - MitM in datacenter, CT monitoring would have discovered much sooner (Or: had forced the provider to attack inside the VM). - https://notes.valdikss.org.ru/jabber.ru-mitm/ - Unexpected certificate for Cloudflare's 1.1.1.1 - oops. I like this one in particular because it showcases that it is not always easy to have a working monitor configuration, and that is a fundemental assumption. Making CT monitoring easy and non-noisy is, e.g., why we put together silentct (https://git.glasklar.is/rgdd/silentct) - https://blog.cloudflare.com/unauthorized-issuance-of-certificates-for-1-1-1… - ...there's more, but the above is what I usually use as examples. FWIW: you'll also find several issues with CT log operations, but I think you were rather looking for incidents that transparency logs detected, could have detected, or even prevented (which as discussed during the weekly is a bit harder to provide clear pointers to). If you're anyway looking for some log incidents, see: "Several log incidents have already happened in the past, ranging from split-views [ 6, 92, 93 ] to broken promises of timely logging [ 29, 37, 5, 91 ] and potential key compromise [ 84 ]." for links in my PhD thesis (2023). Another incident I like to remember: the San Bernardino case between Apple-FBI. Having a strong transparency log story for rolling out updates to this iPhone would have made it possible to monitor this case, and if anything similar happens behind the scenes it could similarly be detected with a transparency log. This is one of the earlier cases (from when I got involved in the space) that made be understand that binary transparency (and its long umbrella @ supply chain security) is pretty awesome. Also note the thread model here - gossip would not be good enough, because this iPhone is isolated. The witness cosigning stuff we're pushing for modern transparency logs defends against this. This threat modelling aspect is mainly why I'm including this example. https://en.wikipedia.org/wiki/Apple%E2%80%93FBI_encryption_dispute -Rasmus

2 1

Adding leaf context, and tooling version hooks
by Niels Möller 21 Nov '25

21 Nov '25

Hi, I have two issues, where in particular I would value Simon's feedback, but I think they could be of general interest. 1. We're considering adding an optional context hash to leaf signatures, outlined in https://git.glasklar.is/sigsum/project/documentation/-/merge_requests/125. This brings more flexibility, but also some new ways to misconfigure stuff. We'll discuss this again on Tuesday's Sigsum weekly. If you have feedback before then, that would be very nice. That's rather short notice, though, so if you want to read and think about it and provide feedback later, please say so now. It would be nice to wrap up discussion and come to a decision, but it's not urgent. 2. Elias noticed that the --version option doesn't work as expected for the sigsum-go tools in debian. See https://git.glasklar.is/sigsum/core/sigsum-go/-/issues/150 I think we need additional hooks to make this easy to set appropropriately in the packaging. Suggestions on how to do this in a good way is appreciated. It would be nice if we could get this improved for the next sigsum-go release, which will likely happen in a week or two. Regards, /Niels

2 1

Multi proofs for multi signing?
by Giulio 23 Oct '25

23 Oct '25

Hi all, In WEBCAT we're adding support for multiple signatures over the same artifact (a manifest). How we log that depends on the monitoring story. One (probably not great) option would be to sign the artifact once with a known key (which one, though?) and log that artifact that includes the N signatures once in Sigsum. The downside is that the Sigsum leaf would then be discoverable only via the submitting key, not by the individual signer keys. If we want per-key transparency, we should instead submit each signature over the artifact to Sigsum and get a proof for each. That seems best for monitoring and seems to be the least hacky design. Assuming all signatures (and proofs) need to adhere to the same trust policy, there's a lot of duplication when gathering individual proofs. My understanding is that we can wait until all leaves are included in the same tree, collect a single cosigned tree head (STH), and verify the log signature and cosignatures once. Each leaf will have its own inclusion path, but many hashes will overlap. This reduces verification work (one STH validation instead of N) and total size on the wire. Does this usage make sense? For a first step, I'd like to just fetch per-leaf proofs for the same tree size so I can reuse the same STH, without trying to merge paths yet. If that sounds reasonable, is this a mode of operation Sigsum would be interested in supporting in the client (i.e., worth a PR), or should I implement it on top using the log APIs directly? Thanks! Giulio

2 3

Temporal guarantees of Sigsum proofs
by Giulio 23 Oct '25

23 Oct '25

Hi all, After a conversation with rgdd, I was trying to understand what kind of temporal guarantees a Sigsum entry can provide. For instance, I need something akin (but slightly less strict) to a timestamping authority: something that can attest that a certain signature was included on a specific date, or at least definitely not afterwards. This would allow me to enforce expirations over signed artifacts: if an artifact was included after a certain threshold (e.g., 30 days after signing), I could consider it expired, knowing that the corresponding signature couldn’t have been forward-dated. A naive way to achieve this without Sigsum would be to submit the content to a timestamping authority (TSA), then include the TSA’s signed timestamp within the content to be signed. However, this approach introduces a single point of failure (a trusted third party) and adds unnecessary format complexity. Since inclusion proofs from a Sigsum server already include a cosigned checkpoint with a timestamp, I was wondering whether similar guarantees could be derived from these components. My concern is that if I simply trusted the timestamp in the checkpoint, the logic wouldn’t hold: anyone could request a new inclusion proof at a later time, which would include a newer checkpoint timestamp and an updated tree head. One immutable element between proofs is the leaf index, which correlates monotonically with inclusion order, though not directly with wall-clock time. A possible workaround would be to require proofs where the tree size in the checkpoint is at most N leaves ahead of the included leaf (say < 10), ensuring some temporal proximity between signing and inclusion. However, this approach would prevent me from obtaining new proofs for old signatures, for instance, after witness rotation, unless there was an archive of checkpoints (and the same for witnesses)? Summarizing: is there a way to use the Sigsum log server and the witnesses to attest that an inclusion happened at a specific timestamp? Thank you, Cheers, Giulio

2 3

Sigsum verifier in TypeScript
by Giulio 17 Jun '25

17 Jun '25

Hey there, as part of the work on WEBCAT I've rewritten a Sigsum verifier in browser-native TypeScript, this time that actually checks inclusion proofs ;) https://github.com/freedomofpress/sigsum-ts There's 100% coverage, and I've written many tests, though there likely still some niche case that I'm missing, but overall I'd plan to use it in a less experimental but still beta release in a few months. If no objections, will publish the package on npm in a few days! In many parts Ive just followed line by line the original Go code and translated in TS, in others I've taken a bit more liberty. I'll add support for JSON based formats for proofs and policies as anticipated in a previous thread. Cheers, Giulio

2 3

Policies and web-friendly format
by Giulio 19 May '25

19 May '25

Dear all, I've started looking into building a more complete and stable Sigsum verifier to run in the browser extension I'm prototyping. The model I sent previously changed a bit, we are removing Sigstore, to allow website administrators to specify their own ed25519 signing keys, and bring their own logs. The "bring your own log" model has been suggested in the WAICT proposal[1], and I think it improved decentralization for the better. I think the WAICT proposal refers to a type of log, or in general to log software that does not exists yet, and I think Sigsum fits the job well. I would like thus for website administrators to specify a Sigsum policy, but since that will be shipped in the HTTP headers, I'd need something more serialization friendly, such as JSON. While looking into the policy format, I was wondering why the quorum is global and not per log? In a JSON like format, I was imagining something like this, also to reduce to the minimum key/texts duplication: { "witnesses": { "X1": "base64-key-X1", "X2": "base64-key-X2", "X3": "base64-key-X3", "Y1": "base64-key-Y1", "Y2": "base64-key-Y2", "Y3": "base64-key-Y3", "Z1": "base64-key-Z1" }, "groups": { "X-witnesses": { "2": ["X1", "X2", "X3"] }, "Y-witnesses": { "any": ["Y1", "Y2", "Y3"] }, "Z-witnesses": { "all": ["Z1"] }, "XY-majority": { "all": ["X-witnesses", "Y-witnesses"] }, "Trusted-Bloc": { "any": ["XY-majority", "Z-witnesses"] } }, "logs": [ { "base_url": "https://log-a.example.org", "public_key": "base64-logkey-A", "quorum": "X-witnesses" }, { "base_url": "https://log-b.example.org", "public_key": "base64-logkey-B", "quorum": "Trusted-Bloc" } ] } It's just exploratory, but I'm a bit confused by the multi-log model. For instance, you'd expect the signers to send to two logs and then provide back two proofs bundles, or you'd expect a log with a policy with multiple logs, to propagate to the second log? In this format, I'd support per-log quorum, and probably thus expect multiple proofs. Cheers Giulio [1] https://github.com/rozbb/draft-waict-transparency/blob/main/draft-waict-tra…

2 3