[Flug] Supporto per il progetto Mixminion
marcoc1@dada.it
marcoc1@dada.it
Lun 23 Ago 2004 01:17:02 CEST
Con tempi non proprio brevi e' andato in porto il contatto
ufficiale aperto a nome del Flug e del PWS con Len Sassman
e gli altri core developer del progetto Mixminion.
Per riassumere, il supporto che e' ci stato richiesto, riguarda
5 punti
1) esplorare la possibilita' tecnica di ospitare
uno dei futuri directory server distribuiti
(il prossimo, ed ultimo passo per la creazione
di una rete Mixminion completa)
2) produzione di documentazione (in inglese)
3) programmazione, specialmente per la creazione
di una interfaccia utente
4) Backup periodico del cvs di progetto
5) creazione di un logo (c'e' un suggerimento nel todo)
Ci sono poi molti altri punti su cui contribuire,
che trovate raccolti nel file todo allegato
Per quanto riguarda il punto 1 sto portando avanti
(non saranno tempi brevissimi) la verifica tecnica
per la gestione di un directory server.
Il punto 4 sembrerebbe la cosa piu' realizzabile
nell'immediato; il cvs (non molto movimentato)
e' quello puntato dalla pagina di sourceforge,
ed i file risultanti dovrebbero essere recuperabili
senza autorizzazioni via http (directory listabile ?)
oppure ftp anonimo; chi se ne potrebbe occupare
sul serverone ?
Per gli altri punti, e per quanto riguarda i contenuti
del todo, si apra il dibattito. Fatevi avanti !
Sottolineo nuovamente l'importanza che il progetto Mixminion
ha per la difesa della privacy.
Promette di unificare remailer, nym server e stats server, mandando
in soffitta tutti i vecchi ed onorati software a cominciare
da Mixmaster, e fornendo servizi semplici ed affidabili
sia livello utente che a livello amministratore.
Non credo di esagerare dicendo che, insieme a Freenet e GnuPG,
sarebbe in grado di garantire tutto cio' che serve per la privacy
in rete di oggi e del prossimo futuro.
Ciao a tutti. Marco
===========================================================
$Id: HACKING,v 1.25 2004/04/04 17:58:28 nickm Exp $
Hacking Mixminion
HOW TO CONTRIBUTE PATCHES:
- Send them to the list mixminion-dev@freehaven.net, or to me
(nickm@freehaven.net).
- Include a statement saying that you give permission for me to
redistribute your work under any FSF-approved license Mixminion
may use in the future, including (but not limited to) LGPL, GPL,
modified (3-clause) BSD, X11, or MIT.
System requirements:
Python >= 2.0 (see PORTING NOTES below)
OpenSSL 0.9.7 (If you don't have it, the Makefile knows how to
download it for you.)
NON-HACKING PROJECTS:
- We need documentation.
- See the spec for open issues.
- We need a logo. (An alien with an eggbeater or an alien at a DJ's
mixer
are two ideas.)
THINGS TO HACK: (Good introductory projects that I won't get to myself
for
at least a version or two.)
- We need some distributed stress-test code. Ideally, it should use SSH
to
build Mixminion on a number of machines and start servers on those
machines, then run a bunch of clients to send messages through the
system.
It should be possible to run the code with different network and
server
configurations. (Difficulty: moderate. Invasiveness: none.)
- The current implementations for the MBOX and SMTP modules open a new
connection to the local MTA for each outgoing message. This is
inefficient; they should batch as much as possible. (Difficulty:
easy.
Invasiveness: slight.)
- The current implementation for the MBOX and SMTP modules do not
support
ESMTP (over TLS). They should. (Difficulty: easy. Invasiveness:
slight.)
- In addition to the stress-test code above, we should have some
automated
integration test code to start many servers with different
configurations
on the same server, and test them with calls to the client code. This
can
probably share a good deal of logic with the stress-test code. A nice
extra would be to allow testing multiple versions of Mixminion with
multiple versions of the client, and have multihost support.
(Difficulty:
moderate. Invasiveness: none.)
- It would be neat if all the boilerplate that servers spit out were
configurable via some kind of generic boilerplate mechanism, and
stored in
separate files. (Difficulty: easy. Invasiveness: slight.)
- We could use some way to cap total disk usage, and handle full disks
sanely.
(Difficulty: moderate. Invasiveness: moderate.)
- If you have access to a multiprocessor machine, it would be nice to
make
good use of more than one CPU. Right now, the network code runs in
parallel with the processing code, but the processing thread accounts
(I
think) for most of the CPU use. It would be nice to support multiple
processing threads and multiple network threads (round-robin, not
one-per-connection). (Difficulty: easy/moderate, depending on your
knowledge of writing multithreaded code. Invasiveness: slight.)
- We have a specification for multiple exit addresses, but it needs to
be
implemented... (Difficulty: easy. Invasiveness: slight.)
THINGS TO THINK ABOUT AND HACK: (Introductory projects that will take
some
specification work. Please, get your spec discussed on mixminion-dev
and
checked into CVS *before* you submit an implementation for any of
these!
[See spec-issues.txt for more open issues].)
- We should have an incoming email gateway for users to use reply blocks
to
send messages anonymously without using Mixminion software. (Spec
difficulty: easy. Implementation difficulty: moderate. Invasiveness:
slight.)
- Want a real challenge? We have an allusive description for how to do
K-of-N fragmentation in our E2E-spec documentation. Go flesh out the
description. (Spec difficulty: moderate. Implementation difficulty:
already implemented.)
- Right now, we never generate link padding or dummy messages. The code
is
there, but it never gets triggered. Specify when it gets triggered
(and
justify why this improves anonymity). (Spec difficulty: ????.
Implementation difficulty: easy once you know how. Invasiveness:
some.)
- We could use IPv6 support. The big specification problem here is
routing:
an IPv4-only server simply cannot deliver to a server without an IPv4
address. Any path-generation algorithm I can come up with has
troublesome
anonymity implications. If you can come up with an algorithm that
doesn't, the code should be pretty easy to do. (Spec difficulty:
????.
Implementation difficulty: easy. Invasiveness: some.)
HARD HACKING:
- Do you want to dive into Python and OpenSSL internals? Right now, we
allow
all our data to get swapped out to disk. That's no good! Now, you
_could_
install an OS that encrypts your swap, but that's not an option for
everybody. Write code to use memlock to protect sensitive data
structures
(keys, packets, etc) as necessary. [If you're feeling unsubtle, use
memlockall to keep *all* data from getting swapped out... but watch
out for
ticked-off admins!] (Difficulty: easy/hard depending on whether you
take
the easy way out with memlockall, or whether you actually do the right
thing. Invasiveness: all over the place.)
- Want a real challenge? Right now, we store sensitive files right on
the
file system, and do our best to overwrite them when they need to be
deleted... but go read the comment in Common.py to see why this
doesn't
really work. We *could* have people use encrypted filesystems.... but
that's not an option for everyone. Here's what you do: Write code
for a
generic encrypted filestore, and have Mixminion use that as
appropriate
instead of the filesystem directly. This will be easier than writing
a
real encrypted filesystem, since:
- All of the files are the same size (within a few K).
- There are no hard or soft links
- There are no attributes: no ownership, no modes, no special
files, no
atime/mtime/ctime... just name and size.
- There is no arbitrary nesting of directories; the set of
directories
is very small.
- No more than one process needs to be able to access the
filestore at
a time. (Though multiple threads might need to.)
Your code should probably be generic enough for other Python projects
to
use. :) (Difficulty: hard. Invasiveness: moderate.)
- Port the code to use NSS or libgcrypt/GNUTLS instead of/in addition to
OpenSSL. (The OpenSSL license conflicts with the GPL, and makes us
unlinkable with GPL'd code under some circumstances.) Note that NSS
does
not, today, have any support for server-side DHE; if you're going to
go
down the NSS route, you should contribute an implementation for
server-side
DHE. (Difficulty: hard. Invasiveness: moderate.)
- We should eventually port to Twisted, which looks to be an incredibly
cool
and featureful networking platform written in Python. Issues:
- I don't want to switch Twisted's favored crypto library:
PyOpenSSL.
This library, however cool, lacks a lot of symmetric cipher
functionality I need, and I really don't want to carry _two_
crypto
library dependencies. This means that we need to either bring
PyOpenSSL up to date, or change Twisted's SSL wrapper to speak
_minionlib's admittedly limited OpenSSL dialect.
- Twisted has functionality for a few things that Mixminion's
libraries
currently duplicate, such as logging. We'll need to integrate
these.
- I'd rather keep the changes one-by-one, and not have to port the
entire codebase in one step. First, we'd change the async loop,
then
change more and more of the other IO-intensive stuff to use it.
- The install process MUST NOT get hard! Requiring users to
install
Twisted beforehand could get tricky. We'll need to either make
the
Twisted install project learn all of our
Python-Python-Who's-Got-The-
Python trickery, or add a 'download and install twisted' target.
Benefits:
- Move server HTTP activity into async loop.
- Freebies like windows portability, bandwidth throttling, etc.
(Investigate more)
(Difficulty: moderate. Invasiveness: moderate.)
- We could really use a nymserver.
DESIGN PRINCIPLES:
- It's not done till it's documented.
- It's not done till it's tested.
- Don't build general-purpose functionality. Only build the
operations you need.
- "Premature optimization is the root of all evil." -Knuth
Resist the temptation to optimize until it becomes a necessity.
CODING STYLE:
- See PEP-0008: "Style Guide For Python Code". I believe in most of
it.
(http://www.python.org/peps/pep-0008.html)
- Also see PEP-0257 for documentation; we're not there yet, but it's
happening. (http://www.python.org/peps/pep-0257.html)
- Magic strings:
"XXXX" indicates a defect in the code.
"FFFF" indicates a missing feature.
"????" indicates an untested or iffy block.
"DOCDOC" indicates missing documentation.
PORTABILITY NOTES:
- I've already backported to Python 2.0. (I refuse to backport to
1.5 or
1.6.)
- Right now, we're dependent on OpenSSL. OpenSSL's license has an
old-style BSD license that isn't compatible with the GPL. We
have two other options, it seems:
- libnss: this is a dual-license GPL/MPL library from
Mozilla. Sadly, we can't use it now, because it doesn't
yet support server-side DHE. Bugzilla says that
server-side DHE is targeted for 3.5. Perhaps then we can
port, but I wouldn't hold my breath.
- gnutls/libgcrypt: These are the GNU offerings; the relevant
portions of each are licensed under the LGPL. They don't
support OAEP, but we've already got an implementation of that
in Python.
So for now, it's OpenSSL. I'll accept any patches that make us
run under gnutls/libgcrypt as well, but I think in the long term
we should migrate to libnss entirely.
CAVEATS:
- If I haven't got a test for it in tests.py, assume it doesn't
work.
- The code isn't threadsafe. It will become so only if it must.
FINDING YOUR WAY AROUND THE CODE.
- All the C code is in src/. Right now, this is just a set of thin
Python wrappers for the OpenSSL functionality we use.
- The Python code lives in lib/mixminion (for client and shared
code)
and lib/mixminion/server (for server code only). The main loop is
in lib/mixminion/server/ServerMain; the asynchronous server code
is
in lib/mixminion/server/MMTPServer.
- A message coming in to a Mixminion server takes the following
path:
Received in MMTPServer;
V
Stored in an 'Incoming' queue, implemented in ServerMain and
Queue.
V
Validated, decrypted, padded by code in PacketHandler.
V
Stored in a 'Mix' pool, implemented in ServerMain and Queue.
V
A batch of messages is selected by the 'Mix pool' for delivery.
V
---Some are placed in an 'Outgoing' queue...
I V
I ... and delivered to other Mixminion servers via
MMTPServer
V
---Others are queued and delivered by other exit methods,
implemented and selected by ModuleManager.
--Nick
(for emacs)
Local Variables:
mode:text
indent-tabs-mode:nil
fill-column:77
End:
============================================================
--
+--------------- http://www.winstonsmith.info ---------------+
| il Progetto Winston Smith: scolleghiamo il Grande Fratello |
| the Winston Smith Project: unplug the Big Brother |
| Marco A. Calamari marcoc@dada.it http:// www.marcoc.it |
| DSS/DH: 8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B |
+ PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 ----------+
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome: non disponibile
Tipo: application/pgp-signature
Dimensione: 307 bytes
Descrizione: This is a digitally signed message part
URL: <http://lists.linux.it/pipermail/flug/attachments/20040823/83f50838/attachment.pgp>
Maggiori informazioni sulla lista
flug