Today’s Topics:

Krista topics:

I’m apparently back, be gentle :)

Prios:

1. Key election removal (see below)
2. What fires need to be put out? (N.B. We should discuss how fires are determined in light of recent events)

Key Election Status

Key election removal is largely implemented; however, removing it exposed some ugly use cases. Three things we’ll need to consider:

1. Unexpected issues, and
2. Documenting the changes the apps will need to be aware of so they are not constantly filing bugs, and
3. Transition issues

Unexpected issues

I will have to spend some time getting back up to speed. The following issues are in my chat log, though, to begin with:

1. update_identity()

15:33 <darthmama> ignore this til you get back, I just need to note it down
15:37 <darthmama> key election removal makes our TOFU hijinks difficult; the way 
                  the update identity algorithm uses usernames as a filter will 
                  cause problems if a comm partner uses slightly different names 
                  on two devices.
15:37 <darthmama> We don't always find the keys when we would expect to, and this 
                  will cause problems when we have a comm partner that the apps 
                  don't make a contact
15:38 <darthmama> The solution, as I see it, is this:
15:39 <darthmama> For as long as we don't have a user_id, if there is a TOFU 
                  identity stored and no identity on the input ident to 
                  update_identity, we take the TOFU info and ignore usernames
15:42 <darthmama> Alternately, we make the affirmative decision that we don't 
                  care to encrypt to anyone we don't want to make a contact 
                  (which I think is a horrible idea)
18:11 <darthmama> Hrm. This one is actually a tricky, nasty problem.
18:14 <darthmama> "I know my Bob sent me his key, but I can't encrypt a message 
                  to him", especially based on something as arbitrary as the name 
                  used. I mean, if the typical use case we're expecting is either 
                  direct reply or someone we've made a contact of, that's fine, 
                  but I know I have plenty of folks I don't stick in my contacts 
                  that I mail regularly, and I might specify a different name 
                  than they do
18:15 <darthmama> On the other hand, we're already accepting that key as the 
                  default key for the temporary identity we created based on 
                  not-very-much information
18:16 <darthmama> so it seems to me the username "check" isn't doing much here.
                  It's a nice heuristic, but it doesn't really provide us with 
                  much

2. There was something related to TOFU which was the real blocker, but I’ll have to get back to you later today, as I don’t remember what it was (it may have been related to the above, but I’m not sure now).

Changes which may impact apps

The apps will need to understand that TOFU will now fail under certain circumstances and that it is intentional (specifically, when we have a key that we didn’t receive it the “right” way)

Transition issues

What do we do about folks who communicate using keys which haven’t been trusted now? Not all of those will have been saved as defaults in the DB. Additionally, for folks with OpenPGP contacts, they will have to be informed about how their contacts need to send keys - otherwise, they’ll never be able to encrypt to them, since they never see keys!!!!

Documentation and testing

Krista, Kelly, and Sofia have a weekly meeting now to discuss engine docs and tests. Krista will try to delegate and explain as time allows.

Volker Issues

• Will we reply with keys?
• How is this related to Extra Keys?
• ENGINE-817
• Process of Protocol Specification / Implementation

Other stuff