Re: Managing the WoT with GPG

2017-06-23 Thread Brian Minton
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

Re: Managing the WoT with GPG

2017-06-23 Thread Neal H. Walfield
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 > >

Re: Managing the WoT with GPG

2017-06-23 Thread 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

Re: Managing the WoT with GPG

2017-06-23 Thread Neal H. Walfield
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

Re: Managing the WoT with GPG

2017-06-23 Thread martin f krafft
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

Re: Using gpg for ssh (Maximum Portability)

2017-06-23 Thread Christopher Jones
Peter and Andrew, Thank you both for your responses. I'm going to see if I can't use your advice to ease my frequent system hoteling woes. -CJones ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: TOFU

2017-06-23 Thread Peter Lebbing
On 23/06/17 03:07, MFPA wrote: > I thought "good signature" just meant the message has not been > altered in transit. That's very well possible. In that case there is no verbal indication of a valid signature, only a colour. The text I see for a signature by a fully valid key is: Good signature

Re: Are TOFU statistics used for validity or conflict resolution?

2017-06-23 Thread Neal H. Walfield
At Fri, 23 Jun 2017 13:22:23 +0200, Peter Lebbing wrote: > On 23/06/17 12:56, Neal H. Walfield wrote: > > It's up to the GPG client to interpret it. This document (authored by > > Andre and me) has some recommendations for MUAs: > > Ah! Thanks for the information. > > I was thinking about how

Re: Are TOFU statistics used for validity or conflict resolution?

2017-06-23 Thread Peter Lebbing
On 23/06/17 12:56, Neal H. Walfield wrote: > It's up to the GPG client to interpret it. This document (authored by > Andre and me) has some recommendations for MUAs: Ah! Thanks for the information. I was thinking about how GnuPG handled it, i.e., on the gpg command line or as a backend for some

Re: Are TOFU statistics used for validity or conflict resolution?

2017-06-23 Thread Neal H. Walfield
At Fri, 23 Jun 2017 12:52:48 +0200, Peter Lebbing wrote: > > [1 ] > On 23/06/17 11:14, Neal H. Walfield wrote: > > No, both keys are set to ask. The key with a lot of observed > > signatures could be bad. This could occur, if there is a MitM, but > > the MitM has a small lapse, because,

Re: Are TOFU statistics used for validity or conflict resolution?

2017-06-23 Thread Teemu Likonen
Neal H. Walfield [2017-06-23 11:14:31+02] wrote: > At Thu, 22 Jun 2017 20:32:48 +0300, Teemu Likonen wrote: >> Then let's say I have a key which has been used to verify hundred or >> so signatures. In --status-fd's TOFU_STATS it gets higher >> value, say 4. Then the keyring gets a new key with

Re: Using gpg for ssh (Maximum Portability)

2017-06-23 Thread Andrew Gallagher
On 2017/06/21 18:17, Peter Lebbing wrote: > On 18/06/17 03:48, Christopher Jones wrote: >> It's a task to setup gpg on new boxes: Import pub key, ultimately trust >> my key, and muck around with gpg and ssh agents. > > Configuring gpg as an SSH agent for Linux in the easiest way is very, > very

Re: Managing the WoT with GPG

2017-06-23 Thread Andrew Gallagher
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

Re: Are TOFU statistics used for validity or conflict resolution?

2017-06-23 Thread Neal H. Walfield
At Thu, 22 Jun 2017 20:32:48 +0300, Teemu Likonen wrote: > Teemu Likonen [2017-06-22 09:42:50+03] wrote: > > Does the SUMMARY field's value (0-4) have effect on how key's validity > > is calculated or how TOFU conflicts are resolved or presented to a > > user? > > I didn't get answers yet but

Re: Key corruption: duplicate signatures and usage flags

2017-06-23 Thread martin f krafft
also sprach Werner Koch [2017-06-23 09:40 +0200]: > Those flags are tracked in self-signatures. When changing a flag > a new self-signature is used. This will be uploaded to the > keyserver. gpg uses the flags from the latest self-signature it > has. So how does this explain

Re: Key corruption: duplicate signatures and usage flags

2017-06-23 Thread Werner Koch
On Fri, 23 Jun 2017 00:33, 2014-667rhzu3dc-lists-gro...@riseup.net said: > I didn't know you could remove a usage flag once the key was on the Those flags are tracked in self-signatures. When changing a flag a new self-signature is used. This will be uploaded to the keyserver. gpg uses the

Re: Key corruption: duplicate signatures and usage flags

2017-06-23 Thread martin f krafft
also sprach MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> [2017-06-23 00:33 +0200]: > I didn't know you could remove a usage flag once the key was on the > keyservers. Well, it somehow seems to work, apart from the fact that gnupg first needs to clean up the key (using --edit-key) after