Sorry, I don't understand your request. I might missing some context related to the neomutt bug, though. What I can see tehre is that gpg options are used after the option/command to arg delimtyer "--" . That is of course wrong. It might be that mutt uses a special syntax here but I can't remeber that because it is 15 years since I implemented the new crypto layer in mutt. And you should really prefer to use the use_gpgme than the >20 year direct call of gpg.

There is no real difference between options and commands. The only difference is that gpg does not allow to give more than one command. ARGS are the ARGS for the respective command. For example a file name or a list of arguments for --quick-gen-key.

Can you please briefly explain and show what the assumed bug is; the command line interface to gpg has not changed over the last 20 years.

First, there is a documentation bug: args is undefined. It appears at the top of the man page, but nothing in the man page says what an argument is. The man page says --recipient is an "option" (but it's not, it's an argument, and the distinction is important). I broke neomutt recently because I read the GPG man page, which stipulates a particular sequence of tokens and implied that the old commandline was out of order. That is why it's suddenly a problem after 20 yrs.

FYI, the -- is a neomutt hack, because the --recipient token does not accept a list, and must be repeated before every recipient. The pgpwrap tool does that. So --recipient %r expands to --recipient alice --recipient bob --recipient leroy, and -- is a delimiter.

Second, there is a code bug: --encrypt-to <key id> --encrypt-to-self should not replace --recipient (and according to the man page, --recipient is required). But gpg will execute and encrypt a msg without --recipient when --encrypt-to <key id> --encrypt-to-self is supplied. GPG should be made to fail if the --encrypt command is missing the --recipient argument.

Regarding GPGME, it's not ready for prime-time: https://github.com/neomutt/neomutt/issues/1014#issuecomment-359016857

What's in daily use for 15 yrs? GPGME? I thought GPGME was new, but in any case it's broken in the cases mentioned in that thread.

MUA which can't handle MIME at all but PGP are still able to decrypt PGP/MIME.

I don't know of any such cases, but certainly that's not always the case. I've sent PGP/MIME to a traditional mode client and the user could not handle it. That MUA may no longer be in play (was 10+ yrs ago), but protonmail and hushmail are still quite common today. A protonmail user receiving PGP/MIME w/file attachment is totally helpless -- it's technically infeasible to remedy when the server just shows them an error banner, and they don't even have a means to obtain their private key.

Hushmail users are most likely helpless regardless of whether there's a file attachment. There's a remote chance they can download the blob and their private key and do surgery on the payload. I've not tested that, but even if that's in the realm of feasibility those users are helpless in terms of competence anyway. If a PGP/MIME msg arrives on a hushmail acct, it's game over for the typical user, if not all users of that system.

What about webmail users w/a browser plugin? I don't think the browser plugin can access the headers in a composition window. Aren't they all limited to the inline format?

Regarding IDEA, I have no attachment to it, but I find it unfortunate when a tool maker makes security decisions on behalf of users and admins. Responsibility and accountability should be attached to the same person. The Debian apt team takes the liberty of imposing security decisions on admins, denying them choice. It's the admin of a system who knows their threat model, who is better informed on the deployment to balance availability with confidentiality and integrity. I don't know the story w/dropping IDEA.. if it was creating a maintenance burden on the project while also being relatively useless, that's fair enough. Otherwise, defaults should be sensible but the user or admin should have ultimate control IMO.

In T3751#110422, @cipherpunks wrote:

What's in daily use for 15 yrs? GPGME? I thought GPGME was new,

Actually it's older than that, version 0.2.0 was released in February, 2001. The first release of PyME was the following year.

but in any case it's broken in the cases mentioned in that thread.

As one of the participants in that thread as well as here, I disagree. Since I use Neomutt with GPGME compiled in as well, I believe I can address all of the points you raised in that thread:

sending a file attachment to a protonmail user (protonmail has widespread popularity ATM)

Protonmail's implementation of OpenPGP is not quite as good as they claim. It is not currently possible for external hosts to send OpenPGP encrypted messages to Protonmail userds and vice-versa. Unlike with Hushmail where all that was required was uploading a public key to the Hushmail keyserver.

The OpenPGP key file available for contacting the Proton Security team on the ProtonVPN site may provide some hints as to why theyt have been unable to work with external parties. That key was generated and exported using OpenPGP.js and that JavaScript project does not implement the full set of cipher and digest algorithms. Indeed it will frequently fail hard when encountering any key with features it doesn't support or when encountering messages encrypted that way. Even as an attachment, it's likely the system tried to decrypt what had been sent and that was what induced the error.

The solution is for ProtonMail to upgrade their systems to support the entire OpenPGP standard.

sending any secure message to a user of any webmail service running the hushmail backend (file attachment or not)

It's been a long time since I've had to do so, but as long as you've uploaded your public key to the Hushmail keyserver you should be able to encrypt to those recipients. Mind you, most people have been wary of Hush ever since they compromised their own system to to capture passphrase data at the behest of the FBI and DEA.

