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.)