On Tue, Jun 20, 2017 at 03:34:44PM +0200, martin f krafft wrote:
> 2. I've also tried running --update-trustdb, but it seems that this
>process is *endless*. I have no idea how many keys remain, and
>I also got the impression that I keep seeing keys I already
>processed. How do you appr
At Tue, 27 Jun 2017 09:27:57 +0100,
MFPA wrote:
> On Monday 26 June 2017 at 10:31:04 AM, in
> ,
> Goddess: Primal Chaos wrote:-
>
>
> > Dear player, Thank you very much for contacting us
> > by mail.
>
>
> I've seen several of these messages on this list lately. It looks like
> somebody has su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Monday 26 June 2017 at 10:31:04 AM, in
,
Goddess: Primal Chaos wrote:-
> Dear player, Thank you very much for contacting us
> by mail.
I've seen several of these messages on this list lately. It looks like
somebody has subscribed a customer
### Do not reply below this line ###
-
Goddess: Primal Chaos | June 26, 2017 | 11:55 +0200
-
Dear player,
Thank you very much for contac
At Mon, 26 Jun 2017 11:27:30 +0200,
martin f krafft wrote:
> > Martin, I think --no-auto-check-trustdb and a cron job will
> > already make it much more bearable, with the current state of
> > things. That's what I'd suggest.
>
> I've been doing that for a long time already, and yes, it mitigates
### Do not reply below this line ###
-
Goddess: Primal Chaos | June 26, 2017 | 11:31 +0200
-
Dear player,
Thank you very much for contac
also sprach Peter Lebbing [2017-06-23 17:56 +0200]:
> There are two hard problems in computer science: Cache invalidation,
> naming things, and off-by-one errors.
I haven't heard that one in years. Lol. ;)
> Martin, I think --no-auto-check-trustdb and a cron job will
> already make it much more
On Fri, Jun 23, 2017 at 03:50:27PM +0200, Neal H. Walfield wrote:
>
> Ensuring that a cache is consistent is *hard*. I don't think we want
> to add complexity (nevermind a cache!) to this security-critical
> functionality.
>
Neal (or Werner), what executable is responsible for maintaining the t
At Fri, 23 Jun 2017 13:04:02 -0400,
Brian Minton wrote:
>
> [1 ]
> On Fri, Jun 23, 2017 at 03:50:27PM +0200, Neal H. Walfield wrote:
> >
> > Ensuring that a cache is consistent is *hard*. I don't think we want
> > to add complexity (nevermind a cache!) to this security-critical
> > functionalit
On 23/06/17 15:50, Neal H. Walfield wrote:
> Ensuring that a cache is consistent is *hard*. I don't think we want
> to add complexity (nevermind a cache!) to this security-critical
> functionality.
There are two hard problems in computer science: Cache invalidation,
naming things, and off-by-one
At Fri, 23 Jun 2017 15:35:05 +0200,
martin f krafft wrote:
> also sprach Werner Koch [2017-06-22 19:02 +0200]:
> > For a key listing this means computing it for every listed key. And the
> > majority of frontends first do a key listing and show the validity of
> > the keys before you can encrypt
also sprach Werner Koch [2017-06-22 19:02 +0200]:
> For a key listing this means computing it for every listed key. And the
> majority of frontends first do a key listing and show the validity of
> the keys before you can encrypt something.
Obviously, one could work with caching here…
Running -
On 2017/06/22 14:34, martin f krafft wrote:
> also sprach Andrew Gallagher [2017-06-21 15:57 +0200]:
>> I have a quick and dirty tool here:
>> https://github.com/andrewgdotcom/synctrust
>
> Yeah, that'll do the job, except it blindly overwrites changes made
> locally. It's unlikely this happens,
On Thu, 22 Jun 2017 16:29, madd...@madduck.net said:
> updating the trustdb on update of key material, wouldn't it make
> much more sense to compute the information just-in-time? Provided
For a key listing this means computing it for every listed key. And the
majority of frontends first do a key
also sprach Neal H. Walfield [2017-06-22 16:15 +0200]:
> I didn't say that it is not possible to have a better algorithm. It
> is possible. But, it is not as easy as you suggest (and what you
> suggest doesn't sound trivial).
>
> For instance, adding or updating a key doesn't necessarily result
Hi,
I didn't say that it is not possible to have a better algorithm. It
is possible. But, it is not as easy as you suggest (and what you
suggest doesn't sound trivial).
For instance, adding or updating a key doesn't necessarily result in
equal or more trust. An update could cause a key to be r
also sprach Peter Lebbing [2017-06-22 15:46 +0200]:
> > As far as I understand, the parameters --marginals-needed and
> > --completes-needed can be used to define a maximum search depth D,
> > so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd
> > envision it to
>
> Don't you me
On 22/06/17 15:00, martin f krafft wrote:
> As far as I understand, the parameters --marginals-needed and
> --completes-needed can be used to define a maximum search depth D,
> so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd
> envision it to
Don't you mean
>--max-cert
also sprach Andrew Gallagher [2017-06-21 15:57 +0200]:
> I have a quick and dirty tool here:
> https://github.com/andrewgdotcom/synctrust
Yeah, that'll do the job, except it blindly overwrites changes made
locally. It's unlikely this happens, but say I declared your key
trustworthy last night at
also sprach Neal H. Walfield [2017-06-21 14:00 +0200]:
> It starts with the set of ultimately trusted keys. But let's say
> that you start with key X, which is not ultimately trusted. What
> should GnuPG do with the result? Or, let's say that X is
> ultimately trusted and it decides that key Y
On 2017/06/20 14:34, martin f krafft wrote:
> 5. Has anyone come up with a smart way to keep pubring/trustdb
>synchronised between multiple workstations?
I have a quick and dirty tool here:
https://github.com/andrewgdotcom/synctrust
A
signature.asc
Description: OpenPGP digital signature
_
At Wed, 21 Jun 2017 13:55:52 +0200,
martin f krafft wrote:
>
> also sprach Neal H. Walfield [2017-06-21 11:53 +0200]:
> > > 3. Is there a way to run --check-trustdb or --update-trustdb not
> > >over the entire key graph, but only traversing to a certain depth
> > >starting from a specific
also sprach Neal H. Walfield [2017-06-21 11:53 +0200]:
> > 3. Is there a way to run --check-trustdb or --update-trustdb not
> >over the entire key graph, but only traversing to a certain depth
> >starting from a specific key? Then I could tell parcimonie to run
> >--check-trustdb for e
Hi,
At Tue, 20 Jun 2017 15:34:44 +0200,
martin f krafft wrote:
> I've spent some time trying to figure out how to make actual use of
> the web-of-trust (the "pgp" trust-model), and I am turning to this
> list for some advice, related to a couple of questions:
>
> 1. My public keyring has several
Hello,
I've spent some time trying to figure out how to make actual use of
the web-of-trust (the "pgp" trust-model), and I am turning to this
list for some advice, related to a couple of questions:
1. My public keyring has several thousand keys and "weighs" almost
500Mb. Every couple of runs,
25 matches
Mail list logo