sending any secure message to anyone using a classic non-PGP/MIME MUA

As Werner said, any MUA unable to handle MIME at this point is living in the past and pandering to such clients via extra effort is also a waste of time.

receiving a msg from any of the above users probably requires extra manual work to open

Nope, decrypting PGP/in-line with Neomutt and GPGME works just fine, it's only the sending of PGP/in-line which doesn't work. Those few occasions where I find in-line of any use it's simply a matter of handling the process from within my text editor (Emacs) and remebering to clear out the Neomutt PGP settings before sending.

ability to verify S/MIME sigs, strangely enough (#940)

Not that strange since GPGME supports gpgsm as well as gpg. Sometimes it appears to hang or there are long delays if the message with the S/MIME signature originates from a network that prevents access to the public key data for reasons which are ... passing understanding.

MUA which can't handle MIME at all but PGP are still able to decrypt PGP/MIME.

I don't know of any such cases, but certainly that's not always the case. I've sent PGP/MIME to a traditional mode client and the user could not handle it. That MUA may no longer be in play (was 10+ yrs ago),

Which MUA was that?

but protonmail and hushmail are still quite common today.

Protonmail is, but Hushmail has been a joke ever since the Farmers Market incident.

A protonmail user receiving PGP/MIME w/file attachment is totally helpless -- it's technically infeasible to remedy when the server just shows them an error banner, and they don't even have a means to obtain their private key.

That is a bug in the Protonmail system.

Hushmail users are most likely helpless regardless of whether there's a file attachment. There's a remote chance they can download the blob and their private key and do surgery on the payload. I've not tested that,

I have. It is possible for a Hush user to download their private key to manipulate or modify it. That's how my old Hush account I played around with just after they launched ultimately led to the key being revoked and pushed out to the entire SKS pool as well as just the rest of Hush.

Likewise I've had little trouble with providing the public keys for my real usage to Hush through their tools site. That's how my current and previous keys were signed by the Hushmail Demo CA key.

but even if that's in the realm of feasibility those users are helpless in terms of competence anyway. If a PGP/MIME msg arrives on a hushmail acct, it's game over for the typical user, if not all users of that system.

Arguably it was game over when Hush exploited the JavaScript on their own login page to capture passphrases.

What about webmail users w/a browser plugin? I don't think the browser plugin can access the headers in a composition window.

The PGP/MIME components don't use the headers, though there is a hint for the format near the end of the headers. All the real MIME data is encrypted inside the ciphertext.

Aren't they all limited to the inline format?

It depends on the systems involved, both server and client.

Regarding IDEA, I have no attachment to it, but I find it unfortunate when a tool maker makes security decisions on behalf of users and admins.

The GnuPG Project makes no decisions for anyone. Some sensible defaults are set for ease of use and documentation or public statements may include recommendations, but ultimately it is end users who decide how they use the software.

IDEA was included with Pretty Good Privacy fairly early on, as was RSA following the disaster that was Bass-O-Matic in PGP version 1. Both of those, however, were patented, so when Phil Zimmermann founded the PGP Corporation with Jon Callas to make a commercial version they used CAST5 instead of IDEA and DSA1/El-Gamal in place of RSA.

The GnuPG project began two or three years later and adopted the same algorithms which were in use at that time. Since the project is also part of the GNU Project in general, patent restricted algorithms could not be used. As with other common programs in this sort of position (e.g. FFMPEG), end users have the option to incorporate those algorithms manually if they needed to or had the right to do so.

When the RSA patent expired in 2000, that was reincorporated into both PGP and GPG. When the patent for IDEA expired in 2011, support for it was added to GPG in both the 1.4 and 2.0 branches

Responsibility and accountability should be attached to the same person. The Debian apt team takes the liberty of imposing security decisions on admins, denying them choice.

Then perhaps Debian is not the ideal system for you, but whether it is or isn't that matter is out of scope here.

It's the admin of a system who knows their threat model, who is better informed on the deployment to balance availability with confidentiality and integrity.

Indeed, but it seems to me that you might not be fully aware of the scope of the threat model of that era. We're basically talking about the time which these days is called the Crypto Wars or the First Crypto War.

I don't know the story w/dropping IDEA.. if it was creating a maintenance burden on the project while also being relatively useless, that's fair enough. Otherwise, defaults should be sensible but the user or admin should have ultimate control IMO.

They do have ultimate control, but both the free (GnuPG) and commercial (PGP Corp.) projects of the time needed to adhere very closely to the law regarding these things. Remember, this was during a period when cryptographic software was considered a munition and the USA was looking at any possible way it could shut the entire thing down and stuff the genie back into the bottle.

As for tracking the defaults or when some things may be deprecated or included, that's handled via the IETF with the OpenPGP RFCs. The main one, albeit not the only one, is RFC 4880.