Random Bullshit

Archivi per la categoria nerdate

Crisis Management

Quando offri un servizio online può capitare di avere dei problemi (bug, DDoS, guasti hardware, router impazziti, ecc.) che precludono l'accesso al servizio a buona parte dell'utenza (se non tutta).

Ci sono almeno due modi per affrontare la comunicazione con gli utenti durante una crisi:

1. far finta di nulla;
2. ammettere che si sta verificando un problema.

Il primo modo di replicare - a mio personalissimo parere - è inutile, a meno che non si stia affrontando una crisi che potrebbe avere ripercussioni gravissime sulla sicurezza degli utenti. In quel caso, è sempre buona norma dispensare le informazioni col contagocce e spiegare solo a problema risolto.

Il secondo modo, invece, porterà inevitabilmente alla domanda da un milione di dollari:

Quando risolverete il problema?

E qui scatta a chiunque la molla del VAFFANCULOPEZZODIMERDANONMIROMPERELEPALLECHEGIAHOIMIEICASINIDARISOLVERECIMANCHISOLOTU, specialmente se il servizio è gratuito. Reazione comprensibilissima, per carità, ma che non deve durare più di 5 millisecondi e che non deve assolutamente diventare di pubblico dominio.

A mio avviso, in una situazione di crisi bisogna osservare alcune semplici regole:

• spiegare onestamente all'utenza quale problema si sta verificando e quali sono i tempi previsti per la risoluzione (se ce ne sono, altrimenti ammettere tranquillamente di non sapere quanto tempo ci vorrà);
• mordersi le dita prima di rispondere male ad un utente, anche al più insistente;
• staccarsi le dita prima di limitare l'accesso ad un utente che chiede spiegazioni (questa è in assoluto la peggior cazzata che si possa fare);
• se non si è in grado di reggere la pressione lasciare che siano altri ad occuparsi del crisis management;
• risolvere il problema nel minor tempo possibile :-)

Anomalie statistiche

Da qualche giorno finalmente sono in giro i famigerati elenchi degli affittuari degli alloggi del Fondo Immobiliare, dopo mesi di "silenzio" da parte di Comune e SGE.

Perché elenchi e non elenco? Semplice, perché Aquilatv.it ne ha pubblicato uno estratto da non-si-sa-bene-dove, con tanto di date di firma del contratto e termine di locazione, canoni di affitto ecc., mentre a stretto giro il Comune dell'Aquila ne ha pubblicato un altro in cui erano assenti molti dei dati di cui sopra.

Ovviamente, visti i miei precedenti con elenchi di beneficiari (e non) di alloggi, potevo esimermi dal rompere le scatole? Ma ovviamente no :-)

Caricando entrambi gli elenchi in Google Refine (dopo averli trasformati in CSV con pdftotext, vim e tanto olio di gomito) salta subito all'occhio una discrepanza: l'elenco del Comune ha 299 voci, mentre quello di Aquilatv ne ha 308 (escludendo duplicati e voci "anonime").

C'è un'altra cosa che salta all'occhio: nella colonna relativa alla composizione dei nuclei familiari di entrambi gli elenchi fa spesso capolino il numero 2. Potrebbe essere solo una coincidenza, quindi prima di trarre conclusioni affrettate sarebbe il caso di analizzare i dati con strumenti adeguati.

Esportando entrambi i dataset e dandoli in pasto a R si ottengono questi istogrammi relativi alla distribuzione statistica delle dimensioni dei nuclei familiari:

