Could we make a detached signature in this cases, too, like for the single files?

No. The detached signature would sign an ephemeral archive. The signature could never be verified because the data that was signed doesn't exist as a file.

Combined sign & encrypt is not implemented for S/MIME:

• For single files the files are encrypted as *.p7m files and detached signatures for the unencrypted files are created as *.p7s files.
• For folders or multiple files an archive is created and this archive is encrypted as *.p7m file and and this archive is signed opaquely as *.p7s file.

I agree that the only sensible course of action is to disallow sign & encrypt for S/MIME because currently it doesn't do want one sensibly expects it to do.

Alternatively, we could make it more obvious that for S/MIME two (!) separate results are created.

Instead of disabling something (which gets complicated --see the notepad-- and the users will not understand why the button is disabled) I suggest to show a confirmation dialog that explains what is going to happen.

Nevertheless we should think about disallowing it eventually then. I can't see a usecase right now, where this combination would make enough sense for a general mode (as this still can be done with two operations). What would be the issue with first encrypting the tarball and then sign that resulting tar.gz.p7m to create a tar.gz.p7m.p7s?

In T8324#220048, @timegrid wrote:

What would be the issue with first encrypting the tarball and then sign that resulting tar.gz.p7m to create a tar.gz.p7m.p7s?

The main reason speaking against this is that this would be the opposite of what is done for OpenPGP where the data is first signed and then encrypted. And the reason for this is that you don't want to leak any information by adding a not encrypted signature.

The easiest fix is to enable the "exclusive" mode that we use for the notepad (and the clipboard) also for the Sign/Encrypt Files/Folder dialog. This will disable mixing of OpenPGP and S/MIME recipients (which is anyway misleading because in case of encryption the result is two separate encrypted files with mutually exclusive recipients). Moreover, for S/MIME, it will disable "combined" sign and encrypt.

The only downside is that some people might be confused that they don't find some certificates in the list of recipients because they are looking for an S/MIME certificate (without knowing that they are looking for S/MIME) while the dialog is in OpenPGP mode (and vice-versa).

Moreover, for S/MIME, it will disable "combined" sign and encrypt.

But also for single files, not only for archives?
I'd like to keep the capability for single files, which does work, if possible.

I don't know what you understand as "does work". For single files two completely separate things are done:

1. A detached S/MIME signature for the unencrypted file is created.
2. The unencrypted file is S/MIME encrypted.

There's nothing "combined" here. You get exactly the same result if you first S/MIME sign a file and then S/MIME encrypt a file (or vice versa).

This is radically different from how OpenPGP works where the file is first signed and then encrypted and the result is a single signed+encrypted file. In my opinion, it does not work at all for S/MIME (at least not how somebody knowing about OpenPGP sign+encrypt would expect it to work).

Well at least the reporter was of the opinion that it worked. Depends on what one expects.

We discussed it and decided that we want to keep the sign+encrypt option for S/MIME and single files. But for folders (and multiple files) we want to disable S/MIME signing. If people need to sign an archive, they have to create it before signing (or signing+encrypting).

Reason for the decision: gpgsm does - in contrast to gpg - not allow combined sign+encrypt, which makes the process to complex when adding archiving on top.