Managing the WoT with GPG

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Managing the WoT with GPG

martin f krafft-2
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, I'm told to run --check-trustdb,
   which takes several minutes to complete, then tells me that the
   next run will be in like 2 weeks, but three operations later, I'm
   again being asked to run --check-trustdb. The funny thing is that
   these operations are just message signing and authentication,
   sometimes decryption. However, parcimonie is running in the
   background, updating the keyring one key at a time. Is that the
   reason? If yes, is there any way to mitigate this? I've sketched
   out an idea under (3.) below, but maybe there's another way…?

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 approach this? Or does everyone just use
   tofu these days?

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 every key it imports, or have mutt run
   --update-trustdb for every key I want to use. This would
   iteratively achieve the job with the benefit that no cycles would
   be wasted processing trust for keys I never use. I understand
   --edit-key can be used to change the ownertrust, but I don't
   think it recomputes the WoT on change, does it?

   If there's no way to do this yet, would this be a useful addition
   to the UI, assuming it's technically possible?

4. Is there a tool to visualise or explain the computed validity of
   a key? I.e. one saying that e.g. Werner's key is valid because
   Daniel signed it, and I fully trust Daniel? There's wotsap, but
   I want to analyse my own keyring, not a .wot file…

5. Has anyone come up with a smart way to keep pubring/trustdb
   synchronised between multiple workstations?

Thanks for any insights!

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
darwinism is nothing without enough dead bodies.
 
spamtraps: [hidden email]

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Neal H. Walfield
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 thousand keys and "weighs" almost
>    500Mb. Every couple of runs, I'm told to run --check-trustdb,
>    which takes several minutes to complete, then tells me that the
>    next run will be in like 2 weeks, but three operations later, I'm
>    again being asked to run --check-trustdb. The funny thing is that
>    these operations are just message signing and authentication,
>    sometimes decryption. However, parcimonie is running in the
>    background, updating the keyring one key at a time. Is that the
>    reason? If yes, is there any way to mitigate this? I've sketched
>    out an idea under (3.) below, but maybe there's another way…?

You figured it out: whenever your keyring is updated, 'gpg
--check-trustdb' needs to be run.  This is normally done on demand,
which is annoying for even moderately sized keyrings.  You can disable
this behavior by setting no-auto-check-trustdb in your gpg.conf file.
In that case, you'll want to run 'gpg --check-trustdb' periodically to
integrate new keys, expiry information, revocations, etc.  You can do
this in the background via e.g. a cron job.

> 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 approach this? Or does everyone just use
>    tofu these days?

Since I don't trust most people to sign keys correctly, I just invoke
'gpg --edit-key' (and use the trust subcommand) on the specific keys
that I want to have as trusted introducers.

> 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 every key it imports, or have mutt run
>    --update-trustdb for every key I want to use. This would
>    iteratively achieve the job with the benefit that no cycles would
>    be wasted processing trust for keys I never use. I understand
>    --edit-key can be used to change the ownertrust, but I don't
>    think it recomputes the WoT on change, does it?
>
>    If there's no way to do this yet, would this be a useful addition
>    to the UI, assuming it's technically possible?

This isn't easy given the current implementation: GnuPG doesn't store
the graph, but traverses the graph and only saves whether a particular
key is trusted.

> 4. Is there a tool to visualise or explain the computed validity of
>    a key? I.e. one saying that e.g. Werner's key is valid because
>    Daniel signed it, and I fully trust Daniel? There's wotsap, but
>    I want to analyse my own keyring, not a .wot file…

See my answer to #3: this is not currently possible.

> 5. Has anyone come up with a smart way to keep pubring/trustdb
>    synchronised between multiple workstations?

This is a pain.  Something along the lines of the following should
work:

  gpg --export | ssh host gpg --import

:) Neal

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