Fondo immobiliare - Distribuzione componenti nucleo familiare (fonte: Comune dell'Aquila)

Fondo immobiliare - Distribuzione componenti nucleo familiare (fonte: Aquilatv.it)

Che cosa si può dedurre dai grafici?

Innanzi tutto, entrambi gli elenchi hanno la stessa distribuzione statistica, quindi i dati di Aquilatv.it sono reali. Nello specifico, i nuclei familiari con due componenti rappresentano oltre il 40% dei beneficiari degli alloggi del Fondo Immobiliare, seguiti a ruota da persone singole e nuclei di 4 componenti.

Non ci sarebbe nulla di strano in tutto questo, se non fosse che (cito testualmente il comunicato stampa del Commissario delegato per la Ricostruzione - l'enfasi è già presente nel documento originale):

– I nuclei familiari numerosi – da quattro componenti in su – potranno chiedere l’assegnazione di un map disponibile sia nel comune dell’Aquila che in quelli dell’intero cratere, o di un alloggio del fondo immobiliare, anche se avevano espresso la preferenza per il contributo di autonoma sistemazione nel censimento dello scorso agosto.

(Per i curiosi, qui potete trovare la sessione di R utilizzata per produrre i grafici.)

Pretendo i diritti d'autore!

Il primo aprile ho scritto una mail vagamente surreale in mailing list amministrativa di Azzurra, annunciando un improbabile passaggio ad un ircd basato su .NET/WCF.

Beh, sappiate che pretendo i diritti d'autore.

Lenza, amo, esca e... PESCI!

Visto che su Azzurra non si faceva più un pesce d'aprile come si deve all'utenza da anni, ho deciso di farne uno io ai miei "colleghi" inviando una mail un tantino improbabile in mailing list amministrativa:

Date: Fri, 01 Apr 2011 18:56:55 +0200
From: Matteo 'morph' Panella <...@azzurra.org>
To: <OMISSIS>
Subject: Nuovo software di rete

Salve lista.

Dati i recenti sviluppi e le positive esperienze raccolte sul campo da un'altra
rete irc italiana, ho il piacere di annunciarvi le specifiche tecniche del
nuovo ircd e dei nuovi services.

Il linguaggio scelto è C# e il runtime .NET/Mono (in modo tale da permettere il
ritorno di server basati su Windows e quindi maggiori opportunità di link).
ircd.conf sarà sostituito da un comodo file XML per la configurazione, mentre
per il protocollo server-to-server verrà utilizzato Windows Communication
Framework per non reinventare la ruota e ridurre i tempi di sviluppo.

I services saranno integrati in uno degli ircd e utilizzeranno MongoDB come
backend.

Per quanto riguarda le feature visibili agli utenti, sono in programma le
più richieste, ovvero:
 a) protect/owner
 b) vhost
 c) notifica in caso di whois estesa a tutti gli utenti
 d) botserv

Lo sviluppo verrà condotto in maniera totalmente chiusa (per adeguarci al
modello tipico di .NET) fino al completamento della prima release stabile e
alla sua messa in rete. Salvo complicazioni, la data per il deploy del nuovo
stack di rete ed il rilascio dei sorgenti è fissata al 21 dicembre 2012.

Sono sicuro di avere la vostra totale approvazione.

Saluti,
--
Matteo 'morph' Panella
Azzurra IRC Network

"Java is a DSL for converting large XML files into stack traces"
  --Someone on Twitter
"Java. Write Once; Hog 80% of CPU Everywhere."
  --Merlin Mann

Pesce #1 - Raynk:

[19:07:02] <@rnk> morph, ma avevi già pensato a un ircd da cui partire?
[19:07:17] <@rnk> (in merito alla mail sul nuovo software)

Pesce #2 - CYbER:

[19:31:36] <@CYbER> morph ma è un pesce d'aprile???
[19:32:17] <@CYbER> ma li mortacci tua mi hai fatto prendere un colpo!

Pesce #3 - IRC Operator anonimo (mail privata):

Date: Fri, 1 Apr 2011 19:34:29 +0200
From: <OMISSIS>
To: Matteo 'morph' Panella <...@azzurra.org>
Subject: Re: Nuovo software di rete

mi hai fatto prendere un colpo :P

Che dire? Buon primo aprile, pesciolini :D

Migrate this

After reading a lot of confusing and conflicting statements on the status of OpenVZ in Debian, I finally found out that both linux-vserver *AND* OpenVZ are deprecated and may not even make it for squeeze+1. I can live without linux-vserver since I won't touch that thing with a pole, but OpenVZ has been my choice for container-based virtualization.

The migration path is replacing OpenVZ with virtualization solutions merged with mainline, and it looks really awful:

• Xen: overhead, overhead, overhead. I want a container-based solution, not an hypervisor;
• KVM: same as before, plus my server doesn't support VT-x/SVM;
• LXC: COME THE FUCK ON, the userspace doesn't support squeeze guests on squeeze, it is not even near to production quality and you can't really control memory usage of each container - unless you rebuild a kernel (what??) with memory cgroup enabled, which means a lot of CPU-time overhead for each memory access (WHAT THE FUCK!?!?!?!).

To summarize, my only option would be migrating from a proven and working solution (OpenVZ) to a virtualization system with an incomplete and buggy userspace and with a reduced kernel feature set because it would negatively impact performance on the whole system, only because it is not merged with mainline.

Guess what? If squeeze+1 (or wheezy) dumps OpenVZ, I'll dump Debian - better yet, Linux altogether.

FreeBSD, anyone?

RFC 4226 implementation in Python

Straight from RFC 4226, Appendix C:

import hmac
import hashlib
import struct

