For the record in my original message I asked about adding self-signatures.

It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?

A possible exception here is that .onion TLDs should stick with HKP by default

I note that "the best" seems like it might be a pretty subjective thing. The standard GnuPG framing asks about the validity of keys for the User ID in question. Perhaps the caller could indicate whether they want to require full validity for each key to make this key selection more strict.

The function would do something like:

• from msg, extract all e-mail addresses from to, cc, bcc fields
• find "the best" keys that match these addresses, storing them in keylist
• copy msg to tmp, remove bcc header from tmp
• wrap armored output of gpg.Context.encrypt(bytes(tmp), recipients=keylist) in the necessary RFC 3156 cladding, copying most headers from msg (maybe stubbing out the subject), producing an email.message.EmailMessage object.

we now have a DCO from @Valodim

@werner, My usual approach for private branches is to prefix with dkg/, but (a) playfair rejects branch names with a /, and (b) i'm not the author of these patches, and i didn't want to claim credit that doesn't belong to me.

Please use a private branch as usual. There has been no agreement or a discussion over this change nor do we have a DCO from him.

I've pushed @Valodim's proposed patches to the fix-4393 branch in our git repo. they look good to me, and i think they should be merged to master.

Nope

Here are the patches without any new commands:

@werner Only patches 2 and 3 introduce new commands. What do you think about the other changes?

In case I not already mentioned it: There won't be any new commands to delete a key. Of course you are free to change GnuPG as you like but I won't apply them here.

The change in message class did not help.

While it's not recommended, current master has a support of sharing same raw key materials. I think that it now works (I don't try, though).
Closing.

gniibe wrote:

RFC 5280 only addresses about BCP78 and not about TLP, while RFC 5652, RFC 5755, RFC 5911 and RFC 5912 address explicitly about TLP. In this situation, I wonder if it's better to take the definitions of Extensions, UniqueIdentifier, and GeneralNames from RFC 5280. To be conservative, I don't include them now.

I pushed more changes to include modules in RFC 5911 and RFC 5912.

Comparing old cms.asn and new cms.asn, now I understand how RFC 3370 matters. I added those things back from RFC 5911 (which cites RFC 3370) which comes with BSD license for code.

@gniibe thank you!

I did some work (since Debian is important for us).
Please have a look at my topic branch: gniibe/fix-4487
or:
https://dev.gnupg.org/source/libksba/history/gniibe%252Ffix-4487/
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libksba.git;a=shortlog;h=refs/heads/gniibe/fix-4487

Perhaps i wasn't clear enough in the earlier messages on this thread. The inclusion of restrictively-licensed code in a file that also claims LGPL/GPL appears to be an unredistributable license. Could you please clarify why the GPL or LGPL applies to libksba while it contains src/cms.asn in its current form?

Fix pushed.

I think that detecting strerror_s by configure is better, because it's a new feature on Windows.

I doubt that we are going to implement this.

I guess we can do that. Thanks for the hint.

The behaviour related to ssh key access is due to the way ssh works: After a connection has been established to a server ssh presents to to the server all identities (public keys) it has access to (meaning it has a corresponding private key). Thus we can't tell ssh all the keys we have because that would be an information leak and may also take too long. Because the user may in some cases not want to use the ssh-agent but resort to ssh command line input of the passphrase, we do not insist on using a key known by gpg-agent.

Perl would be okay for maintainer mode but not for regular builds. The reason is that perl is already used by autotools but a build shall still be possible w/o perl.

I'm looking into doing a pretty epic hack of using the switch_endian syscall to speed this up.

I don't know. That would make it a relatively easy transplant. We've also used the Cryptogams code as a reference for Golang enhancements, if that helps. I'd welcome guidance on the matter from a maintainer.

Would the maintainers accept having perl in the repository? Linux does it.[1]

FWIW, I disabled @aa7356 because he again started to troll.

Snap question regards to the clock;

Sorry, I can't parse that. For development question please use gnupg-devel at gnupg.org.

Feature supported in master.

Or a better tl;dr; When you send mails without "inline" option everything is fine and standardized. The problem is that the old version of GpgOL that your college uses is too stupid to handle this ;-)

Yes your colleague should or basically needs to upgrade. 2.2.3 is very outdated. There are security issues that were fixed by then etc.

In T4515#125651, @aheinecke wrote:

Hi,

What client does your colleague use so that you have to use PGP/Inline?

That format where the attachment is it's own PGP Encrypted file is very problematic. You basically have mutliple signature and encryption states. An attacker can easily remove or add attachments to the message. The attachment name is leaked. etc. Also see: https://wiki.gnupg.org/PgpPartitioned

Our opinion is that if you really _have_ to use PGP/Inline that you must do so manually using Kleopatra's notepad and Encrypted files.

I am a bit unsure if I just close this as "Wontfix" or move it to Wishlist. I think for now I go with Wishlist but do not expect that feature soon. At least until maybe some really important use case comes up.

Anyway, thanks for your feedback. It is always valuable to know what users would like to have.

Best Regards,
Andre

What client does your colleague use so that you have to use PGP/Inline?

Thanks for the hint on the existing OID I already looked into that and planned to use one from the GnuPG arc, But an existing OID is better. I still need to figure useful workflows but something like this will be useful for smartcards..

I anyway plan to extend the --quick-gen-key parameters to allow the specification of several subkeys on the command line.

I think you'll be better off doing this with the simpler --quick-generate-key and --quick-add-key interfaces, rather than hacking on the domain-specific language used by --batch --generate-key.

@werner, why is it the case that if i'm willing to look up a key via WKD on Monday, i should by definition also be willing to send a followup request to that WKD server on Thursday just because the certificate is marked with an expiration?

see also T4467

WK you command me to put the file scd.log somewhere.
I am trying to do it on the wires set "F103RB" from ARM (GeeNuke)

i'm thinking that if the algo parameter to --quick-add-key is a keygrip, then it would find the key directly in the existing keyring(s) and attach it as a new subkey.

Thanks for the explanation.

If the ASN.1 is not from an RFC, then the AUTHORS file should not claim that it is from an RFC.

As I want to keep this tracker clean I would say this is a Wontfix at least until someone (DKG?) provides an argument what would be gained and why we should do this.