martin f krafft-2
also sprach Neal H. Walfield <[hidden email]> [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 every key it imports, or have mutt run
> >    --update-trustdb for every key I want to use. This would
> >    iteratively achieve the job with the benefit that no cycles would
> >    be wasted processing trust for keys I never use. I understand
> >    --edit-key can be used to change the ownertrust, but I don't
> >    think it recomputes the WoT on change, does it?
> >
> >    If there's no way to do this yet, would this be a useful addition
> >    to the UI, assuming it's technically possible?
>
> This isn't easy given the current implementation: GnuPG doesn't store
> the graph, but traverses the graph and only saves whether a particular
> key is trusted.
It's gotta start somewhere, though, right? Can't it pick the leaf
where to start?

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
dies ist eine manuell generierte email. sie beinhaltet
tippfehler und ist auch ohne großbuchstaben gültig.
 
spamtraps: [hidden email]

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Neal H. Walfield
At Wed, 21 Jun 2017 13:55:52 +0200,
martin f krafft wrote:

>
> also sprach Neal H. Walfield <[hidden email]> [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 every key it imports, or have mutt run
> > >    --update-trustdb for every key I want to use. This would
> > >    iteratively achieve the job with the benefit that no cycles would
> > >    be wasted processing trust for keys I never use. I understand
> > >    --edit-key can be used to change the ownertrust, but I don't
> > >    think it recomputes the WoT on change, does it?
> > >
> > >    If there's no way to do this yet, would this be a useful addition
> > >    to the UI, assuming it's technically possible?
> >
> > This isn't easy given the current implementation: GnuPG doesn't store
> > the graph, but traverses the graph and only saves whether a particular
> > key is trusted.
>
> It's gotta start somewhere, though, right? Can't it pick the leaf
> where to start?

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 is only marginally trusted, but Y would have
been fully trusted if you started with all ultimately trusted keys.
How do you intelligently merge that?

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Andrew Gallagher
In reply to this post by martin f krafft-2
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


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

martin f krafft-2
In reply to this post by Neal H. Walfield
also sprach Neal H. Walfield <[hidden email]> [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 is only marginally
> trusted, but Y would have been fully trusted if you started with
> all ultimately trusted keys. How do you intelligently merge that?

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

  1. enumerate all keys reachable within D steps

  2. iterate all these keys

  3. backpropagate the trust/validity level towards 0xdeadbeef

  4. update the nodes touched by this walk in trustdb

  5. do this for every key when it changes

  6. do this for every key upon use, such that missing information
     can be interactively provided, and expired keys pruned
     just-in-time.

  7. --check-trustdb could still be used to do overall cleaning at
     regular intervals.

Given how the keygraph is essentially a singly-linked graph with
keys containing pointers to other keys that signed them, while there
exists no such information implicitly about all the keys that have
been signed *by* a given key (e.g. one that's ultimately trusted),
the approach I've sketched actually seems more intuitive, don't you
think?

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"here i was all convinced that if i sleep all day, bug counts go
 down, and if I work all day, they go up, so much for that theory."
                                                   -- lars wirzenius
 
spamtraps: [hidden email]

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

martin f krafft-2
In reply to this post by Andrew Gallagher
also sprach Andrew Gallagher <[hidden email]> [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 home, forgot to run sync, and
not-trustworthy this morning at the office (sorry, this is just
a silly example…), and then ran sync, your key would be trustworthy
again.

On the other hand, it'd be totally possible to export ownertrust
prior to the import, and then fire up vimdiff or the like on the two
versions. Not exactly a great UID at all.

It'd be better if trustdb would be journalled using a mergeable
approach.

And then again, something like jetring is far beyond overkill for
day-to-day usage…

#SyncIsHard

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"convictions are more dangerous enemies of truth than lies."
                                                 - friedrich nietzsche
 
spamtraps: [hidden email]

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Peter Lebbing
In reply to this post by martin f krafft-2
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-depth n
>               Maximum depth of a certification chain (default is 5).

? I don't see how --*-needed would limit the search depth, other than
that for an actual keyset increasing them would effectively probably
decrease the actual depth.

While in general there are probably many avenues to be more efficient
about --check-trustdb, introducing too much complexity raises the
likelihood of bugs, especially if you start to intelligently update
trust by partial traversal.

Perhaps it would already be enough to split it into three phases:

1) Consider every key signature potentially valid. Construct the graph
of signatures. Discard anything that is not rooted in an ultimately
trusted key.

2) Still assuming correctness of key signatures, now consider
ownertrust. Remove any key that clearly does not have enough trust from
further computations (but leave in place all edges in the graph of the
remaining keys).

3) Start at the ultimately trusted keys and consider each signature that
corresponds to an edge going out of a valid key. Check signatures until
full validity of a key is reached (or all signatures on a key have been
checked). Stop checking then; it can't become more than fully valid by
more signatures. The fact that a key has been added to the valid keys
means you now have more edges going out from a valid key; keep repeating.

When a key fails to become valid in 3), you could consider the criteria
of 2) again and prune some keys from the graph, but it might be
over-optimizing. Without it it might already be plenty quick.

I don't know what the current algorithm is, but given its runtime, I'm
thinking it might be "check all signatures that can be checked" followed
by "now propagate validity through ownertrust". In my sketched proposal,
a *lot* of signatures would probably remain unchecked because they can't
further affect the validity of a key.

HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

martin f krafft-2
also sprach Peter Lebbing <[hidden email]> [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 mean
>
> >        --max-cert-depth n
> >               Maximum depth of a certification chain (default is 5).
>
> ? I don't see how --*-needed would limit the search depth, other than
> that for an actual keyset increasing them would effectively probably
> decrease the actual depth.
Yeah, that too.

> 1) Consider every key signature potentially valid. Construct the
>    graph of signatures. Discard anything that is not rooted in an
>    ultimately trusted key.