# Copyright (C) 2011, Matteo Panella. All rights reserved.
#
# This software is licensed under the same terms as the original
# Java reference code in RFC 4226.
#
# This is a work derived from OATH HOTP Algorithm.
#
# The author makes no representations concerning either
# the merchantability of this software or the suitability of this
# software for any particular purpose.
#
# It is provided "as is" without express or implied warranty
# of any kind and THE AUTHOR EXPRESSLY DISCLAIMS ANY
# WARRANTY OR LIABILITY OF ANY KIND relating to this software.
#
# These notices must be retained in any copies of any part of this
# documentation and/or software.

# Copyright notice for original Java code:
# Copyright (C) 2004, OATH.  All rights reserved.
#
# License to copy and use this software is granted provided that it
# is identified as the "OATH HOTP Algorithm" in all material
# mentioning or referencing this software or this function.
#
# License is also granted to make and use derivative works provided
# that such works are identified as
#  "derived from OATH HOTP algorithm"
# in all material mentioning or referencing the derived work.
#
# OATH (Open AuTHentication) and its members make no
# representations concerning either the merchantability of this
# software or the suitability of this software for any particular
# purpose.
#
# It is provided "as is" without express or implied warranty
# of any kind and OATH AND ITS MEMBERS EXPRESSaLY DISCLAIMS
# ANY WARRANTY OR LIABILITY OF ANY KIND relating to this software.
#
# These notices must be retained in any copies of any part of this
# documentation and/or software.

__all__ = ['hotp']

# Checksum algorithm defined in RFC4226
_doubleDigits = (0, 2, 4, 6, 8, 1, 3, 5, 7, 9)
def _calcChecksum(num, digits):
    doubleDigit = True
    total = 0
    while digits > 0:
        digits -= 1
        digit = num % 10
        num /= 10
        if doubleDigit:
            digit = _doubleDigits[digit]
        total += digit
        doubleDigit = not doubleDigit
    result = total % 10
    if result > 0:
        result = 10 - result
    return result

def hotp(secret, movingFactor, codeDigits=6, addChecksum=False, truncationOffset=None):
    """
    Perform RFC4226 HOTP generation from given secret (shared secret) and movingFactor.

    secret: the shared secret
    movingFactor: a counter, current time or other value that changes on a per-use basis (64 bit integer)
    codeDigits: number of digits in the OTP, not including the checksum (if any)
    addChecksum: True if a checksum digit should be appended to the OTP, False otherwise (default: False)
    truncationOffset: the offset into the MAC output to begin truncation. If this value is out of the
                      range 0 .. 15 or is None, then dynamic truncation will be used.
    Returns a numeric string in base 10 (the OTP).

    Test vectors (RFC4226, Appendix D):
    >>> hotp("12345678901234567890", 0)
    '755224'
    >>> hotp("12345678901234567890", 1)
    '287082'
    >>> hotp("12345678901234567890", 2)
    '359152'
    >>> hotp("12345678901234567890", 3)
    '969429'
    >>> hotp("12345678901234567890", 4)
    '338314'
    >>> hotp("12345678901234567890", 5)
    '254676'
    >>> hotp("12345678901234567890", 6)
    '287922'
    >>> hotp("12345678901234567890", 7)
    '162583'
    >>> hotp("12345678901234567890", 8)
    '399871'
    >>> hotp("12345678901234567890", 9)
    '520489'
    """
    digits = codeDigits + 1 if addChecksum else codeDigits
    movingFactor = struct.pack('!q', movingFactor)
    hs = hmac.new(secret, movingFactor, hashlib.sha1).digest()
    if truncationOffset is None or truncationOffset < 0 or truncationOffset > 15:
        # Perform dynamic truncation (per RFC4226)
        # The offset is taken from the lowest 4 bits of hs[19]
        truncationOffset = ord(hs[19]) & 0xf

    # Starting from the offset, 4 bytes are extracted and converted to an
    # unsigned 32 bit integer (big endian) and then masked with 7fffffff
    bin_code = struct.unpack('!I', hs[truncationOffset:truncationOffset+4])[0] & 0x7fffffff
    # OTP is the value modulo 10^codeDigits
    otp = bin_code % 10**codeDigits
    if addChecksum:
        otp = (otp * 10) + _calcChecksum(otp, codeDigits)
    result = '%d' % (otp,)
    return '0' * (len(result) - digits) + result

Dear macports gnome-doc-utils maintainers...

variant python25 conflicts python26 python27 description {Use python 2.5} {
    depends_lib-append     port:python25 port:py25-libxml2
    configure.args-append  am_cv_python_pythondir=${frameworks_dir}/Python.framework/Versions/2.5/lib/python2.5/site-packages/
    configure.python       ${prefix}/bin/python2.5
}

