py -m sigstore ... failure is a mess when run in non-elevated terminal

[djhenderson]

When sigstore is executed from a non-elevated terminal, it fails without a useful error message or with multiple exceptions, non of which provide a clue to the reason for failure.

Version

Edition	Windows 11 Pro
Version	25H2
Installed on	‎2025-‎01-‎17
OS build	26200.8875
Experience	Windows Feature Experience Pack 1000.26100.334.0

> py -3.14 -m venv venv314
> venv314\Scripts\activate.bat

> py -V
Python 3.14.6

> pip list
...
sigstore             4.4.0
sigstore-models      0.0.6
sigstore-rekor-types 0.0.18
...

No directly useful error message is issued. Adding the --verbose option to the sigstore command does not provide a particularly useful result.

The significant exception is OSError: [WinError 1314] A required privilege is not held by the client: ... which is buried in between two exception trace backs.

This exception should be detected, and a useful message generated without the unuseful trace backs, or the requirement to add the verbose option.

Thanks,
Doug

[woodruffw]

Thanks for the report. Nobody else has reported behavior similar to this and our CI (which runs on Windows) hasn't exhibited similar errors, so it's hard to rule out system- or configuration-specific behavior here.

Are there more error messages you can share? WinError 1314 is indeed unfortunately opaque. Adding -vv or -vvv may help by increasing the log verbosity.

(One possibility: if we use symlinks anywhere - including indirectly via TUF - I guess they could cause that kind of non-privileged error. I can't think of anywhere within sigstore-python itself that uses symlinks, but it's not impossible that python-tuf does.)

[woodruffw]

One potential source:

https://github.com/theupdateframework/python-tuf/blob/6889cfbffbb90a17930fbdedf12ae050be775fe3/tuf/ngclient/updater.py#L365-L372

(If that's the root cause, this is arguably either a bug in python-tuf, or an intentional limitation that they should document/use a dedicated exception for so we can handle it here. If they consider it a bug, I think the "right" fix is to use an NTFS junction instead of a symlink.)

[intltechventures]

I am also seeing the same error:

Edition Windows 11 Pro
Version 25H2
Installed on ‎2025-‎03-‎18
OS build 26200.8875
Experience Windows Feature Experience Pack 1000.26100.334.0

Python 3.14.4

(normal terminal window opened, not opened with "Run as administrator")

python -m sigstore verify identity --bundle python-3.14.7-amd64.exe.sigstore --cert-identity hugo@python.org --cert-oidc-issuer https://github.com/login/oauth python-3.14.7-amd64.exe

[20:03:16] ERROR Failed to refresh TUF metadata.

With verbose turned on:

OSError: [WinError 1314] A required privilege is not held by the client:

Note:
This is the command (per the documentation) that I used to install sigstore
Re: https://www.python.org/downloads/metadata/sigstore/

$ python -m pip install -r https://raw.githubusercontent.com/sigstore/sigstore-python/main/install/requirements.txt

I will test sigstore-go and report back by end of day 2026-08-07 Friday (CDT)
A client library for Sigstore, written in Go.
https://pkg.go.dev/github.com/sigstore/sigstore-go

[woodruffw]

I'm pretty sure this is a bug in python-tuf, per the previous comment. There isn't much that sigstore-python itself can do here.

[jku]

One potential source:

https://github.com/theupdateframework/python-tuf/blob/6889cfbffbb90a17930fbdedf12ae050be775fe3/tuf/ngclient/updater.py#L365-L372

agreed. I'll add a fallback in python-tuf

theupdateframework/python-tuf#2980

[overgoy]

The upstream half has landed, in case it is useful for tracking this: theupdateframework/python-tuf#2980 was closed on 10 August by python-tuf#2981, "ngclient: Fix symlink usage on Windows".

It is not in a release yet, though. The newest python-tuf release is v7.0.0 from May, so with tuf >= 6, < 8 an install today still resolves to a version that symlinks root.json, and the WinError 1314 above still reproduces. When python-tuf cuts a release with that fix, raising the floor here is what turns it into a guarantee rather than a coincidence of resolution.

Nothing to change in this repository until then, as far as I can see.

Disclosure: prepared with an AI coding assistant.