[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

    - Send them to the list mixminion-dev@freehaven.net, or to me
    - 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.)


- 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
  are two ideas.)

THINGS TO HACK:  (Good introductory projects that I won't get to myself
  at least a version or two.)

- We need some distributed stress-test code.  Ideally, it should use SSH
  build Mixminion on a number of machines and start servers on those
  machines, then run a bunch of clients to send messages through the
  It should be possible to run the code with different network and
  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:
  Invasiveness: slight.)

- The current implementation for the MBOX and SMTP modules do not
  ESMTP (over TLS).  They should.  (Difficulty: easy.  Invasiveness:

- In addition to the stress-test code above, we should have some
  integration test code to start many servers with different
  on the same server, and test them with calls to the client code.  This
  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.
  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
  (Difficulty: moderate.  Invasiveness: moderate.)

- If you have access to a multiprocessor machine, it would be nice to
  good use of more than one CPU.  Right now, the network code runs in
  parallel with the processing code, but the processing thread accounts
  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
  implemented... (Difficulty: easy.  Invasiveness: slight.)

THINGS TO THINK ABOUT AND HACK: (Introductory projects that will take
  specification work.  Please, get your spec discussed on mixminion-dev
  checked into CVS *before* you submit an implementation for any of

  [See spec-issues.txt for more open issues].)

- We should have an incoming email gateway for users to use reply blocks
  send messages anonymously without using Mixminion software.  (Spec
  difficulty: easy. Implementation difficulty: moderate.  Invasiveness:

- 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
  there, but it never gets triggered.  Specify when it gets triggered
  justify why this improves anonymity).  (Spec difficulty: ????.
  Implementation difficulty: easy once you know how.  Invasiveness:

- We could use IPv6 support.  The big specification problem here is
  an IPv4-only server simply cannot deliver to a server without an IPv4
  address.  Any path-generation algorithm I can come up with has
  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.)


- Do you want to dive into Python and OpenSSL internals?  Right now, we
  all our data to get swapped out to disk.  That's no good!  Now, you
  install an OS that encrypts your swap, but that's not an option for
  everybody.  Write code to use memlock to protect sensitive data
  (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
  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
  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
  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
  instead of the filesystem directly.  This will be easier than writing
  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
        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
  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
  not, today, have any support for server-side DHE;  if you're going to
  down the NSS route, you should contribute an implementation for
  DHE.  (Difficulty: hard.  Invasiveness: moderate.)

- We should eventually port to Twisted, which looks to be an incredibly
  and featureful networking platform written in Python.  Issues:
      - I don't want to switch Twisted's favored crypto library:
        This library, however cool, lacks a lot of symmetric cipher
        functionality I need, and I really don't want to carry _two_
        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
        currently duplicate, such as logging.  We'll need to integrate
      - 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,
        change more and more of the other IO-intensive stuff to use it.
      - The install process MUST NOT get hard!  Requiring users to
        Twisted beforehand could get tricky.  We'll need to either make
        Twisted install project learn all of our
        Python trickery, or add a 'download and install twisted' target.
      - 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.

    - 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.

    - See PEP-0008: "Style Guide For Python Code".  I believe in most of
    - 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.

    - I've already backported to Python 2.0.  (I refuse to backport to
1.5 or
    - 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.

    - If I haven't got a test for it in tests.py, assume it doesn't
    - The code isn't threadsafe.  It will become so only if it must.

    - 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
      and lib/mixminion/server (for server code only).  The main loop is
      in lib/mixminion/server/ServerMain; the asynchronous server code
      in lib/mixminion/server/MMTPServer.
    - A message coming in to a Mixminion server takes the following

        Received in MMTPServer;
           Stored in an 'Incoming' queue, implemented in ServerMain and
        Validated, decrypted, padded by code in PacketHandler.
           Stored in a 'Mix' pool, implemented in ServerMain and Queue.
        A batch of messages is selected by the 'Mix pool' for delivery.
              ---Some are placed in an 'Outgoing' queue...
              I       V
              I   ... and delivered to other Mixminion servers via
              ---Others are queued and delivered by other exit methods,
                 implemented and selected by ModuleManager.


(for emacs)
  Local Variables:



+--------------- 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