variant python26 conflicts python25 python27 description {Use python 2.6} {
    depends_lib-append     port:python26 port:py26-libxml2
    configure.args-append  am_cv_python_pythondir=${frameworks_dir}/Python.framework/Versions/2.6/lib/python2.6/site-packages/
    configure.python       ${prefix}/bin/python2.6
}

variant python27 conflicts python25 python26 description {Use python 2.7} {
    depends_lib-append     port:python27 port:py27-libxml2
    configure.args-append  am_cv_python_pythondir=${frameworks_dir}/Python.framework/Versions/2.7/lib/python2.7/site-packages/
    configure.python       ${prefix}/bin/python2.7
}

if {![variant_isset python25] && ![variant_isset python26]} {
    default_variants +python27
}

Is it so fucking difficult?

Happy PI day

$$ \pi = \sum_{k = 0}^{\infty}\frac{1}{16^k} \left(\frac{4}{8k + 1} - \frac{2}{8k + 4} - \frac{1}{8k + 5} - \frac{1}{8k + 6}\right) $$

Happy PI day, everyone!

Debian squeeze: fuckup non documentati

Durante l'aggiornamento da lenny a squeeze, tenete presente quanto segue (e che non è presente nella documentazione):

• quando installate il nuovo kernel fate attenzione ai warning sul firmware, se ve ne spunta uno abilitate subito la sezione non-free, installate il pacchetto necessario (non è sempre firmware-linux-nonfree) e date un bel dpkg-reconfigure linux-image-vostra-versione per forzare il rebuild di initramfs prima di rebootare;
• se usate PostGIS, l'unica maniera sana di mente per migrare da PostgreSQL 8.3 a 8.4 è effettuare un dump e restore dei db, non provate neanche ad usare pg_upgradecluster perché non funzionerà;
• per default, mysql-server-5.0 verrà sostituito da mysql-server-core-5.1 che non è sufficiente per far girare il DBMS, quindi alla fine dell'aggiornamento avviate aptitude, selezionate mysql-server-5.1 e risolvete tutti i conflitti.

Epic math fail

Prendiamo l'esempio canonico di una firma ECDSA:

$$ \begin{aligned} r &= (k G)_x&\pmod n \\ s &= k^{-1}(z + r d_A)&\pmod n \end{aligned} $$

Un avversario conosce tutti i parametri, ad eccezione della chiave privata \( d_A \) e del parametro random \( k \).

In teoria, ogni firma è un sistema di due equazioni con due incognite, ma la prima equazione non è per niente facile da risolvere, quindi il sistema è sicuro - a patto che il parametro random non sia prevedibile o derivabile in alcun modo.

Mettiamo ora il caso di avere davanti due firme ECDSA \( (r_1, s_1) \) e \( (r_2, s_2) \) generate con la stessa chiave privata (a noi ignota) tali che \( r_1 = r_2 \). Questo significa che:

$$ \begin{aligned} (k_1 G)_x &\equiv (k_2 G)_x &\pod n \\ k_1 &\equiv k_2 &\pod n \end{aligned} $$

Ouch: il parametro random non è né random né imprevedibile, bensì è identico per entrambe le firme. Non sappiamo ancora il suo valore, ma possiamo tranquillamente calcolarlo attaccando \( s_1 \) e \( s_2 \) (ricordate: la parte computazionalmente ardua del problema è invertire la moltiplicazione scalare tra il parametro random e il punto generatore!):

$$ \begin{aligned} s_1 - s_2 &= k^{-1}(z_1 + r d_A) - k^{-1}(z_2 + r d_A) &\pmod n \\ s_1 - s_2 &= k^{-1}(z_1 - z_2) &\pmod n \\ k &= (s_1 - s_2)^{-1}(z_1 - z_2) &\pmod n \end{aligned} $$

Uh-oh... improvvisamente l'incognita è una sola: \( d_A \), ovvero la chiave privata usata per generare la firma.

A questo punto, non ci resta che inserire il valore appena calcolato in una delle due equazioni relative a \( s \) e risolvendola rispetto a \( d_A \):

$$ \begin{aligned} s_i &= k^{-1}(z_i + r d_A) &\pmod n \\ s_i k &= z_i + r d_A &\pmod n \\ s_i k - z_i &= r d_A &\pmod n \\ d_A &= r^{-1}(s_i k - z_i) &\pmod n \\ d_A &= (r(s_1 - s_2))^{-1}(z_1 s_2 - z_2 s_1) &\pmod n \end{aligned} $$

