[guardian-dev] Fwd: [keysync] The conversion of keys should not depend on the existence of Jitsi configuration files

Mohamed Akram Tabka akram at accessnow.org
Fri Sep 27 13:49:08 EDT 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/09/13 15:32, Hans-Christoph Steiner wrote:
> 
> 
> On 09/25/2013 05:04 PM, Mohamed Akram Tabka wrote:
>> On 25/09/13 20:58, Hans-Christoph Steiner wrote:
>> 
>> 
>>> On 09/24/2013 09:16 PM, Mohamed Akram Tabka wrote:
>>>> 
>>>> On 25/09/13 01:16, Hans-Christoph Steiner wrote:
>>>> 
>>>>> Ideally, keysync would not need to read the Jitsi files,
>>>>> but Jitsi will have to be changed to support that.
>>>>> Jitsi's file format is much harder to work with than
>>>>> libotr-based apps because it uses one config file for many
>>>>> settings, including accounts and OTR.  If KeySync just
>>>>> overwrote the existing sip-communicator.properties with the
>>>>> OTR stuff that it gets from other apps, that would wipe out
>>>>> all of the account settings in Jitsi.  Therefore KeySync
>>>>> needs to first load the entire Jitsi config, then change
>>>>> the OTR stuff, then write the whole thing out again.
>>>> 
>>>> 
>>>> 
>>>> I didn't say we will wipe out accounts and their
>>>> configuration . We should append them if they exist. If they
>>>> doesn't, we don't block we create our file and we continue.
>> 
>>> This sounds useful for bootstrapping Jitsi with OTR key info.
>>> Have you tested Jitsi to see if it will properly import a 
>>> sip-communicator.properties file that already exists when Jitsi
>>> is started for the first time?
>> 
>> Yes, I have tested Jitsi and it imports properly the file when
>> started for the first time. There is no problem .
> 
> Good to know.  Now the question is how KeySync should behave.  How
> can it detect that Jitsi is installed but hasn't started, or should
> it always just output to all supported apps?  I can't think of an
> answer to this, except keeping the same automatic behavior while
> making it easy for people to manually force output to any app that
> they choose.
> 
> So in the GUI app, automatically detected apps would show up
> automatically, then the user could add other apps with the "other"
> button and that would default to the standard location for that
> app's conf files.
> 
> https://guardianproject.mybalsamiq.com/projects/gpgcleanroom/KeySync%20main%20screen%20with%20detected%20apps
>
>  .hc
> 
> 
>>>> What I'am doing is trying to cover all use cases: What if
>>>> Keysync is not used from my own PC. So If that PC contains
>>>> Jitsi with some OTR keys in it's configuration, I risk to get
>>>> the keys of someone else when keysync load the file while I
>>>> want only to convert my keys that somehow exists on Pidgin to
>>>> use them in another place.
>>>> 
>>>> Generally, I think that the best way is to give user choice.
>>>>  Especially if he has specified a different output folder and
>>>> he is not about to overwrite the file of the application. in
>>>> this case, KeySync will parse existant keys on Jitsi file and
>>>> say "found some otr keys in the application file and ask the
>>>> user if he wants to append them or not ?" .
>> 
>>> Currently, the idea behind KeySync is that is has direct
>>> read/write access to your chat apps' conf files because you are
>>> running the account manually on your own computer.  If people
>>> are writing out the files to a separate folder to be later
>>> copied into place, they are on their own in terms of making
>>> sure the data is valid.  That's just too big a problem for us
>>> to handle right now, we're focusing on what we can first
>>> achieve before trying to think about other situations.  Anyone
>>> is welcome to take on the use cases they find important.
>> 
>>> We are designing a protocol to securely sync OTR trust data via
>>> OTR itself. That will be first used between KeySync and
>>> ChatSecure, but we hope to make it a useful protocol that
>>> anyone can implement.
>> 
>> About the protocol, it sounds like a good idea. I hope it will
>> be usefully implemented for others IM clients.
>> 
>> 
>>>>> So with Jitsi working as it does now, the only way to make 
>>>>> KeySync automatically sync with Jitsi is to first read the 
>>>>> Jitsi config. Also, I'm unaware of any OTR import function
>>>>> in Jitsi for a user to do this manually.
>>>> 
>>>>> Are you proposing adding something to Jitsi?
>>>> 
>>>> Yes, there is no OTR import fuction in Jitsi. I tried to
>>>> make some sort of plugin that is based on the old version of 
>>>> OtrFileConverter. But since it was written in python and
>>>> Jitsi is Java, it not really compatible. I think that needs
>>>> to convert all the code of keysync to Java and make a new
>>>> implementation. you have an idea for that?
>> 
>>> I think we should focused on getting things fully working in 
>>> KeySync first. Then people can use KeySync as an example for
>>> how to do it in their own apps. Unfortunately, its a bigger
>>> problem than it seems.
>> 
>>> .hc
>> 
>>>> 
>>>> A.
>>>>> .hc
>>>> 
>>>>> On 09/24/2013 06:49 PM, Mohamed Akram Tabka wrote:
>>>>>> Hi all, About Keysync, I tried to mention why I think it
>>>>>> is useless to depend on the existence of configuration
>>>>>> files Jitsi.
>>>>>> 
>>>>>> Here is the forwarded e-mail:
>>>>>> 
>>>>>> -------- Original Message -------- Subject: [keysync] The
>>>>>>  conversion of keys should not depend on the existence
>>>>>> of Jitsi configuration files Date: Tue, 24 Sep 2013
>>>>>> 20:30:31 +0100 From: Mohamed Akram Tabka
>>>>>> <akram at accessnow.org> To: Hans-Christoph Steiner
>>>>>> <hans at guardianproject.info>
>>>>>> 
>>>>>> Hi Hans,
>>>>>> 
>>>>>> I think besides verifying if Jitsi is running after 
>>>>>> converting OTR keys, we should also do not depend on the 
>>>>>> existence of sip-communicator.properties file under the
>>>>>> Jitsi configuration folder. This is not useful at all. In
>>>>>> to many use cases this will limit the functionality of
>>>>>> KeySync.
>>>>>> 
>>>>>> What I understood from you is by copying the file you
>>>>>> don't want to erase the configuration made on Jitsi
>>>>>> before. But it is not a good idea. It will be most
>>>>>> appropriate to notify the user to append his keys to the
>>>>>> file and not replace the old file when copying. So, what
>>>>>> do you think ?
>>>>>> 
>>>>>> By the way, I found that it is not possible to convert an
>>>>>>  already converted Jitsi key to Pidgin unless we use it
>>>>>> at least one time with Jitsi. Because it works with the
>>>>>> contacts file "contactlist.xml". I think, we can get the
>>>>>> accounts Id only from sip-communicator.properties file
>>>>>> and avoid using "contactlist.xml". Unless, there is
>>>>>> another need for this file ?
>>>>>> 
>>>>>> 
>>>>>> So, generally what I think is KeySync must operate 
>>>>>> independently from the configuration Jitsi, only with
>>>>>> using OTR keys. what do you think ?
>>>>>> 
>>>>>> All bests,
>>>>>> 
>>>>>> A.
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Guardian-dev mailing list
>>>>>> 
>>>>>> Post: Guardian-dev at lists.mayfirst.org List info: 
>>>>>> https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>>> 
>>>>>> To Unsubscribe Send email to: 
>>>>>> Guardian-dev-unsubscribe at lists.mayfirst.org Or visit: 
>>>>>> https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>>>
>>
>>>>>> 
You are subscribed as: hans at guardianproject.info
>>>>>> 
>>>> 
>>>> 
>>>> 
>>>>> _______________________________________________
>>>>> Guardian-dev mailing list
>>>> 
>>>>> Post: Guardian-dev at lists.mayfirst.org List info: 
>>>>> https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>> 
>>>>> To Unsubscribe Send email to: 
>>>>> Guardian-dev-unsubscribe at lists.mayfirst.org Or visit: 
>>>>> https://lists.mayfirst.org/mailman/options/guardian-dev/akram%40accessnow.org
>>>>
>>>>>
>>>>>
>>
>>>>> 
You are subscribed as: akram at accessnow.org
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> A.
>> 
>> 
> 

