Hi Björn,
Thanks for your comments.
On Mon, 12 Jan 2026 18:39:55 +0100,
Björn Persson wrote:
> Neal H. Walfield via devel wrote:
> > The fundamental issue is the following. Fedora's verification recipe
> > instructs the user to use the signature to verify the checksum file,
> > and then to use sha256sum with the original checksum file to verify
> > the iso:
> >
> > gpgv --keyring ./fedora.gpg Fedora-Workstation-43-1.6-x86_64-CHECKSUM
> > sha256sum --ignore-missing -c Fedora-Workstation-43-1.6-x86_64-CHECKSUM
> >
> > This is wrong. sha256sum must use the verified data to verify the
> > iso.
>
> You're right so far. The instructions are dangerously wrong.
>
> > the above command does not work for me:
> >
> > $ gpgv --keyring ./fedora.gpg Fedora-Workstation-43-1.6-x86_64-CHECKSUM
> > --output -
> > gpgv: Packet type 63 not allowed in detached signature
> > gpgv: no valid OpenPGP data found.
> > gpgv: verify signatures failed: Unexpected error
>
> The error message I get is "not a detached signature". This is because
> gpgv thinks you want to verify a file named "--output". You must put
> all options before the input filename:
>
> gpgv --keyring ./fedora.gpg --output -
> Fedora-Workstation-43-1.6-x86_64-CHECKSUM
Thanks for correcting me. I know about gpg's ordering requirements
for parameters, but I assumed that what I had entered was acceptable
given the error message I saw. It didn't occur to me that
non-existant files would not trigger an error along the lines of
"--output: file not found" but a parse error.
Given that the following works:
gpgv --keyring ./fedora.gpg --output -
Fedora-Workstation-43-1.6-x86_64-CHECKSUM
We should at least change the verification instructions to:
gpgv --keyring ./fedora.gpg --output -
Fedora-Workstation-43-1.6-x86_64-CHECKSUM \
| sha256sum -c --ignore-missing
Ideally, the link to the checksum file should be to Fedora's
infrastructure and not the same mirror as the iso.
> > Another approach would be to directly sign the iso instead of the
> > checksum file.
>
> Absolutely. The sha256sum detour adds only complexity and pitfalls. A
> detached signature of the ISO file would be much easier and safer for
> the user.
Do you know who would be the right person to approach about this
change?
> > As far as I can tell, gpgv cannot be convinced to do the right thing.
>
> Thank you for illustrating how confusing an idiosyncratic command line
> syntax can be. Allowing parameters in any order would be more user-
> friendly.
>
> There are lots of other programs that also require parameters in a
> particular order, and expect the user to know the correct syntax.
> Sequoia is one of them. This does not work:
>
> $ sq --signer-file ./fedora.gpg verify --cleartext
> Fedora-Workstation-43-1.6-x86_64-CHECKSUM
> error: unexpected argument '--signer-file' found
>
> tip: a similar argument exists: '--password-file'
>
> Usage: sq <COMMAND>
>
> For more information, try '--help'.
Thanks for raising this issue. I'd like to dig a bit deeper here so
that we can improve Sequoia. I'm not convinced that allowing
parameters in any order would be more user friendly. Some ordering is
required for an argument that takes a value. Consider:
command --output file
command file --output
In the second invocation of command, I would find it surprising to
learn that file is --output's value.
Also, I think subcommands should be ordered. Consider:
sq key generate ...
sq generate key ...
sq considers the first variant to be valid and the second to not be.
I'd personally be quite surprised if a tool allowed an arbitrary
ordering here.
In your example you seem to suggest that subcommand-specific
parameters should be allowed before the subcommand. I could imagine
doing that, but that seems idiosyncratic. It's not the default in
clap, which is what Sequoia uses to parse arguments and which is a
widely used command line argument parser in the Rust ecosystem. Also,
Sequoia acts similarly to other tools in this regard, like git:
$ git --pretty=oneline log
unknown option: --pretty=oneline
usage: git ... <command> [<args>]
And cvs:
$ cvs -h log
cvs: invalid option -- 'h'
Usage: cvs [cvs-options] command [command-options-and-arguments]
So it seems surprising to me to say that Sequoia is idiosyncratic.
Perhaps the output would be less confusing if sq identified that the
argument is out of order and displayed a message suggesting that the
user reorder the option.
What do you think? How could we make sq less confusing?
:) Neal
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
