It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?
Fri, Jun 21
A possible exception here is that .onion TLDs should stick with HKP by default
Wed, Jun 19
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.
Tue, Jun 18
Sun, Jun 16
@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.
Fri, Jun 14
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.
Thu, Jun 6
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?
Wed, Jun 5
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.
Tue, Jun 4
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).
Mon, Jun 3
Sat, Jun 1
Fri, May 31
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.
Thu, May 30
@gniibe thank you!
I did some work (since Debian is important for us).
Please have a look at my topic branch: gniibe/fix-4487
Wed, May 29
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?
I think that detecting strerror_s by configure is better, because it's a new feature on Windows.
Tue, May 28
Mon, May 27
I doubt that we are going to implement this.
May 24 2019
I guess we can do that. Thanks for the hint.
May 23 2019
May 21 2019
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.
May 20 2019
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.
May 18 2019
FWIW, I disabled @aa7356 because he again started to troll.
Snap question regards to the clock;
May 17 2019
Sorry, I can't parse that. For development question please use gnupg-devel at gnupg.org.
May 16 2019
Feature supported in master.
May 15 2019
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.
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.
What client does your colleague use so that you have to use PGP/Inline?
May 14 2019
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?
May 13 2019
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)
May 12 2019
May 10 2019
May 9 2019
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.
May 8 2019
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.
May 7 2019
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.