I have a small suggestion about KeySync Behaviour:

- - Instead of disabling icons when the application is running, we
highlight when installed and we leave the verification of "running" if
the user specifies the default application output . (it allows us to
remove the "others" buttons which reduces the usability of the interface)

- - We should give user the possibility to force output if he want.

This is explained in the following picture. (I wanted to add it to the
site but I failed.)
http://img202.imageshack.us/img202/6831/p2yt.png

A.



- -- 
Mohamed Akram Tabka
Tech intern at Access | AccessNow.org
Student at the National School of Computer Sciences
PGP ID : 0x82000BEF
PGP FingerPrint : 40DF DB6B D10B 107B 7609 362F 1045 B72D 8200 0BEF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSRcUUAAoJEBBFty2CAAvvxioH/2O0hl4p5RqVBSDKyntPLWEm
CT1pD/eHVucb7iNGezLe6rYkDmVlZDDxoJyQ5WhoPAT3SIZwS8xpqEqBdr4OoASe
uSP0yiVgLU7cxYRQ3OI01BUQXh/sqCgf6+Ja09Ytdn29nrFCfhb2c9nrPE2WGD4Z
XcbTOTRMcpLtmq+biMyRSbXVMQ7pCv671oo/bQNIXJIA7MB76X4fmkt1mBjIxJjK
csnKr+ZgvkafTj1T+WZJLOj//Q+F4C8KXxk3IfUnY5k5ycLfKlciEmxPuq9rK1VF
T5XD3pzilv+OQihzxqx5HpPififOOUmIjMstkk1kaQ11OVNrMxXy7DimAOAWJQQ=
=VQY+
-----END PGP SIGNATURE-----


More information about the Guardian-dev mailing list