[OTR-dev] OTR key storage

[Tamme Schichler]

Am 10.09.2013 19:48, schrieb subharo at hushmail.com:
> Hello Tamme,
>
> So far I like your approach.  I've never heard of py2exe before,
> but you seem to have done your research WRT the options for using
> Python in Windows.  If py2exe is good enough for BitTorrent, then
> it's good enough for me.

Hello,

I have to look a bit more into the different options before we can 
decide on the Python version. From what I've seen it should be possible 
to get a reasonable distributable size with either though. I think I 
would prefer the plain "include parts of Python" option, as that should 
work without additional dependencies for the build. I really need to 
look into build automation, with C# VS does everything and it "just 
works". Maybe someone else reading this can help here.

> BTW: before getting started on otr-dev:
>
> 1) How would you feel about releasing it under, say GPL v2
> licensing?  That would be my first choice.

It depends on whether that allows closed-source messengers to use the 
service. I know both Pidgin and Gajim are GPL'd, but Trillian for 
example isn't and as such can't be distributed with the GPLv2 OTR 
plugin. It would be better to allow all clients to offer compatibility 
as core feature.

I agree with dkg on the forward-compatibility, we should definitely 
include the ", or (at your option) any later version" part.

I think we should use LGPLv2+ or LGPLv3+.

> 2) It sounds like you would like to develop in Windows first.  I
> would also propose that Debian stable (or testing or unstable, only
> if necessary) be the primary Linux distro to develop in first
> (trying to proceed in parallel with a Windows implementation),
> taking the time necessary to keep the core functionality
> installable and working in both OS's (before adding any bells-and-
> whistles features).
> I especially suggest Debian, because today's most popular Linux
> distros (Linux Mint, *buntu, Elementary OS, etc) are downstream
> from Debian.  IMHO, the best hope for this project, would be that
> an official Debian Developer would eventually come along (which I'm
> not), and help this software become a proper Debian package,
> eventually making its way into Debian main, with all the necessary
> dependencies getting sorted out along the way.  Eventually, it
> would be great if all OTR-computible IM's would have this proposed
> package as a dependancy (and not just a "recommendation", which
> IMHO would be very naiive in today's computer security climate)!
>
> Debian also ranks as a top recommendation on https://prism-
> break.org/ , as being trustworthy amidst all the Big News in the
> computer security world, which I'm sure you're also following.

That sounds like the best way to get started. I don't have a Debian 
system at the moment but setting up a VM should be no problem. Testing 
my commits there should be possible but I'm not sure if I can develop 
against the system API.

> I can perhaps offer a bit of help as time allows, and lots of Linux
> expertise.  I'll have to think over my current commitments before
> making any promises.  I've done some small-time coding of one-off
> system-adminstration-related Python scripts (usually not more than
> a hundred lines of code, which can accomplish quite alot), but I
> have little familiarity with modern version control systems and
> software packaging (you know, making .debs, unofficial APT
> repositories, etc).  I've never been a professional coder.  I've
> worked with many coders in past jobs.  I do have a B.Sc. in
> computer science, and 5 yrs experience as primarily a Unix/Linux
> Sysadmin (with some Windows admin experience too).  I have an eye
> to make things low-maintenance, simpler when possible, and easy to
> backup and restore.

I've only worked as Java developer for a short time before starting at 
university (mostly unrelated field), but I've written a lot more code in 
C# as private projects (a persistent dictionary, some network code, some 
scheduling and graphics, lots of file IO, and a ton of unfinished 
projects). I'd have to properly learn Python before starting which 
should take a week or two.

I use Mercurial, but Git should be fine too. I prefer the former because 
it's more convenient and has much better Windows integration (I prefer 
GUI over CLI if I have the choice). No packaging experience here either, 
everything I wrote so far didn't need to be installed.

No professional qualifications for me, I'd say I'm at a point where I 
could do well in most coding jobs though. I know a good amount of 
relatively low-level Windows, but not the C(++) API.

I tend to write modular code (my projects are split into reusable 
binaries that have their own subrepos if there's a logical abstraction 
layer), but not to the point where everything has an interface. I often 
start with the "highest" layer and then implement the more low-level 
parts as needed.

Unfortunately my free time varies a lot due to university, at the moment 
I have a lot, but it will be less when the semester starts. It should be 
enough to contribute on a regular basis.

> Are there any other python geeks, Debian geeks, or Debian
> Maintainers out there?
>
> If you agree that this sounds sensible, then I'll see you on otr-
> dev.

How does "OTR key storage" as topic sound? The service probably should 
handle both known public-key-contact associations and private keys for 
the user's identities as programs using one feature will most likely 
also use the other.

I look forward to contributing here, it looks like an interesting 
challenge that I hope will make encryption more accessible.

-Tamme