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
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
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
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,
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
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
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
> 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
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
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,
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
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
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
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
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
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
> 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
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
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
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
20 matches
Mail list logo