That sounds like a worthwhile optimisation, indeed.

> 3) Start at the ultimately trusted keys and consider each signature that
> corresponds to an edge going out of a valid key. Check signatures until
> full validity of a key is reached (or all signatures on a key have been
> checked). Stop checking then; it can't become more than fully valid by
> more signatures. The fact that a key has been added to the valid keys
> means you now have more edges going out from a valid key; keep repeating.

And so does this…

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"durch frauen werden die höhepunkte des lebens bereichert
 und die tiefpunkte vermehrt."
                                                 - friedrich nietzsche
 
spamtraps: [hidden email]

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Neal H. Walfield
In reply to this post by martin f krafft-2
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 revoked.  In
that case, if 0xdeadbeef is marginally trusted, we now need to
identify keys that were considered valid because of 0xdeadbeef, but no
longer are.

:) Neal

At Thu, 22 Jun 2017 15:00:52 +0200,
martin f krafft wrote:

>
> [1  <text/plain; us-ascii (quoted-printable)>]
> also sprach Neal H. Walfield <[hidden email]> [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 is only marginally
> > trusted, but Y would have been fully trusted if you started with
> > all ultimately trusted keys. How do you intelligently merge that?
>
> 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
>
>   1. enumerate all keys reachable within D steps
>
>   2. iterate all these keys
>
>   3. backpropagate the trust/validity level towards 0xdeadbeef
>
>   4. update the nodes touched by this walk in trustdb
>
>   5. do this for every key when it changes
>
>   6. do this for every key upon use, such that missing information
>      can be interactively provided, and expired keys pruned
>      just-in-time.
>
>   7. --check-trustdb could still be used to do overall cleaning at
>      regular intervals.
>
> Given how the keygraph is essentially a singly-linked graph with
> keys containing pointers to other keys that signed them, while there
> exists no such information implicitly about all the keys that have
> been signed *by* a given key (e.g. one that's ultimately trusted),
> the approach I've sketched actually seems more intuitive, don't you
> think?
>
> --
> @martinkrafft | http://madduck.net/ | http://two.sentenc.es/
>  
> "here i was all convinced that if i sleep all day, bug counts go
>  down, and if I work all day, they go up, so much for that theory."
>                                                    -- lars wirzenius
>  
> spamtraps: [hidden email]
> [2 Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) <application/pgp-signature (7bit)>]
> No public key for 9C9D6979AE941637 created at 2017-06-22T15:00:47+0200 using RSA

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

martin f krafft-2
also sprach Neal H. Walfield <[hidden email]> [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 in
> equal or more trust.  An update could cause a key to be revoked.  In
> that case, if 0xdeadbeef is marginally trusted, we now need to
> identify keys that were considered valid because of 0xdeadbeef, but no
> longer are.

This would be handled upon use of such keys. In fact, rather than
updating the trustdb on update of key material, wouldn't it make
much more sense to compute the information just-in-time? Provided
we'd have a data format allowing for fast access like this?

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"the scientific paper in its orthodox form does embody a totally
 mistaken conception, even a travesty, of the nature of scientific
 thought."
                                                -- sir peter medawar
 
spamtraps: [hidden email]

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Werner Koch
On Thu, 22 Jun 2017 16:29, [hidden email] 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 listing and show the validity of
the keys before you can encrypt something.

BTW, the algorithm posted here looked much like classic PGP without all
the extra steps necessary for the PGP 6 variant of the WoT we implement.
(I have not fully followed the thread, though.)


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Andrew Gallagher
In reply to this post by martin f krafft-2
On 2017/06/22 14:34, martin f krafft wrote:

> also sprach Andrew Gallagher <[hidden email]> [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 home, forgot to run sync, and
> not-trustworthy this morning at the office (sorry, this is just
> a silly example…), and then ran sync, your key would be trustworthy
> again.
Yes, this is a limitation. I did say it was dirty. ;-)

> On the other hand, it'd be totally possible to export ownertrust
> prior to the import, and then fire up vimdiff or the like on the two
> versions. Not exactly a great UID at all.

Not the raw diff, no. But it might be possible to run a diff on the
ownertrusts, ignore any "normal" changes (e.g. where the old/local trust
state was "unknown") and present the user with a list of potentially
dangerous conflicts, such as your unlikely scenario above.

> It'd be better if trustdb would be journalled using a mergeable
> approach.

Trust signatures could trivially implement this, iff it were possible to
ltsign a key without also certifying it. (Feature request?)

> #SyncIsHard

Amen.

A



_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

martin f krafft-2
In reply to this post by Werner Koch
also sprach Werner Koch <[hidden email]> [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 --check-trustdb in the background once a day is doable, for
sure.

I guess what I'd really like is a way to run --update-trustdb just
for a specific key, and a way to do that automatically when using
a key, e.g. to verify or encrypt to…

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"president thieu says he'll quit if he doesn't get more than 50% of
 the vote. in a democracy, that's not called quitting."
                                                -- the washington post
 
spamtraps: [hidden email]

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Neal H. Walfield
At Fri, 23 Jun 2017 15:35:05 +0200,
martin f krafft wrote:

> also sprach Werner Koch <[hidden email]> [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 --check-trustdb in the background once a day is doable, for
> sure.
>
> I guess what I'd really like is a way to run --update-trustdb just
> for a specific key, and a way to do that automatically when using
> a key, e.g. to verify or encrypt to…

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.

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Peter Lebbing
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 errors.

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.

Other than that, I don't think my outlined strategy is very complex, it
basically boils down to not actually checking a signature until it is
used to compute validity, and stop for a specific key when full validity
is reached. I could be wrong though. It just doesn't seem like it should
be high on a TODO list, which in practice probably means it won't be
done. If the cron job wasn't available as an option, the situation would
be different.

Peter.

PS: I didn't come up with "There are two..." but I can't be arsed to
look up proper attribution :-).

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Brian Minton
In reply to this post by Neal H. Walfield
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 trustdb?
Is that handled by gpg itself?

--
Brian Minton
brian at minton dot name http://brian.minton.name
Live long, and prosper longer!
OpenPGP fingerprint = 8213 71DD 4665 CF4F AE20  2206 0424 DC19 B678 A1A9

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (399 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Neal H. Walfield
At Fri, 23 Jun 2017 13:04:02 -0400,
Brian Minton wrote:

>
> [1  <text/plain; us-ascii (quoted-printable)>]
> 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 trustdb?
> Is that handled by gpg itself?

gpg does it, yes.  See gnupg/g10/trustdb.c:validate_keys

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

martin f krafft-2
In reply to this post by Peter Lebbing
also sprach Peter Lebbing <[hidden email]> [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 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
the issue a little bit. I still think that the interface doesn't
exactly invite people to invest time into the WoT, which directly
translates into lesser quality.

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"auch der mutigste von uns hat nur selten den mut zu dem,
 was er eigentlich weiß."
                                                 - friedrich nietzsche
 
spamtraps: [hidden email]

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Managing the WoT with GPG

Goddess: Primal Chaos
In reply to this post by martin f krafft-2
### Do not reply below this line ###
Goddess: Primal Chaos
June 26, 2017, 11:31 +0200
Dear player,
Thank you very much for contacting us by mail. As the language or region of your email can’t be automatically identified, we have to manually sort through each and every issue then send these on to the relevant GM.
- If you are able to log in to the game, we recommend you send a message to us in-game via Settings-Account-Help.
- If you can’t find your account, usually it means you’re using the wrong login method or server. Please confirm you’re using the same login method as before and have selected the correct server.
Please note that even if have bound to your Facebook or Google account, if you are using "Sign In" to login, please login exactly as previously since data is not exchanged between the three different login methods.
Please leave your correct server and character name (if you’re using any special symbols in your name, please ensure you’re continuing to do so) and we’ll check your login method as soon as possible for you to.
Thanks for your support and cooperation!

Goddess: Primal Chaos
June 26, 2017, 11:31 +0200
Hi, thanks for contacting Customer Service. This is an automated reply, hope to help you solve common problems. Please tell me your server and character's name. Manual service will contact you as soon as possible! Thank you very much for the support and patience.

If you have a problem with recharge, please leave us the necessary information.
1. the name of the character(IGN)
2. the server
3. the number of your order
# via Google, we need the GPA.XXXX-XXXX-XXXX-XXXXX
#via Apple, we need the number from the receipt and also a screenshot that you take from the Itunes of your computer.
#other ways, please let us know the exact way of recharging and the number of it
4. the UID of this character (which you can see in the game, but if you cannot find it that will be fine )
We are really hope that we could help!

If you want to report a BUG, please try to tell us more details, such as related character names and servers. The most important is the exact time (better with hour and minute), so that we locate and check the problem more quickly. Thank you in advance.

martin f krafft
June 26, 2017, 11:31 +0200
Managing the WoT with GPG

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 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
the issue a little bit. I still think that the interface doesn't
exactly invite people to invest time into the WoT, which directly
translates into lesser quality.

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/

"auch der mutigste von uns hat nur selten den mut zu dem,
was er eigentlich weiß."
- friedrich nietzsche

spamtraps: [hidden email]
_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Attachments:


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
12
Loading...