[OTR-users] Pretty-please standardize OTR signature storage, per OS.

[Tamme Schichler]

Hello Subharo,

Am 01.10.2013 18:56, schrieb subharo at hushmail.com:
> Hello Tamme, and others,
> 
> My Python guru, who wishes to remain anonymous, informs me:
> 
> "I think named pipes are not the right solution for Windows, don't
> think they even exist.  It sounds like they want to make a something
> like PuTTY agent, for managing SSH keys.  The source code for PuTTY
> exists, someone could make a modified copy of it."
> 
> FWIW, I'd also like to point out that http://stackoverflow.com/ has 
> excellent answers to well-poised, highly-sophisticated programming 
> questions.

named pipes do exist, it's possible that they work a bit differently
from Unix though. They are not reachable from the command line by default.
The PuTTY agent uses a memory mapped file but that would require
additional synchronization and a more complicated protocol to handle
multiple clients (and a frozen client can block the whole system in the
easiest implementation).
The named pipes do everything that's needed in the most simple way
possible, the problem is that I can't connect them to Python. (Neither
they nor shared memory seems to be part of the standard library and I
haven't found a named-pipe module so far.)

Asking on Stack Overflow seems like a good idea, I'm currently too busy
to dive into the WinAPI though.

> Tamme, *I applaud your efforts*, however I'd like to point out that 
> the birthplace of OTR is Pidgin, and the birthplace of Pidgin is 
> the Linux world.  Using any C# code at all, even just for testing-
> related utilities, will probably scare away the majority Linux 
> people.  Mono doesn't have a good reputation, generally, even 
> though it's open source.  Even that faint whiff of Microsoft is 
> distasteful enough to most Linux folks.

That's unfortunate if true. While there are some notable libraries that
are incompatible (WPF, MonoGame, Microsofts server infrastructure...),
the Common Language Infrastructure itself and C# are
platform-independent and standardized. There's the JVM, but it's not all
that great in comparison, feature wise.

> Tamme, you also wondered where the spec for OTR is.  It appears 
> there is none.  All there is to go on, for now, it seems, is just 
> to "wing it", after carefully observing the formatting seen in the 
> config file that Pidgin creates, containing the OTR signature 
> (which was mentioned a bit earlier, in this mailing list).  
> Somebody, please correct me, if I'm wrong.

Pidgin seems to store just a list of (account, key) pairs for own
identities and (nickname, verified?, fingerprint) for known
fingerprints. (I could not check the latter one in the config files.)

I think what would work best is using lists of (network, id,
friendly_name, key) for own identities and (uid, network, id,
friendly_name, verified?, fingerprint) for known fingerprints.

I don't have the time to do it currently, but it seems reasonably
straightforward. My concern was mainly with what data needs to be
stored, it seems there's a good balance between ease-of-use and
ease-of-implementation this way though.

> Furthermore, I've considered how involved I can get into this, and 
> I've decided I can't offer more than this much.

I have a few things coming up right now, so I probably won't be able to
contribute either for the next month or so.

> I wish everyone the best in this, however I'm moving on for now, as 
> I've come up with a primitive workaround to this duplicate OTR 
> signature problem for: create a new, unique XMPP (or whatever IM-
> protocol) account in each IM client one uses, each with a slightly 
> different name.  Each unique account gets a unique OTR fingerprint, 
> and then there is no "collision" in OTR fingerprints.  The 
> unfortunate side effect is needing to add all of one's IM contacts 
> multiple times, one for each unique account.  But that's not so 
> bad, it just adds a few more minutes work (including the OTR 
> signature exchange for each account, with each contact).  
> Typically, even a sophisticated user would only use 2 or 3 OTR-
> aware IM clients, in tandem.
> 
> Peace out,
> Subharo
> 

So the problem is basically the remote clients not understanding
multiple valid fingerprints for one account? Maybe that should be added
to the specification as requirement (with a clear warning message when
adding an additional key).

-Tamme