Lo so, state pensando: "belle seghe mentali, nessuno è così stupido da usare due volte lo stesso parametro random".

In effetti è vero, nessuno l'ha usato solo due volte, ma c'è chi l'ha usato per ogni singola firma generata: $REDACTED

EDIT: ho rimosso il nome e il link di chi ha fatto la pirlata in questione visto che tira aria di citazioni in giudizio. E' stato presentato al 27C3 e riguarda una console, Google è vostro amico.

Yet another switch

Stavolta da lighttpd a nginx. Appena ho 5 minuti di tempo posto un po' di dettagli.

IRC, fiducia e OpenSource

Tanto tempo fa, quando si parlava di Azzurra andava di moda dire "quelli loggano tutto". Ovviamente, per una rete (all'epoca) con 10000 utenti la cosa era pressoché impossibile, ma il mito resisteva. Anzi, uscì rafforzato quando qualche anno dopo uno degli autori dell'ircd (il buon Marcello Barnaba) parlò ad un suo amico dello spamfilter e del "famigerato" snow.azzurra.org.

Ammetto di essermi preoccupato un po' anche io, anche perché la descrizione che ne faceva Marcello era un po' allarmistica. Di lì a poco, però, qualcuno (e sia chiaro: non fu Marcello - no, non dirò manco sotto tortura chi è stato :-P ) pubblicò sull'ormai defunto sorciazzurra.altervista.org un bel tgz con tutto il repository SVN di Azzurra.

Tralasciando il (ridicolo) tentativo di metterci una pezza pubblicando sorgenti ufficiali ma non aggiornati di ircd e services, il leak mi permise di verificare in prima persona cosa era 'sto benedetto spamfilter, come funzionava e se loggava qualcosa. (e incidentalmente, anche di verificare che l'algoritmo di cloak degli host è fatto come si deve e non usa porcate facilmente attaccabili con Google Code Search, un po' di aritmetica modulo 2 e un pizzico di bruteforce, ma questa è un'altra storia)

Recentemente, un gruppo di utenti storici di Azzurra ha deciso di "mettersi in proprio", sviluppare da zero un ircd integrato coi loro siti e dare vita ad una micro rete IRC monoserver. Tralasciando l'aspetto tecnico del risultato (hint: RPL_ISUPPORT non è qualcosa che potete omettere senza creare problemi ai client), la cosa che mi ha colpito è la scelta di tenere gelosamente riservato il codice dell'ircd. Per carità, possono esserci miliardi di motivi (magari è pieno di password hardcoded per le varie backend o l'algoritmo di cloak degli host funziona tramite una buona dose di security through obscurity, chi lo sa), ma la cosa comunque non ispira fiducia.

Tant'è che già ha cominciato a girare il famigerato "quelli loggano tutto" :-)

A volte ritornano

Avevo solennemente annunciato la morte per vecchiaia del fork di Bahamut di Azzurra IRC Network e dei relativi Services, ma a quanto pare non avevo tenuto conto di due noiosissimi metodi per rompere i coglioni via IPv6.

E così, mi tocca fare gli straordinari (a onor del vero, la parte più rognosa se l'è sbrogliata Sonic :P).

Sadismo

Sto leggendo con un certo piacere sadico i post delle persone che s'incazzano per il recente botto di uno degli storage di Tophost.

Perché piacere sadico? Perché il 99.9999% delle lamentele proviene da persone che non hanno MAI effettuato un backup del proprio sito e il restante 0.0001% da persone che pretendono di ottenere con €8.99+IVA all'anno anche un backup giornaliero. Magari su Tivoli Storage Manager¹, già che ci siamo.

¹ Seeweb fa pagare un backup bisettimanale su TSM €475+IVA all'anno per una singola macchina. Non so quante macchine abbia Tophost per i clienti, ma ho come la sensazione che i costi complessivi siano proibitivi rispetto ai loro prezzi (senza contare che il ripristino di un singolo sito da un backup su TSM è un po', come dire... complesso).

Fuckup of the day

La nuova versione di BootCamp include un driver HFS+ per Windows. Siccome ho moderatamente paura di lasciar accedere tale accozzaglia di bug (Windows, ovviamente) al mirror della partizione OSX principale ho pensato "bene" di rimuovere la lettera di unità alla partizione.

Ecco, non fatelo, perché quella fetenzia per andare sul sicuro cambierà il tipo della partizione da Apple HFS/HFS+ a Microsoft Basic Data e ripristinare il tipo corretto è molto, molto, molto complicato (a meno di non usare cose come gptfdisk, ma non lo consiglio ai deboli di cuore).