Re: gpg-agent systemd user service [was: Re: GnuPG and SSH_AUTH_SOCK value]
El día martes, junio 25, 2019 a las 11:12:43a. m. -0400, Daniel Kahn Gillmor escribió: > On Tue 2019-06-25 13:07:03 +0200, Dirk Gottschalk via Gnupg-users wrote: > > This is my $HOME/.config/systemd/user/gpg-agent.service: > > If you're using gpg-agent as a systemd user service, please use the > systemd unit files (.service and .socket definitions) that ship with > GnuPG itself. > > ... Thanks for all the helping hands and hints about systemd(8), but FreeBSD normally does not run/use this. AFAIK, there is not even an official port of it in the FreeBSD's ports collection. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators! signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Infinite loop?
On Tue 2019-06-25 23:03:18 -0400, Phil Pennock wrote: > With GnuPG 2.2.16 : > > % ls -ldh ~/.gnupg/pubring.kbx > -rw-r--r-- 1 pdp pdp 241M Jun 22 22:16 /home/pdp/.gnupg/pubring.kbx > % time gpg --list-keys >/dev/null > [...] > gpg --list-keys > /dev/null 1473.99s user 1965.72s system 99% cpu 57:19.85 > total > % kbxutil --stats .gnupg/pubring.kbx > Total number of blobs: 5640 >header:1 > empty:0 > openpgp: 5638 > x509:1 > non flagged: 5638 >secret flagged:0 > ephemeral flagged:1 > > This is an "Intel(R) Atom(TM) CPU D2500 @ 1.86GHz" and is where I've > long had my high-security keys. One bright side to this box and its > speed: it's immune to speculative prediction attacks. None of that > newfangled nonsense. ;) i'm glad you have a sense of humor about it, but this sounds unacceptably slow to me. --list-keys isn't even doing any cryptographic processing, right? > I've long been resigned to this being normal. the timing you show above suggests that --list-keys operates at ~100 keys per minute, or not even 2 keys per second. And why on earth is so much time spent in the kernel? for my own run, the breakdown is: real0m17.555s user0m17.367s sys 0m0.184s But yours appears to have > 50% of its time spent in "sys". Can you use strace -T or some other profiler to see what system calls it's making that makes it spend so much time in the kernel? > In fact, I got so used to seahorse just dying that I adjusted my login > scripts to ignore it and fire up my own ssh-agent so that I wouldn't > lose the ability to log into other machines. I made that conditional > upon the socket being dead and grumpily chalked it up to Linux > flakiness, but I see now that this hasn't been getting triggered > recently. > > The X1 Carbon is 8 claimed cores of "Intel(R) Core(TM) i7-8650U CPU @ > 1.90GHz" and 16GiB RAM. It was definitely not happy at a keyring which > lets me comfortably verify software releases from signers in the strong > set. numbers like 5K keys and 241MiB are not large for a machine of this caliber. my own kbxutil --stats looks like: Total number of blobs: 4166 header:1 empty:0 openpgp: 3787 x509: 378 non flagged: 4165 secret flagged:0 ephemeral flagged:0 If you import your larger keyring on the X1 Carbon, what is the output of "time gpg --list-keys > /dev/null" there? > If you're interested, I can share mine; there are no "secret" keys in it > and I'll trust you not to leak the communications graph of which > software I care about verifying :) or the public signatures from the > strong set showing where I've been over the years or the local > signatures for "yeah, I grabbed these fingerprints from a web-page, I'll > trust them locally but won't attest to them publicly". If the issue is just a large keyring, i can generate that myself pretty easily, thanks. I was concerned by the OP that there was an acual infinite loop somewhere. But if the run is just taking a long time because of unoptimized code, we should try to address that as a separate issue. --dkg ps fwiw, i think even 17s is too long for my own 4K keys, esp. with a hot fileysystem cache. that's still only ~220 per second, but it's managable, and i've had enough other things i want to get fixed in GnuPG that i haven't dug in too deeply to see where the problem is or how it could be sped up. But it's nothing near the order of magnitude that you're describing. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Infinite loop?
On 2019-06-25 at 18:47 -0400, Daniel Kahn Gillmor via Gnupg-users wrote: > Interesting! my pubring.kbx is 147MiB, but GnuPG still should not run > forever when doing --list-keys. It takes 17s to complete the listing of > my pubring.kbx, as measured by "time gpg --list-keys > /dev/null" With GnuPG 2.2.16 : % ls -ldh ~/.gnupg/pubring.kbx -rw-r--r-- 1 pdp pdp 241M Jun 22 22:16 /home/pdp/.gnupg/pubring.kbx % time gpg --list-keys >/dev/null [...] gpg --list-keys > /dev/null 1473.99s user 1965.72s system 99% cpu 57:19.85 total % kbxutil --stats .gnupg/pubring.kbx Total number of blobs: 5640 header:1 empty:0 openpgp: 5638 x509:1 non flagged: 5638 secret flagged:0 ephemeral flagged:1 This is an "Intel(R) Atom(TM) CPU D2500 @ 1.86GHz" and is where I've long had my high-security keys. One bright side to this box and its speed: it's immune to speculative prediction attacks. None of that newfangled nonsense. ;) I've long been resigned to this being normal. An unthinking import of a fuller keyring (probably this one) to my recent new work laptop (Thinkpad X1 Carbon, running Ubuntu) led to confusion as I re-acclimated to a Linux desktop after years of macOS usage, because core parts of system preferences appeared to just hang and do nothing. Until I finally realized the problem and nuked the keyring down to a dozen keys which most mattered here. I hadn't realize that my GnuPG keyring was being exposed in my view of the preferences. In fact, I got so used to seahorse just dying that I adjusted my login scripts to ignore it and fire up my own ssh-agent so that I wouldn't lose the ability to log into other machines. I made that conditional upon the socket being dead and grumpily chalked it up to Linux flakiness, but I see now that this hasn't been getting triggered recently. The X1 Carbon is 8 claimed cores of "Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz" and 16GiB RAM. It was definitely not happy at a keyring which lets me comfortably verify software releases from signers in the strong set. > If you still have a copy of the corrupt 20M pubring.gpg, it might be > interesting to see it as an example, because it sounds like it's > tickling a bug. If you're interested, I can share mine; there are no "secret" keys in it and I'll trust you not to leak the communications graph of which software I care about verifying :) or the public signatures from the strong set showing where I've been over the years or the local signatures for "yeah, I grabbed these fingerprints from a web-page, I'll trust them locally but won't attest to them publicly". -Phil signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Infinite loop?
On Tue 2019-06-25 12:02:13 -0700, James Moe via Gnupg-users wrote: > On 25/06/2019 8.30 AM, Daniel Kahn Gillmor wrote: > >> Is it possible that your pubring.gpg is corrupt? > > As it happens, yes. > The size of pubring.gpg was 20MB; the backup copy was 1.3MB. After > restoring from backup, gpg2 performs normally. Interesting! my pubring.kbx is 147MiB, but GnuPG still should not run forever when doing --list-keys. It takes 17s to complete the listing of my pubring.kbx, as measured by "time gpg --list-keys > /dev/null" gpg should not take forever to list a 20MB keyring. If you still have a copy of the corrupt 20M pubring.gpg, it might be interesting to see it as an example, because it sounds like it's tickling a bug. however, sharing your keyring might be sensitive, and 20MB certainly won't fit in a message on this mailing list. If you are willing to share it privately so this can be tracked down, feel free to reply to me privately and we can figure out the details. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Infinite loop?
On 25/06/2019 8.30 AM, Daniel Kahn Gillmor wrote: > Is it possible that your pubring.gpg is corrupt? > As it happens, yes. The size of pubring.gpg was 20MB; the backup copy was 1.3MB. After restoring from backup, gpg2 performs normally. Thank you. -- James Moe moe dot james at sohnen-moe dot com 520.743.3936 Think. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
On Tue 2019-06-25 17:41:12 +0200, Dirk Gottschalk via Gnupg-users wrote: > Am Dienstag, den 25.06.2019, 16:30 +0200 schrieb Vincent Breitmoser: >> Have you considered the option to have keys cross-sign third party >> signatures for publication? It's a very slight switch in tooling if >> we assume a caff workflow, but that way each key remains in control >> of the public version of itself. > > I didn't consider it until you mentioned ist. A good idea, thanks. One concrete proposal for a mechanism for how to do this at the protocol level is "First-party-attested Third-party Certifications", documented here: https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-10 To make this feasible requires some work on the client side. The protocol implementation is likely to be the easy part. The hard part is the UI/UX work to make this something that a normal human can understand and do without too much pain. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent systemd user service [was: Re: GnuPG and SSH_AUTH_SOCK value]
Hello. Am Dienstag, den 25.06.2019, 11:12 -0400 schrieb Daniel Kahn Gillmor: > On Tue 2019-06-25 13:07:03 +0200, Dirk Gottschalk via Gnupg-users > wrote: > > This is my $HOME/.config/systemd/user/gpg-agent.service: > If you're using gpg-agent as a systemd user service, please use the > systemd unit files (.service and .socket definitions) that ship with > GnuPG itself. Sorry, I didn't even know there are such files. I just used the packages from Fedora and didn't look deeper into the packages. Thanks for your Comment. > If the standard upstream service doesn't work for you for some > reason, please explain why it doesn't work for you, and report it as > a bug so that we can fix it for everyone. I'll test them this evening, thanks againm. > While you're of course free to use custom variants like this for > yourself, please don't recommend that other people use them, because > it makes it much more difficult for the GnuPG project to support > other users. I didn't know about them and have not seen thgem in the source tree. Pure blindness I think. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
> The Upload should be restricted to the key owner in some way. We restrict upload of user ids to the owner of the user id, identified by email verification. Non-identity data (subkeys, revocations, ...) can be freely distributed, but only with a verified self-signature. Is there any other mechanism you can come up with to allow upload by the owner of some key data or email addresses, but not others? > I didn't consider it until you mentioned ist. A good idea, thanks. Great! I've been getting generally positive feedback about this idea, perhaps we should look into that more seriously. > Theres simply one point: "If you do not want your email to be public, don't > upload your key to a server." What if I upload your key to a server though? Keep in mind this is not just a "nice to have", it is a legal requirement. > In my opinion, the UID is essential for the Keys, except of M2M Usage. > (...) > No. But if I want to sent you an email and want to encrypt it on a > machine with an empty keystore, shouldn't I be able to fetch your key > by Address? Of course! And we do support that, given consent from the owner of an address. Without that, only non-identity data (still enough for M2M) is distributed. > It could be realized by exact match This is exactly what we do. :) - V ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
Hi. Am Dienstag, den 25.06.2019, 17:54 +0200 schrieb Vincent Breitmoser: > > The Upload should be restricted to the key owner in some way. > We restrict upload of user ids to the owner of the user id, > identified by email verification. Non-identity data (subkeys, > revocations, ...) can be freely distributed, but only with a verified > self-signature. That's what I had in mind. > Is there any other mechanism you can come up with to allow upload by > the owner of some key data or email addresses, but not others? Additionally some kind of authentication mechanism would be required to avoid fake uploads like just a faked sender address. I implicated this wordless. Other mechanisms could be possible but I don't have any special thoughts regarding this at the moment. > > I didn't consider it until you mentioned ist. A good idea, thanks. > Great! I've been getting generally positive feedback about this idea, > perhaps we should look into that more seriously. Yes, I agree. > > Theres simply one point: "If you do not want your email to be > > public, don't upload your key to a server." > What if I upload your key to a server though? Keep in mind this is > not just a "nice to have", it is a legal requirement. This would not be poissible with an authentication mechanism. See above. Only the owner should be able to modify his key or make ammendements. Probably except for revocations, in somne cases. > > In my opinion, the UID is essential for the Keys, except of M2M > > Usage. > > (...) > > No. But if I want to sent you an email and want to encrypt it on a > > machine with an empty keystore, shouldn't I be able to fetch your > > key > > by Address? > Of course! And we do support that, given consent from the owner of an > address. Without that, only non-identity data (still enough for M2M) > is distributed. M2M keys don't need a UID at all. I made such keys für my automatic backups and for some of the telematics solutions I work on. We use them only to encrypt, sign and send tachograph data files which are sent to our customers by email, for example. > > It could be realized by exact match > This is exactly what we do. :) So you support key search, this is a good point. And it ind of changes my opinion about the new servers. I didn't have the time to dig deeper into this new server and my opinion is based upon the things I read on the list. So this discussion is really helpful. Just the point of a centralized server is a thing that is not good in my opinion, but there should and will be a way to implement a distributed system into this project. A synchronizatio´n mechanism has to be well overthought, that's one point, but technically there are some ways to implement a secure and stable mechanism to achieve distribution. This is a point which should be considered. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Infinite loop?
On Sun 2019-06-23 15:00:40 -0700, James Moe via Gnupg-users wrote: > On 23/06/2019 11.53 AM, James Moe via Gnupg-users wrote: > >> gnupg does appear in the update log >> > Sigh. Typo. > gnupg does NOT appear in the update log. Nor does libscrypt. Without having access to your pubring.gpg, it's hard to say what is triggering this loop. I also note that gpg version 2.2.5 is fairly old -- is it possible to try to upgrade to a newer version? > The repetitive part of the log starts at line 475. The repetitions at 475 actually end at 8144, and different things appear to be happening in that debug log up until you sent it an interrupt to cancel. Is it possible that your pubring.gpg is corrupt? Can you replicate this with a minimal GNUPGHOME? Can you try migrating from pubring.gpg to pubring.kbx and see if you still have the same problem? A script for doing that migration is here if you want to try: https://salsa.debian.org/debian/gnupg2/blob/debian/master/debian/migrate-pubring-from-classic-gpg (you might want to back up your ~/.gnupg/ before trying) All the best, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Adding notations with quick commands
On Sun 2019-06-09 19:17:10 +0200, Wiktor Kwapisiewicz via Gnupg-users wrote: > Hi Markus, > > On 09.06.2019 14:16, Markus Reichelt wrote: >>> in a similar fashion to what --quick-* commands already do for other actions >>> (e.g. --quick-add-uid). >> >> --set-notation maybe? > > Yes, but as far as I understand --set-notation is only a modifier that > needs to be used with another command (e.g. --quick-sign-key). > > I tried using it with my own fingerprint twice but it didn't succeed: > > $ gpg -u F470E50DCB1AD5F1E64E08644A63613A4D6E4094 --set-notation > t...@example.com= --quick-sign-key > F470E50DCB1AD5F1E64E08644A63613A4D6E4094 > "Test McTestington " was already signed by key > 4A63613A4D6E4094 > Nothing to sign with key 4A63613A4D6E4094 > gpg: Key not changed so no update needed. I don't know of a way to do this automatically if there is already a certification from the current issuer over the OpenPGP User ID in question, unless the old certification is local (non-exportable), and the new one is not. in that special case, gpg seems fine with issuing the new certification (and will respect --cert-notation or --set-notation when doing so). I've opened https://dev.gnupg.org/T4584 to track this bug. Please follow up over there. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: missing root certificate, SMIME spanish government
On Sat 2019-06-01 12:14:00 +0200, Uwe Brauer wrote: > In any case I finally solveed the issue by just importing all available > cer into gpgsm and it worked, by mistake was to assume that gpgsm uses > the ones which are installed system wide. I agree that gpgsm integration with the system keyring is lacking. Please see https://bugs.debian.org/888025 for discussion on how that might be improved. I'd love to hear any feedback or thoughts there. (and would be even happier to receive patches i could review). --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Change socketdir from ~/.gnupg to /run/user/
On Tue 2019-06-18 04:03:45 -0400, vijai kumar via Gnupg-users wrote: > I am using gpg inside a docker container. By default, there is no > /run/user/ in the container so gpg defaults to ~/.gnupg as socket > directory. Is there a provision to change the socket directory later? > Now, I would like to create /run/user/$(id -u)/gnupg and use this as > the default socket directory. Is there a way to kill the existing agent > and relaunch it with the new socket directory? Ideally, you'd ensure that /run/user/$(id -u) is created during the session launch within the docker container, so that it's present from the beginning. If you already have an agent running from before /run/user/$(id -u) exists, you can kill it with a SIGTERM. A new agent will be launched appropriately using /run/user/$(id -u) automatically when it is needed. all the best, --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpg-agent systemd user service [was: Re: GnuPG and SSH_AUTH_SOCK value]
On Tue 2019-06-25 13:07:03 +0200, Dirk Gottschalk via Gnupg-users wrote: > This is my $HOME/.config/systemd/user/gpg-agent.service: If you're using gpg-agent as a systemd user service, please use the systemd unit files (.service and .socket definitions) that ship with GnuPG itself. There are a number of subtle (and not-so-subtle) problems with your proposed gpg-agent systemd user service definition. In contrast, the upstream one has been fairly widely tested. If the standard upstream service doesn't work for you for some reason, please explain why it doesn't work for you, and report it as a bug so that we can fix it for everyone. While you're of course free to use custom variants like this for yourself, please don't recommend that other people use them, because it makes it much more difficult for the GnuPG project to support other users. All the best, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG on debian [was: Re: GPG/YubiKey/CentOS7]
On Sat 2019-06-22 09:41:46 +0200, Wolfgang Traylor via Gnupg-users wrote: > On Debian: Prepare GnuPG > > > SSH support is not given by GnuPG 1. The `gpg` executable must be version 2.0 > or higher. > On Debian system, `gpg` is still the old version by default. We change that > globally. this is pretty out of date, debian has shipped modern GnuPG as "gpg" since the current stable release (about two years ago now). Please update your documentation :) all the best, --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
Am Dienstag, den 25.06.2019, 16:30 +0200 schrieb Vincent Breitmoser: > > Hi @ll. > Hi Dirk, > thanks for your thoughts! > > I don't think it's such a good idea to drop Signatures on keys. > As mentioned in our FAQ, the reason we don't support those is that > with the SKS model, anyone can attach arbitrary data to others' > keys. It's hard to overstate how problematic that is. I can just add > a megabyte or fifty of data to your key. The Upload should be restricted to the key owner in some way. That would mitigate this Problem and it should help against a key mess up I made a short while ago. > There are solutions that still allow for some of the TPS-based use > cases, but until there is at least some agreement on how to proceed, > we decided against supporting them. TPS? Okay, it's warm and I don't get this. But yes, a minimal agreement about the procedures would at least be neccessary. > Free distribution of arbitrary TPSes is quite simply not a viable > model for any keyserver. The discussion shouldn't be about liking or > disliking them, it should be about what alternatives could be. That's right. As told, SKS is far away from perfect and your solution goes the right way. Nothing prevents the implementation of, let's say key signatures in further versions or different versions to be used in environments on an in house server. > I see from your signing policy that you do a caff-style workflow. > Have you considered the option to have keys cross-sign third party > signatures for publication? It's a very slight switch in tooling if > we assume a caff workflow, but that way each key remains in control > of the public version of itself. I didn't consider it until you mentioned ist. A good idea, thanks. > > Also the centralized Approach is a no go in my opinion. > The open federation model of SKS means all email addresses are > enumeratable. That's a privacy no-go in my opinion, which people have > gotten surprisingly used to in this community. Isn't verifying the origination of an Email, including the address, one of the PGP approaches? Theres simply one point: "If you do not want your email to be public, don't upload your key to a server." If I didn't want my address to be known by others, I shouldn't post to an open ML. Same thing in my opinion. > I can imagine a closed federation model, where we have a handful of > operators but still don't need to have personal information of our > users in the open. In my opinion, the UID is essential for the Keys, except of M2M Usage. > Maybe we'll move in that direction once the dust has settled a bit. > The keyserver ecosystem has been stagnant in more than a decade, so.. > one step after another. Yes, the key servers (SKS) have come of age and some things weren't "on the radar screen" of it's developers for various reasons. > > Even removing the ability to search for keys by UID is a thing I > > don't like. > Why not? Do you think "find all Dirks on the keyserver" is a valid > use case that should be supported? No. But if I want to sent you an email and want to encrypt it on a machine with an empty keystore, shouldn't I be able to fetch your key by Address? It could be realized by exact match of the email address instead of spitting everything out that comes near to the requested string. Just my 2 cents and I am open to discuss benefits and downsides. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
> Hi @ll. Hi Dirk, thanks for your thoughts! > I don't think it's such a good idea to drop Signatures on keys. As mentioned in our FAQ, the reason we don't support those is that with the SKS model, anyone can attach arbitrary data to others' keys. It's hard to overstate how problematic that is. I can just add a megabyte or fifty of data to your key. There are solutions that still allow for some of the TPS-based use cases, but until there is at least some agreement on how to proceed, we decided against supporting them. Free distribution of arbitrary TPSes is quite simply not a viable model for any keyserver. The discussion shouldn't be about liking or disliking them, it should be about what alternatives could be. I see from your signing policy that you do a caff-style workflow. Have you considered the option to have keys cross-sign third party signatures for publication? It's a very slight switch in tooling if we assume a caff workflow, but that way each key remains in control of the public version of itself. > Also the centralized Approach is a no go in my opinion. The open federation model of SKS means all email addresses are enumeratable. That's a privacy no-go in my opinion, which people have gotten surprisingly used to in this community. I can imagine a closed federation model, where we have a handful of operators but still don't need to have personal information of our users in the open. Maybe we'll move in that direction once the dust has settled a bit. The keyserver ecosystem has been stagnant in more than a decade, so.. one step after another. > Even removing the ability to search for keys by UID is a thing I don't > like. Why not? Do you think "find all Dirks on the keyserver" is a valid use case that should be supported? Cheers - V ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
Hi @ll. Am Freitag, den 14.06.2019, 10:12 +0200 schrieb Oscar Carlsson via Gnupg-users: > Hi, > I'm generally curious on your opinions on the latest new keyserver, > this > time running a new software than the normal keyservers. > They seem to have a different model which minimize the amount of > information available, to be compliant with GDPR and friends. Do you > think there are any downsides to this? Unfortunately I promised to Werner to not get political anymore about the EU and GDPR thingies. To the Server you're Mentioning: I don't think it's such a good idea to drop Signatures on keys. Validating the KEys and it's packet would mitigate many of the SKS issues. But some people and solutions rely on the signatures. Okay, running an in house keyserver might be an option for this situations. Also the centralized Approach is a no go in my opinion. Reading this thread, I feel like I've done a time travel, back to the times where people distributed their keys over the usenet due to the lack of keyserver dunctionality. Keyservers like the desribed one is less than useless in my opinion. Even removing the ability to search for keys by UID is a thing I don't like. But that's the GDPR panic. Yes, I know, no politics from the angry guy. ^^ So, it's pretty hot here. Werner must have turned on the Heater. I'll be quite now. :D Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG and SSH_AUTH_SOCK value
Hi. Am Sonntag, den 23.06.2019, 10:21 + schrieb Matthias Apitz: > El día sábado, junio 22, 2019 a las 09:47:12a. m. +0200, Werner Koch > via Gnupg-users escribió: > > > That seems to be deep in the innards of KDE's X startup or Wayland > > or > > Systemd configuration. I try to avoid all this and use the old > > fashioned but easy to debug ~/.xsession > > I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: > > $ cat ~/.xinitrc > > # set SSH_AUTH_SOCK > # > unset SSH_AGENT_PID > unset SSH_AUTH_SOCK > SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"; > export SSH_AUTH_SOCK > echo SSH_AUTH_SOCK: $SSH_AUTH_SOCK >> /tmp/xinit > # > setxkbmap de,us -option terminate:ctrl_alt_bksp > xrandr --output default --mode 1366x768 > /usr/local/bin/xbindkeys > exec ck-launch-session startkde > > The idea is to set env var SSH_AUTH_SOCK correctly for all the > xterm/urxvt > processes "below" KDE. But, before the start of KDE (last line) the > SSH_AUTH_SOCK is still > /home/guru/.gnupg-ccid/S.gpg-agent.ssh > and later when KDE is up the 'gpgconf --list-dirs agent-ssh-socket' > returns /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg- > agent.ssh > i.e. the env var SSH_AUTH_SOCK is set wrong and I have to reset it > in any terminal. I am not running KDE, but Gnome. For my case I have a SystemD user service which starts a gpg-agent instance in background and sets the environment variables for the user on login. Originally I found this solution on the internet and I adapted it for my usecase with a few modifications. GPG doesn't start the agent becuse there is already a running instance and the authentication socket is available. SSH authentication, gpg and all other things work just fine. If this is what you want to achieve and if you want to have a look at this, tell me and I'll send you the needed Files. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG and SSH_AUTH_SOCK value
Hi.
Additionally to my previous reply:
This is my $HOME/.config/systemd/user/gpg-agent.service:
---
[Unit]
Description=GnuPG Agent
IgnoreOnIsolate=true
[Service]
Type=forking
Environment=SSH_AUTH_SOCK=%t/gnupg/S.gpg-agent.ssh
ExecStart=/usr/bin/gpg-agent --homedir %h/.gnupg --enable-ssh-support
--daemon
ExecStartPost=/usr/bin/systemctl --user set-environment
SSH_AUTH_SOCK=${SSH_AUTH_SOCK}
[Install]
WantedBy=default.target
---
There one could add the home directory for GnuPG, if needed.
Regards,
Dirk
--
Dirk Gottschalk
GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac
signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
