Re: [Hackmeeting] Aquileaks

Borrar esta mensaxe

Responder a esta mensaxe
Autor: vecna mc claudio
Data:  
Para: hackmeeting
Asunto: Re: [Hackmeeting] Aquileaks
Il giorno 22 maggio 2012 14:32, boyska <piuttosto@???> ha
scritto:

> Di aquileaks abbiamo già parlato un pochino, proviamo a chiarire meglio
> i requisiti per poi avere più chiaro cosa ci serve e cosa no.
> * la ggente deve poter mandare cose in modo anonimo
>

check, c'è


> * l'interfaccia deve essere più semplice possibile, e deve supportare
> l'upload in maniera semplice
>

check, c'e', usando jQuery FileUploader (supporta anche il resume, cosa
importante quando c'e' di mezzo Tor)


> * qualcuno deve avere accesso al materiale inviato
>        - data la "località" delle informazioni inviate, non sono
>        particolarmente necessari meccanismi di collaborazione (editing,
>        commenti) tra i revisori. Quel processo potrà avvenire offline, o
>        per altri canali.

>

I commenti sono già supportati. ogni submission ha uno spazio dedicato, i
riceventi ci accedono perchè hanno un token univoco, l'utente che ha fatto
la submission puo' tornarci (nonostante si anonimo) perché gli viene
rilasciata una ricevuta. per il tempo in cui questo spazio è valido,
potranno scambiarsi commenti, e l'utente segnalatore potrà integrare con
nuovifile.

lo chiamo spazio, se leggi il codice e/o della documentazione, troverai i
sinonimi: Tip, Tip-off (segnalazione), TULIP (temporary unique link
information provider)


>        - l'accesso al materiale inviato deve essere limitato a chi ne ha i
>        permessi.

>


per noi è: se ricevi il link, hai i permessi di download (un numero di
download limitabile), se hai la ricevuta, hai i permessi di upload. fine.
certo, il sysadmin ha la possibilità di fare il bello ed il cattivo tempo,
non c'e' protezione da lui. lui pero' si puo' proteggere, almeno, con la
disk encryption.


>
> In pratica ci serve:
> * un form di upload ben fatto
> * un meccanismo di notifica per i "revisori" (arriva un'email quando
> qualcuno manda qualcosa)
> * un interfaccia per i revisori per vedere cosa è stato inviato
>


tutti presenti


> Meccanismi di paranoia:
> * macchina che non logga niente
>


si disabilita da .conf, o si abilita per il debug


> * un hidden service per i più paranoici
>


E' creato di default


> * valutare: esporci SOLO con hiddenservice e poi fare un sito pubblico
> che faccia solo da proxy? (un po' quello che fa tor2web, ma fatto solo
> per il nostro servizio e senza doverci fidare di tor2web)
>


Possibili entrambe le cose, nel caso ci sia un accesso non Tor, servirà
avere la parte web con gli adeguati rewrite e proxy


>
> Globaleaks dovrebbe fare tutto questo (e di più), capiamo se ha dei
> difetti particolari. Altrimenti usiamo quello e via.
>


non ha statistiche, è stato auditato da un paio di conoscenze brave nel
webhacking, ma si basa su web2py e per questo non è escluso possa aver
problemi insiti.

la cosa secondo me comoda in questa fase, è che se uno ha skill
sistemistici e non di programmazione, puo' comunque aiutare sul concetto di
"script che customizza, tuna e pulisce la macchina virtuale", partendo da
una ubuntu server 11.10

inoltre, la parte di interfaccia web in questo momento ne abbiamo 3. un
template basato su web2py e sulle nostre modifiche, un template usato da un
media serbo, un template sviluppato in nonricordocosaJS.


>
>
> Ne parliamo (anche) su irc? mufhd0/#hackit99
>
> volentieri, domani