Sábado 25 de marzo de 2017

Linux Adictos: Huawei usará SUSE Linux para sus servidores

Viernes 24 de marzo de 2017

Usemos Linux: Selene Media Encoder: Un sencillo convertidor de audio y vídeo para Linux
Linux Adictos: Ubuntu MATE 17.04 vendrá con MATE 1.18
Javier Smaldone

Javier Smaldone
Blog de Javier Smaldone

Vot no

Artículo de Nicolás D’Ippolito incluido en el libro Voto electrónico, una solución en busca de problemas.

Nicolás D'Ippolito

Hablemos de las elecciones. Hablemos de la boleta única electrónica.

Sin preámbulos ni entrada en calor, hablemos de la posibilidad de que alguien pueda manipular las máquinas que usaríamos para votar. Podemos empezar por prestar atención al siguiente fragmento de código:

[…]
  read_unlock(&tasklist_lock);
  if (flag) {
    retval = 0;
    if (options & WNOHANG)
      goto end_wait4;
    retval = -ERESTARTSYS;
    if (signal_pending(current))
      goto end_wait4;
    schedule();
    goto repeat;
  }
if ((options == (__WCLONE|__WALL)) && (current->uid == 0))
  retval = -EINVAL;
else
  retval = -ECHILD;
end_wait4:
  current->state = TASK_RUNNING;
  remove_wait_queue(&current->wait_chldexit,&wait);
  return retval;
}

Es importante verlo detenidamente, sé que parece tedioso pero vale la pena el esfuerzo. Acá va de nuevo:

[…]
  read_unlock(&tasklist_lock);
  if (flag) {
    retval = 0;
    if (options & WNOHANG)
      goto end_wait4;
    retval = -ERESTARTSYS;
    if (signal_pending(current))
      goto end_wait4;
    schedule();
    goto repeat;
  }
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
  retval = -EINVAL;
else
  retval = -ECHILD;
end_wait4:
  current->state = TASK_RUNNING;
  remove_wait_queue(&current->wait_chldexit,&wait);
  return retval;
}

¿Qué es lo importante de este código? Que no es uno, son dos distintos, con una pequeña diferencia: uno de ellos tiene un signo ‘=’ de menos. Es la única diferencia, dos miserables rayitas, pero con una implicancia no menor: si el segundo estuviese corriendo en una computadora, esta podría ser hackeada con facilidad. Se trata de un caso real del año 2003, de código que se encuentra en la parte central del sistema operativo Linux.2 La diferencia entre la versión correcta y la que te hace sonar es tan sutil que es muy difícil de detectar, incluso por expertos (para ser riguroso, este caso se detectó con facilidad porque se trató de una modificación a un código ya existente y hay herramientas que muestran solo aquellas líneas que cambiaron, que en este caso eran solo dos, cuando hay que auditar una pieza de software desde cero no se cuenta con esa ventaja).

Me adelanto a la objeción: si fuera tan difícil, ¿cómo saben las empresas que venden software que sus productos no tienen fallas? La respuesta es muy sencilla: no lo saben. Y no se trata de que en su ansia desmedida por apropiarse de la renta saquen productos a medio cocinar. Bueno, a veces un poquito sí, pero hay dificultades mucho más de fondo.

Seguro es el que probó y confió

Ahora, podríamos probar con probar, ¿no? Es decir, si uno quiere saber si una pieza de software falla en algún caso, puede probarla y con eso alcanza, ¿no? No, la verdad es que con probar no alcanza. El testing es la disciplina informática encargada de probar una pieza de software buscando incrementar la confianza que se tiene en que opera como debe. Funciona así: uno prepara una batería de casos de prueba, que son descripciones paso a paso de qué hacer con el sistema, y compara el resultado obtenido con el esperado. Si no son iguales, acabamos de encontrar un defecto (lo que coloquialmente se llama ‘un bug’).

Por otro lado, si sí lo son, la única garantía que tenemos es que esa interacción (y no otra, y mucho menos todas) funcionó bien la vez que la probamos, pero tampoco es que estamos tan seguros. Aun si corremos otra vez exactamente la misma secuencia, este segundo intento podría fallar porque no sabemos si el programa en cuestión tiene en cuenta alguna ‘variable invisible’, como por ejemplo la hora de la computadora, y entonces se comporta de una forma cuando esa variable es una (digamos, a las 9:13 de un martes), y de forma distinta en otra (por ejemplo, a las 4:12 de la madrugada del sábado). El que no se comporte distinto a las 4:12 del sábado, que tire la primera piedra.

Aun si tuviésemos el código y pudiésemos mirar todas las variables involucradas, las alternativas crecen exponencialmente y los caminos posibles a probar son millones de millones. Es decir, el testing es un paso fundamental para asegurar la calidad del software, y cuando encuentra un defecto, hay que arreglarlo; pero el testing nunca puede asegurar la ausencia de defectos.

Existen métodos automáticos que también ayudan a aumentar la confianza en que el software funcione como se espera. Algunos son muy buenos, pero tampoco son infalibles. La cosa se complica aún más si estamos haciendo testing de seguridad, ya que en ese caso el comportarse correctamente implica que no solo haga lo que tiene que hacer, sino que no haga nada ‘extra’. Un ejemplo puede ser el caso del acceso a un home banking: no solo debe dejarme entrar solamente con la contraseña correcta, sino que siempre debe transportarla por la red de manera encriptada y un largo etcétera de requisitos que hacen a la fortaleza y seguridad del sistema.

Pero hay más: no solo debe cumplir con estos requisitos, sino que no debe tener ningún tipo de agujero de seguridad, de esos que aprovechan los virus y los hackers para subvertir un sistema y hacer que sucedan cosas no contempladas. En un sistema informático, es muy, muy difícil encontrar fallas sutiles (a modo de ejemplo, un bug de seguridad en un software de código abierto muy usado estuvo presente 20 años hasta que fue hallado u otro que se detectó hace pocos días y estuvo latente por 11 años y presente en las máquinas con las que se votó en la CABA), y ni hablar de aquellas que son introducidas a propósito con la intención de que no puedan hallarse. Valga como ejemplo el bug introducido intencionalmente en el año 2006 en la especificación de (prepárense que parece chino lo que sigue, pero es algo importante) el generador de números al azar ‘Dual_EC_DBRG’, que es una parte central de muchos algoritmos criptográficos. Posteriormente, varios fabricantes implementaron el estándar viciado en sus productos y por ende muchísima información sensible que debía ser protegida por mecanismos criptográficos quedaba al desnudo para el autor del bug, que muchos sospechan que se trataba de la NSA. El incidente recién salió a la luz pública en el año 2013.

Algo que sabemos hace mucho en el mundo del software es que uno no puede tener garantías de que no hay fallas, y a lo que debe apuntar es a tener un muy alto nivel de confianza en que el sistema en cuestión funcione como se espera.

¿Qué tan grave es que falle el software? Bueno, si falla Tinder, tal vez nuestros genes no se propaguen (quién te dice, terminamos haciendo un bien a la humanidad). Ahora, si falla un marcapasos, uno pensaría que es bastante más grave. Pero, ¿y si el software altera o permite alterar un resultado electoral? Como el marcapasos, pero de escala país. A eso se lo conoce como la criticidad, es decir, qué tan graves son las consecuencias de que falle un sistema.

Cuando se trata de software crítico a lo que debe apuntarse es a hacer nuestro mejor esfuerzo para disminuir la chance de que ese software tenga fallas. Cabría preguntarse por qué se usa software en esos casos si no puede garantizarse que sea seguro. La respuesta es simple: porque las otras alternativas que podrían cumplir las mismas funciones o bien no existen o también pueden fallar.

Tener un alto grado de confianza en un sistema tan crítico como el que interviene en una elección requiere de mucho tiempo de trabajo por parte de un grupo de expertos, que utilizará técnicas como inspección ocular, revisión entre pares, testing, análisis estático y dinámico de código, penetration testing (no relacionado con Tinder) y un largo etcétera durante un periodo prolongado de tiempo. Los hallazgos de ese trabajo realimentarán el proceso de diseño y programación del sistema, y el proceso de prueba deberá recomenzar. Pero, ¿qué pasa en el caso de una elección? ¿Es posible que todos estos controles no sean suficientes? Sí.

Para nosotros que lo miramos por TV

Para entender por qué, imaginemos el próximo proceso electoral de nuestro país: una compra así de grande debe hacerse por licitación, supongamos que se hace mañana, que procede sin dificultades y se evalúa en tiempo récord.

[Pausa para recuperarse de la risa]

El 1° de enero de 2017 la empresa concesionaria termina por completo de desarrollar los sistemas que intervendrán en la elección, los prueba, los analiza y determina que funcionan correctamente. No estamos hablando de desarrollar una app chiquita; se trata de un sistema muy grande, que incluye mucho código desarrollado por la propia empresa, mucho código desarrollado por terceros, e incluso un sistema operativo o parte de él (que puede tener fallas como las que describimos al comienzo del artículo). Todas y cada una de esas partes deben chequearse profundamente porque funcionan de manera encadenada y el resultado final puede alterarse en cualquiera de ellas. En definitiva, el sistema entero es tan fuerte como la parte más débil de la cadena.

Ese 1° de enero, ya curada la resaca, expertos de todos los partidos se reúnen y analizan el sistema utilizando todas las técnicas que mencionamos anteriormente. El sistema completo a probar es muy complejo, dado que contiene hardware (lo que se puede patear) y software (lo que solo se puede putear), así que les toma 6 meses. Menos tiempo, no es realista; más tiempo, se dificulta llegar a agosto con las máquinas repartidas por los más de 3 millones de km cuadrados de nuestro territorio. Entonces se juntan y en un éxtasis de felicidad brindan porque todas las fallas que fueron encontrando se fueron arreglando (lo cual solo significa que no encontraron más fallas, no que no existan).

La primera pregunta es: ¿cómo saben que todos auditaron el mismo sistema? Eso es fácil de resolver con el software porque uno puede calcular una firma digital del código del sistema, y si las firmas coinciden es que auditaron el mismo software. ¿Y el hardware? Bueno, no existe tal cosa como la firma digital del hardware, así que realmente no hay forma de saber que probaron con el mismo hardware, y eso es importante porque lo que determina qué va a pasar es la combinación de hardware y software. Y sí, se pueden poner “virus” por hardware.

Pero supongamos que decidimos pasar por alto ese “detalle” y, en un acto de fe ciega, suponemos que todas las computadoras que se van a usar en la elección fueron bendecidas por Santo Tomás de los Pines en persona y por ende suponemos que el hardware simplemente ejecuta el software en forma fiel, sin interferir con su funcionamiento (insisto con esto: en un acto de fe). ¿Cómo sabemos que el software que se va a ejecutar es el que fue auditado? Deberían reunirse todos, todos, todos, frente a otra de esas computadoras bendecidas y compilarlo ahí mismo (compilar es el proceso por el que se pasa de un texto escrito en un lenguaje de programación a esa secuencia de ceros y unos llamada código de máquina, que es lo único que “entiende” una computadora realmente). De nuevo, necesitamos otro acto de fe para ignorar el artículo de Ken Thompson, laureado en 1984 con el Premio Turing (aka “el Nobel de la Computación”), llamado “Reflections on Trusting Trust”, que explica cómo el propio compilador puede ser saboteado para, a partir de un programa sin problemas, producir código de máquina malicioso.3

Supongamos que también ignoramos eso, así como el trabajo posterior que lo muestra en la práctica. Tenemos nuestro código de máquina compilado delante de todos, que suponemos que no tiene trampas. Calculamos una firma digital de ese código de máquina y se la pasamos a todos nuestros fiscales. Y ojo acá, que cabe recordar que ya venimos acumulando dos actos de fe, uno por el hardware, otro por el compilador.

Llega el día de la elección, viene el empleado del correo con una de esas máquinas que por acto(s) de fe suponemos que no tienen problemas. Trae también su CD o pendrive con el código de máquina que es lo que define qué pasará realmente con ella, y cada uno de los fiscales partidarios chequea con su computadora (que tienen, porque la VAN a necesitar, así que asumimos que hay una computadora para CADA fiscal) si la firma digital de ese CD o pendrive coincide con el que fue compilado delante de todos. Esto es absolutamente indispensable, porque si los fiscales no pueden corroborar individualmente que el software que se instala en cada máquina es el auditado, no solo existe la posibilidad real de que se instale otro, sino que además se deja abierta una puerta para que cualquiera disconforme con el resultado lo atribuya a una adulteración y tenga un punto muy fuerte a su favor.

Todo esto supone además que no hay que hacer ninguna modificación de último momento (como que la justicia autorice algún cambio en las listas o en la forma de presentarlas, algo que es muy usual), porque habría que repetir todo el proceso de nuevo, ya que cambia el código fuente, el código de máquina y la firma digital.

Nada puede malir sal

¿Qué podría pasar si las máquinas de votación estuvieran “comprometidas”? La verdad, de todo. Recordemos que, en el formato ‘boleta electrónica’, el ciudadano elige a sus candidatos y la máquina debe grabar su elección de forma digital y además imprimirlo en formato legible. Una máquina comprometida o adulterada podría imprimir al candidato A en letras y grabar digitalmente al B.

No tiene que hacerlo siempre, que sería muy obvio, puede hacerlo en una cantidad estadísticamente pequeña de casos, lo suficiente como para asignarle una banca de más o de menos a algún partido, o definir un ballotage muy parejo para una presidencia (pongámosle un 51 a 49 hipotético, o recordemos también el referéndum en Colombia4 donde el No ganó con 50,2% de los votos).

Si de variaciones estadísticas se trata, también podría pasar que el orden al azar en el que aparecen los candidatos no sea tan al azar, dándole prevalencia a alguno. No vamos a hacer un listado exhaustivo, pero analicemos un poco más.

Unos investigadores independientes reportaron un defecto en el sistema usado en la CABA para las elecciones para Jefe de Gobierno de 2015: permitía cargar varios votos a la vez, algo que ninguna de las auditorías oficiales había notado.5 Otro investigador descubrió un manejo poco seguro del mecanismo de encriptación utilizado, lo que permitía que cualquiera mandara al centro de cómputos resultados como si fuesen oficiales. Lo reportó antes de las elecciones y por supuesto que fue automáticamente respetado y tratado con cuidado… O no: fue allanado y enfrentó un proceso judicial que duró casi un año6 (así como al pasar, durante ese proceso se determinó que los servidores de la empresa que brindó el servicio habían sido hackeados), con altos costos, hasta que finalmente la justicia determinó que no había cometido ningún delito (y hasta que había dado una genuina mano identificando los problemas). Porque si hay algo que querés cuando reportás un bug en un sistema público crítico es que te traten como un peligroso delincuente y te secuestren todos los aparatos electrónicos, incluyendo compu, laptop, Kindle, y una licuadora que parece que miraba fijo a uno de los gendarmes.

Pero, si es electrónico, tiene que ser fantástico

Una objeción que se escucha con frecuencia es que está previsto el escrutinio manual. Analicemos esta posibilidad basándonos en los datos duros del informe final de la Defensoría del Pueblo de la CABA sobre la elección para Jefe de Gobierno de 2015. Según este informe, “una vez cerrada la mesa, el 83,9% de los presidentes pudo realizar el escrutinio sin inconvenientes. Durante el conteo de votos, solo el 10,1% de las mesas contó con fiscales que realizaron algún reclamo”. Esto significa que hubo cerca de 730 mesas con reclamos. A 300 votantes por mesa, hay unos 219.000 votos en cuestión, muy por encima de los 54.000 que definieron la elección en CABA y peligrosamente cerca de los 300.000 votos de diferencia que definieron el ballotage presidencial de ese mismo año. De ese informe surge también que un 26,2% de los votantes dijo no haber verificado que el voto impreso coincidiera con lo que había elegido.

Pero además, aun en el caso en que todas las mesas electorales corroboraran el escrutinio electrónico con uno manual, el manual es solo corroboración de una planilla que se graba digitalmente en otra boleta electrónica. De nuevo, un software malicioso podría hacer que la grabación tenga cifras adulteradas incluso cuando la propia máquina las siga mostrando como correctas. O tal vez la manipulación podría hacerla la máquina que lee la tarjeta y manda la información a través de Internet hacia el centro de cómputos (que a su vez podría tener software adulterado o hackeado como el de CABA en 2015). No sé cómo vienen ustedes, pero a esta altura ya perdí la cuenta sobre la cantidad de saltos de fe.

Memoria y “países serios”

El pueblo argentino se ganó el voto universal, secreto y obligatorio en cuotas. Primero nos ganamos el voto (de entrada solamente los varoncitos, aunque ellas conquistaron la universalidad un par de cuotas más tarde), varias dictaduras nos lo sacaron y hubo que reconquistarlo. En el medio de esas peleas, conquistamos el voto secreto, y lo consagramos en la Ley Sáenz Peña.

Entonces teníamos la posibilidad de que nadie supiera a quién votaste, para que no pudieran chantajearte, presionarte, comprarte o vengarse de vos si no les gustaba tu decisión. Esto se manifiesta de manera muy clara cuando tenemos la posibilidad de poner nuestro voto en un sobre idéntico a todos los sobres para después abrir la urna y contar (y sí, hay maneras de manipular y de romper el secreto de voto, pero son fácilmente identificables y auditables por ciudadanos comunes).

Hay que tener memoria, algo que las computadoras también tienen. Justamente el tema de la memoria es central en el argumento de la Corte Suprema de Alemania que, en el año 2009, prohibió el uso de urnas electrónicas porque contradice el principio de que todos los pasos de la elección estén sometidos al escrutinio público sin requerir conocimientos técnicos especiales.

Si pudiera elegir un solo párrafo para ser recordado de todo este texto (que intenta ser exhaustivo respecto de las múltiples aristas a considerar en la adopción o no del voto electrónico y sus variantes), sería éste: si dependemos de un proceso técnicamente inaccesible para la enorme mayoría de nosotros (salvo los expertos en desarrollo de sistemas de votación electrónica), la transparencia del sistema para el ciudadano común desaparece.

Con el voto electrónico y sus variantes, a la democracia la vemos pasar, la miramos por TV. Nos cuentan y tenemos que creer o reventar. El pilar de nuestra construcción democrática, la elección, se transforma en algo que no entendemos, que no podemos auditar. No es un detalle menor que el voto sea secreto. Es esencial y nadie nos lo regaló, hubo que luchar mucho para conseguirlo. Con el voto electrónico y sus variantes, puede dejar de serlo. Lo que es peor aún, no sabemos si es o no secreto, y sembrar esa duda (que se vuelve razonable porque el sistema es tan opaco que no hay forma de saber la verdad), alcanza para que alguien pueda manipular nuestra decisión. El voto no solamente tiene que SER secreto, sino que tiene que LUCIR secreto, para poder ser ejercido sin presiones.

De imprentas e impresoras

El sistema actual no es perfecto: es cierto que es problemático y costoso distribuir las boletas a todos los cuartos oscuros, y que sería muy bienvenida una alternativa superadora a semejante desafío logístico, especialmente para los partidos chicos. Pero superadora de verdad, no solo aparentemente. Si vamos a informatizar, pensemos en lo que pasa después de votar, desde hacer un conteo asistido de los votos hechos en papel a cosas mínimas como disponer de un procesador de texto y una impresora en los cuartos oscuros para que las actas no sean manuscritas y haya menos errores de transcripción.

Muchas veces se revolea el argumento de que las máquinas de votación son solamente impresoras. Es un argumento casi gracioso porque las impresoras de hoy en día son solamente otro tipo de computadoras y, como tales, también tienen memoria. Y pueden usar esa memoria para registrar que, por ejemplo, el primer votante votó por A, el segundo por B, el tercero por A de nuevo, y así siguiendo. Con el simple expediente de ir contando, todos los fiscales partidarios pueden saber quién votó primero, quién segundo, etcétera. No solo los fiscales, basta con poner a un chabón a fumar en la puerta del cuarto oscuro. Es decir, no alcanza con que el sistema no manipule los resultados, también hay que garantizar que no registre información de más.

Y la verdad es que en este caso hace falta poca memoria, o casi ninguna: en cada cuarto oscuro votan unas 300 personas; ese número se codifica con solo 9 bits.

Si no te resulta obvio que el número 300 se codifica con 9 bits, es un claro ejemplo de cómo el sistema que estamos discutiendo también te dejó afuera a vos, una persona probablemente educada, curiosa e informada, pero que no tiene conocimientos específicos sobre computación. Qué loco pensar que con esas mismas condiciones sí podrías auditar todo el proceso de voto en papel: saber leer, ser curioso y educarte respecto del proceso de fiscalización (algo que demora minutos).

Decíamos que alcanza con 9 bits, 9 puntitos escondidos en cualquier parte de la boleta en papel para saber a quién votó cada persona. Si alguien va contando en qué orden vota cada uno de los electores, luego, cuando recuperan las boletas en papel, se miran esos 9 puntitos mínimos, escondidos con algo de cautela, tal vez en el borde de una letra, tal vez simulando ser una mancha de tinta, y se puede reconstruir a quién votó cada elector. ¡En tu cara, Sáenz Peña!

Comparando

El sistema electoral actual no es perfecto y tiene mucho para mejorar. Pero es mucho mejor de lo que se nos quiere hacer creer repetidas veces. Si una fuerza política quiere gobernar una ciudad debe concitar las voluntades de la mayor parte de los electores de la ciudad, pero el requisito previo es que tenga un núcleo de personas con un nivel mayor de adhesión, realmente entusiasmados por la propuesta, que estén dispuestos a ser fiscales durante un día. ¿Con qué requisitos? Los básicos: prestar atención, saber leer, sumar y restar, condiciones que en líneas generales cualquier adulto puede cumplir. Sería razonable que las fuerzas políticas que tienen una ambición mayor, como la de gobernar una provincia, tuvieran una cantidad de entusiastas proporcional al tamaño de la provincia. Si no, es muy difícil pensar que la van a poder gobernar. El mismo razonamiento cabe si quieren gobernar un país. Por supuesto que no es fácil, pero gobernar tampoco lo es. Si no podés resolver el problema de conseguir veinte fiscales para ser intendente de tu ciudad, difícilmente puedas resolver los problemas que conlleva la propia intendencia, donde son muchas más las voluntades que deben alinearse, durante mucho más tiempo que un par de domingos cada dos años. Lo mismo si querés gobernar un país.

Por otra parte, es poco verosímil y hasta peligroso que una fuerza política acepte dejar la máquina de votación sin supervisión, con lo que la implementación de mecanismos electrónicos tampoco elimina la necesidad de fiscales.

Para los fiscales, el sistema actual podría mejorarse en varios puntos, pero el hecho de poder entrar por la web y ver si el telegrama escaneado tiene tu firma y si la planilla electrónica coincide con lo que está escrito a mano y con tu copia del acta es un punto de control muy fuerte.

Dada la propuesta actual de voto electrónico, con tener fiscales no alcanza, porque en definitiva los puntos de control establecidos de nada sirven si se pierde el secreto del voto, si lo que se graba en la boleta no refleja la voluntad del elector en todos los casos, o si luego esa información es nuevamente volcada a otra computadora que puede manipularla en el proceso.

No es menor decir que este análisis no parte de ser un romántico de los viejos tiempos o un férreo opositor a la ciencia y la tecnología. Lejos estoy de serles fóbico o de no comprenderlas. Es más bien lo contrario en este caso: entender cómo funciona la tecnología digital nos da herramientas para poder mirarla con ojos críticos. Justamente por eso entendemos sus limitaciones, como lo hacen casi todos los países desarrollados (para nada tecnofóbicos), que siguen votando en papel.

De hecho, si lo que se busca es boleta única, existe la boleta única en papel: en un mismo cacho de árbol tenés a todos los candidatos de todos los partidos y le ponés una cruz a los que prefieras (la única dificultad es que hay que explicarles a los adolescentes que se elige solo con una cruz y no vale usar otros emoticones).

Decía más arriba que con la boleta electrónica la transparencia se pierde, y es importante recalcar que no reaparece si, en lugar de implementarse a las apuradas, se hiciese con tiempo suficiente.

El sistema está intrínsecamente viciado porque el piso mínimo necesario para entender el proceso electoral electrónico, auditarlo y participar de su control, se vuelve prácticamente inalcanzable. Pasa de requerir habilidades que se adquieren en la escolaridad básica a volverse una discusión de expertos, cerrada, críptica, y por ende, excluyente.

Somos los ciudadanos y ciudadanas comunes, los que armamos ese nosotros bien grande que trasciende lo que nos aúna y lo que nos separa, los que queremos poder votar de forma secreta y segura, y que nuestro voto se escuche. Que se escuche cristalino, sin intermediarios, dudas o mugre.

Que se escuche exactamente como lo manifestamos, aun cuando el resultado no nos guste, pero sabiendo que genuinamente nos representa.

Notas

1 Este artículo fue publicado originalmente en el sitio El Gato y la Caja. Se puede leer el original que incluye algunas imágenes y videos en https://elgatoylacaja.com.ar/vot-no/

2 Felten, Ed. “The Linux backdoor attempt of 2003”, 09/10/2013, http://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/

3 El artículo en inglés se puede leer en esta página: http://dl.acm.org/citation.cfm?id=358210

4 Se refiere al referéndum sobre las FARC. Este artículo amplía el tema mencionado: “Referéndum con sorpresa: los colombianos rechazar el acuerdo de paz con las FARC”, Clarín, 03/10/2016, http://www.clarin.com/mundo/referendum-sorpresa-colombianos-rechazan-farc_0_r1stzBy0.html

5 Cf. Video “Multivoto: sumando múltiples votos con una boleta en el sistema vot.ar”, https://www.youtube.com/watch?v=CTOCspLn6Zk

6 Para ampliar sobre el caso de Joaquín Sorianello, se puede leer este artículo: http://www.clarin.com/politica/allanan-detecto-vulnerabilidades-sistema-electronico_0_HkBRiUKwml.html

Sobre el autor

Nicolás D’Ippolito es Doctor en Computación, psicólogo aficionado, investigador y profesor de la UBA.

Usemos Linux: DesdeLinux nominado a los Open Awards 2017 como Mejor Blog
Linux Adictos: Motorsport Manager gratis por una semana
Javier Smaldone

Javier Smaldone
Blog de Javier Smaldone

Voto electrónico: un debate entre lo seguro y lo moderno

Artículo de Tomás Aguerre incluido en el libro Voto electrónico, una solución en busca de problemas.

Tomás Aguerre

Los límites a la ingeniería constitucional están fijados caso por caso por el análisis de condiciones, es decir, por la pregunta, ¿bajo qué condiciones podrá cualquier intervención en particular, cualquier instrumento en particular, producir el efecto que se pretendía? Para mí esa es la cuestión principal.

Giovanni Sartori, 1996

Sabemos que una parte de cualquier discusión pública consiste en imponer los términos en los que se va a dar. La lucha política, después de todo, es la lucha por apropiarse de los términos valorados por la sociedad para cargarlos con el sentido propio.

La discusión sobre la posible implementación de voto electrónico en la Argentina comenzó con el intento de enmarcar ese debate en la idea de que agregarle tecnología al sistema de emisión del voto implica, necesariamente, modernizarlo.

Sin embargo, una serie de países en el mundo de los que tranquilamente podría asegurarse que van en el camino de la modernización transitaron el camino del voto electrónico (o comenzaron a hacerlo) y decidieron “volver” hacia la boleta de papel. El hecho de decir que adoptar el sistema de papel sea “volver” supone, incluso, que el camino indefectiblemente conduce hacia un páramo de voto electrónico al que, algún día, habrá que llegar.

Pero ese no es el caso en países como Alemania, Finlandia, Holanda, Australia y una larga lista que sigue con ejemplos de sistemas electorales que incorporaron tecnología o quisieron hacerlo y detectaron fallas que comprometían nada menos que la fiabilidad del resultado de la elección. En la actualidad, solo tres países usan algún sistema de voto electrónico para todo su sistema electoral nacional: Venezuela, Brasil e India.

El voto electrónico en Alemania

El caso de Alemania es uno de los más citados en la bibliografía especializada sobre el tema. El fallo del Tribunal Constitucional de marzo de 2009 declara la incompatibilidad de la Ley de Ordenamiento Federal de Aparatos Electorales del 3 de septiembre de 1975 (y sus sucesivas modificaciones) específicamente para su aplicación para la 16.° elección al parlamento alemán.1 El sistema que utilizó el país entonces fue el de máquinas de votación que registraban y guardaban el voto en una memoria interna, para luego realizar el escrutinio en el propio aparato que imprimía los resultados finales de la mesa. El fallo es producto de una demanda interpuesta por dos particulares quienes sostuvieron, entre varias cosas, que la confiabilidad del software instalado en los aparatos electorales (provistos por la empresa holandesa Nedap) no fue controlable por el público, que el examen que realizó el Ejecutivo no fue público y que no se permitieron auditorías independientes. El código fuente del software no estuvo abierto al público y no hubo garantía técnica de que las copias del software utilizado en las máquinas fueran concordantes con los modelos testeados.

La respuesta del Ministerio del Interior alemán fue que la publicidad del acto electoral estuvo garantizada porque el público pudo controlar la impresión del resultado electoral al finalizar el acto y el observador y la junta electoral pudieron cotejar los resultados. Respecto a las auditorías, el gobierno aseguró que el Instituto Federal Físico-Técnico de Alemania examinó en detalle la máquina electoral y que se realizaron controles por parte de las administraciones comunales y las juntas electorales.

La sentencia del tribunal alemán está fundada en dos principios que surgen de su Constitución:

1) el principio de la publicidad de la elección, que ordena que todos los pasos esenciales de la elección estén sujetas a
control público y

2) en la utilización de aparatos electorales electrónicos, el ciudadano debe poder controlar los pasos esenciales del acto electoral y la determinación del resultado de manera fiable y sin conocimientos técnicos especiales.

La Corte no prohibió el voto electrónico sino que declaró inconstitucional el marco jurídico que no garantizó el mandato constitucional de publicidad del acto electoral. Sostuvo, entonces:

la utilización de aparatos electorales que pueden registrar el voto electrónicamente y pueden determinar el resultado electoral de manera electrónica es, según ello, solo compatible con la ley fundamental bajo estrictas condiciones.

En cuanto al control del proceso electoral, el tribunal sostiene que, de implementarse este tipo de sistemas de emisión de voto, es recomendable el respaldo en papel para el votante. Ahora bien, el control del proceso no termina ni empieza en ese momento. La sentencia sostiene que una de las irregularidades en la implementación del voto electrónico fue que el propio Ministerio del Interior alemán emitió las homologaciones para las máquinas que se iban a usar.

El 15 de agosto de 2005, anunció la autorización definitiva del sistema que iban a usar las computadoras fabricado por Nedap, el hardware, los módulos de storage y el software. Invocando secretos comerciales de Nedap, el ministro se negó a hacer públicos los documentos que Nedap entregó al ministerio para la fiscalización del sistema y los resultados de los testeos.

En ese sentido, el fallo asegura que

los procedimientos para examinar el sistema y la aprobación por parte del ministerio deben ser públicos. Cualquier interés de los fabricantes en proteger su secreto comercial debe estar subordinado al principio de la democracia (…). Para que exista la posibilidad de testear el aparato de manera independiente, la publicación de los documentos y reportes del Physikalisch Technische Bundesanstalt y del código del software de las máquinas es la única forma de fiscalizar realmente el proceso electoral.

La idea de control y auditoría es mucho más amplia que el momento de chequear el voto contra la máquina y por eso la Corte sostuvo que no es suficiente el control de las instituciones públicas. Todos los procesos que estaban previstos en el Ordenamiento Federal de Aparatos Electorales (una legislación en la que Alemania trabajó desde los años ‘70) resultaron insuficientes como garantía de los principios constitucionales sobre emisión del voto:

ni una participación del público interesado en el proceso de evaluación o del permiso de aparatos electorales, ni la publicación de los informes de evaluación o caracteres de construcción (incluyendo los códigos fuente del software en el caso de aparatos electorales guiados por ordenador) contribuyen decisivamente en asegurar el nivel exigido constitucionalmente de controlabilidad y comprensión del proceso electoral (…). La participación del público necesita por ello, para lograr la exigida supervisión fiable, medidas complementarias ulteriores.

Aunque en la última enmienda a la ley federal electoral en 2013 no se eliminó la posibilidad de voto electrónico (pero sí se dejó establecido que si se hiciera debe contar con respaldo en papel), desde el fallo de la Corte no se volvieron a usar sistemas de voto electrónico en Alemania a nivel federal.

El voto electrónico en Irlanda

El caso de Irlanda permite mostrar un ejemplo de un sistema que, en la práctica, había “funcionado bien” según parámetros que se suelen utilizar para medir la efectividad del sistema (el grado de “aceptación” de quienes lo usaron, la satisfacción por la celeridad, etcétera). La primera propuesta de voto electrónico en Irlanda se realizó en 1998 y en el año 2000 se introdujo la legislación que permitió el voto electrónico. Para el 2002, Irlanda hizo las primeras pruebas piloto con el objetivo de extenderlo al resto del país: ese año, en dos elecciones consecutivas (las generales de mayo y el referéndum por el tratado de Niza de la Unión Europea) el voto electrónico alcanzó a cubrir el 18% del electorado.

Pasaron apenas unos meses para que un informe confidencial del Ministerio del Interior irlandés se filtrara a la prensa: allí se aseguraba que la integridad del proceso electoral en los lugares donde se implementó el voto electrónico no estaba garantizada. Entre otras fallas, el memorando interno que tomó estado público destacaba la posibilidad de que un software malicioso sencillo de programar pudiera generar una pantalla falsa en la máquina para hacer votar incorrectamente al elector.

A pesar de las repercusiones negativas y el manto de sospecha sobre el sistema, el gobierno irlandés avanzó con el plan de implementación de voto electrónico para las elecciones locales y europeas de 2004. Entonces creó la Comisión Independiente de Votación y Escrutinio Electrónico para que examinara el sistema propuesto.

La comisión emitió un informe en el que sostuvo que puede recomendar la utilización del sistema de voto electrónico pero que, así como estaba reglamentado, no podía garantizar la seguridad del voto y la rigurosidad del escrutinio.2

Para cumplir con ese requisito democrático, los especialistas realizaron una serie de consideraciones que debía tener un nuevo proyecto de implementación del voto electrónico: que tuviera en cuenta las potenciales fallas en el software, la seguridad física e informática de la transmisión de los datos, la cantidad insuficiente de auditorías y testeos independientes, entre otras.

El gobierno no dio marcha atrás con el sistema pero lo puso en suspenso: aun con las máquinas adquiridas y las pruebas piloto hechas, en 2004 se votó con el sistema de papel. La inversión que hizo Irlanda en el sistema fue uno de los argumentos principales de las autoridades para no descartar de plano la posibilidad de seguir usando el voto electrónico: a las 52 millones de libras iniciales que se le pagaron a Nedap, se agregaban ahora los costos de mantenimiento y de actualización del sistema (que la ONG irlandesa ICTE calculaba en 700.000 euros anuales y 20.000.000 por única vez,3 respectivamente).

Finalmente, el 23 de abril de 2009 el entonces ministro John Gormley anunció que quedaba descartado el sistema de voto electrónico, en base al alto costo de mantenimiento y actualización y la insatisfacción y sospechas que generó entre los electores.

El voto electrónico en Holanda

El 16 de mayo de 2008, apenas un año antes que en el caso irlandés, el gobierno de Holanda había tomado la misma decisión: abandonar el sistema de voto electrónico que había comprado a una empresa local, Nedap. La decisión se tomó luego de que, en 2008, un juez consideró que el sistema presentaba irregularidades que lo volvían directamente ilegal.

El sistema venía previamente cuestionado: en 2007, la comisión creada para analizar la seguridad y fiabilidad del voto electrónico en el país emitió el informe “Voting with confidence” donde se estableció, entre otras consideraciones, que

el voto con boleta de papel en centros de votación (NdA: se analizaba también la posibilidad de voto remoto) es la opción preferida en términos de transparencia y verificabilidad. En la práctica, sin embargo, hubo algunos problemas con el recuento de votos de papel; un método de voto electrónico en centros de votación que le otorgue un respaldo en papel al votante es más seguro y posible de realizar; en ese caso, las máquinas deben estar protegidas contra la radiación allí donde sea factible y económicamente posible.4

La cara visible de la batalla contra el voto electrónico en Holanda fue la de un grupo de activistas informáticos denominado “We don´t trust voting computers”, quienes, además de presentaciones judiciales, realizaron una demostración pública en un programa de televisión de las múltiples formas en las que se podía acceder y tomar el control de las máquinas Nedap sin demasiado esfuerzo. En menos de cinco minutos, lograron correr su propio software en una máquina de la empresa y repartir votos de acuerdo a sus preferencias, engañando al elector que utilizaba la máquina.

Tras los múltiples informes que demostraron las vulnerabilidades del sistema, la Secretaría de Estado Interior anunció que la regulación que había aprobado el voto electrónico en 1997 quedaba en suspenso hasta introducir las modificaciones necesarias para garantizar su seguridad. Hasta el día de hoy, Holanda mantiene el sistema de voto por medio de boleta de papel.

El voto electrónico en Finlandia

El recorrido de Finlandia fue similar: en 2006 aprobó una ley que permitía la prueba piloto con voto electrónico para las elecciones municipales de 2008 en algunos distritos. La prueba piloto arrojó alrededor de 200 incidentes con votantes que tuvieron problemas para dejar registrado su voto. A partir de esos inconvenientes, votantes de tres municipios elevaron quejas sobre la ley electoral que aprobó la prueba piloto. En la primera instancia, la Corte Administrativa de Helsinki sostuvo que las elecciones fueron ilegales y, luego, la Suprema Corte anuló las elecciones en esos tres municipios, que debieron repetirlas en septiembre de 2009.

En 2010 Finlandia puso en suspenso el sistema. Los cuestionamientos fueron los mismos que en el resto de los países: problemas de implementación, bajas capacidades del sistema de ser auditado y el riesgo potencial pero cierto de que el software fuera intervenido y los resultados manipulados, según relató la propia auditoría del Ministerio de Justicia.5

El voto electrónico en Polonia

Polonia, así como Australia, se presenta como un caso en donde el voto electrónico ni siquiera pasó la instancia de la formación de comisión y debates para su estudio. Polonia lo puso en debate como una posible herramienta para abordar dos cuestiones: los bajos niveles de participación electoral y los votantes polacos en el extranjero. Pero las propuestas siempre quedaron más en el orden de lo discursivo que en lo legislativo.

Las primeras expresiones fueron más bien contrarias por parte de las autoridades electorales. Wojciech Łączkowski, director de la Comisión Electoral Nacional entre el 94 y el 97, sostuvo que

el acercamiento al uso de tecnología que ayude al escrutinio debe hacerse con mucho cuidado, haciendo énfasis en que si bien el uso de la técnica es indispensable en tiempos modernos, traslada la responsabilidad de la accountability de las personas a las máquinas, las computadoras y los operadores.

Su sucesor del 98 al 2010, Rymarz Ferdinand, se expresó en el mismo sentido, apuntando a la necesidad de discutir el tema con especialistas.

La Comisión Nacional Electoral organizó entonces una serie de conferencias, incluyendo una Conferencia Internacional de Voto Electrónico (Varsovia, 14-16 de junio de 2000) a partir de la cual salieron análisis sobre la posibilidad de instaurar ese sistema en el país, evaluando fortalezas y debilidades.6 Los ciclos de conferencias continuaron y la última se realizó en 2013 donde se expusieron algunas de las conclusiones sobre el estado de la situación y una serie de principios para un posible avance:

–el e-voting y el usos de máquinas de votación se ha discutido ampliamente durante las últimas décadas pero el uso de tecnologías de la información en los procesos electorales es un tema mucho más amplio: en la actualidad, el trabajo de organización electoral es inconcebible sin la informatización de los sistemas en distintos niveles del proceso (delimitación de distritos, planificación financiera, confección de padrones, etcétera). En cuanto a la utilización de tecnologías en el sistema de emisión del voto, se presentan preguntas sobre los métodos de implementación y las formas de contratación y adquisición de los sistemas;

–a la hora de implementar tecnologías de la información y de la comunicación en el proceso electoral es vital construir las medidas de seguridad en los sistemas para garantizar la integridad del proceso y evitar la posibilidad de manipulación de información con fines maliciosos;

–cuando los organismos adquieren sistemas de TICs y equipos es fundamental que los procedimientos de contratación sean competitivos y abiertos para garantizar la transparencia y asegurar que los sistemas cumplen con el objetivo de mejorar el proceso electoral;

–cuando se considera el potencial de los sistemas de votación, los organismos electorales deben involucrar en la planificación a todos los actores para asegurar que hay suficiente aceptación pública de la incorporación de tecnología en el sistema de votación;

–un elemento clave para la introducción de sistemas de voto electrónico es tener suficientes instancias de testeo independientes, certificaciones y auditorías que garanticen una total transparencia del sistema.

Más allá de las declaraciones y las diversas publicaciones, no se presentó ninguna iniciativa específica tendiente a modificar la legislación electoral para la introducción de alguna forma de voto electrónico. Al día de hoy Polonia sigue utilizando el sistema de boleta de papel.

Para las elecciones locales de 2014, se contrató con poca anticipación un sistema informático para el momento del escrutinio. Al finalizar las elecciones se registraron problemas en algunas circunscripciones en donde falló el sistema y hubo que contar los votos a mano, lo que derivó en una semana de incertidumbres y marchas en las calles que puso en duda la legitimidad del sistema.

El voto electrónico en Australia

En el caso de Australia, se puso en estudio el tema luego de las elecciones de 2013, cuando una pérdida masiva de boletas arrojó dudas sobre la fiabilidad del sistema electoral de boleta única de papel. Por entonces el gobierno australiano encargó a una comisión del Congreso que estudie la posibilidad de introducir tecnología en el sistema de votación y almacenamiento.

El informe de la comisión sostuvo, entre varias cosas, que “incluso los más ardientes defensores [del voto electrónico] deben reconocer que en términos logísticos sería imposible para nuestras autoridades electorales implementarlo para las próximas elecciones que son en menos de dos años”. Luego de escuchar a expertos y examinar casos internacionales, la comisión concluyó que “es claro para nosotros que Australia no está en posición de introducir ningún sistema de voto electrónico a gran escala sin comprometer catastróficamente la integridad del sistema electoral”.7

Respecto a las diversas modalidades de voto electrónico, la comisión australiana aseguró que

las máquinas son vulnerables al hackeo en algún nivel. Eso puede ser mitigado por un sistema que no solo grabe el voto electrónicamente sino que también imprima un respaldo físico para el recuento posterior. En otras palabras, demasiados gastos para igual tener que acercarse al centro de votación y aun así votar a través de una máquina en vez de una boleta de papel.

El reporte concluyó que “independientemente de las posturas filosóficas sobre el voto electrónico no es posible introducir el sistema en el corto plazo sin enormes costos e inaceptables riesgos para la seguridad”.

En 2015, Australia volvió al sistema de boleta única de papel.

El voto electrónico en Estonia

Incluso en países donde algún tipo de sistema de voto electrónico funciona, los problemas de vulnerabilidad y fiabilidad del sistema son parte de la discusión. En las elecciones municipales del 2005, Estonia se convirtió en el primer país del mundo en probar el voto por Internet desde un lugar remoto, es decir, sin tener que acercarse hasta una mesa de votación, luego de un debate legislativo que comenzó en 2002.

El sistema permite optativamente votar por Internet desde un lugar remoto (la instancia de acercarse al centro de votación sigue vigente y es, de hecho, la que más se utiliza); la identificación se hace a través del documento nacional de identidad que es una tarjeta inteligente; el voto por Internet es previo al día de la votación y se puede modificar considerándose el último voto como el válido (algo que definió la Corte, tras una serie de presentaciones que hacían referencia a las ventajas que tenía un votante que podía cambiar su voto respecto a uno que no).

En 2005, casi el 2% utilizó el mecanismo de voto por Internet y fue creciendo en las sucesivas elecciones hasta llegar al 30% de la población eligiendo ese sistema en 2015. En el medio hubo discusiones sobre los riesgos en la implementación y en la ejecución. En el 2011 el Center Party y candidatos independientes presentaron una queja por fallas en el sistema que se resolvió de una manera bastante peculiar.

El código electoral de Estonia prevé que las quejas sobre el proceso electoral se pueden presentar hasta tres días después del día de las elecciones. Como la queja se presentó sobre el voto por internet desde accesos remotos (que se hace antes) y no por el sistema de votación del día de la elección solo se tomó como válida la presentación de un estudiante universitario y no la de los partidos, que presentaron en el término de tres días pero posteriores al día de la elección. La queja del estudiante –que pedía suspender los resultados de la elección– fue rechazada ya que la Comisión Nacional Electoral del país aduciendo que los mecanismos para garantizar que no habían ocurrido manipulaciones funcionaron, sin aclarar cuáles habían sido esos mecanismos. La presentación se elevó hasta la Corte Suprema que rechazó la queja rápidamente considerando que un votante solo puede presentar un recurso de queja cuando sus derechos propios fueron violados.

En base al informe de la Organization for Security and Cooperation in Europe/Office for Democratic Institutions and Human Rights (OSCE/ODIHR), la especialista en seguridad informática, Barbara Simons, sacó las siguientes conclusiones sobre el proceso electoral de 2011 en Estonia: el sistema de emisión del voto tiene numerosos problemas críticos; el secreto del voto es vulnerable; los dispositivos de los votantes son vulnerables; los servidores son vulnerables al ataque de cualquiera; el sistema no es abierto ni transparente y no hubo ninguna evaluación de seguridad por parte de técnicos en seguridad informática independientes.8

Las pocas garantías que ofrece sobre el carácter secreto del voto es una de las principales críticas que recibe el sistema de Estonia. En su análisis sobre las elecciones de 2011, el especialista Sven Heiberg establece que:

la única garantía posible de que el voto sea verdaderamente anónimo sería en presencia de, por lo menos, dos oficiales electorales, auditores y posibles observadores. Todos los procedimientos están previamente definidos y escritos pero incluso sin violar ninguno de esos procedimientos, el dueño del sistema puede manipular el resultado de la elección a gran escala sin ser detectado.9

En el 2014, el gobierno creó una comisión de investigadores independientes que realizó un informe muy crítico con el sistema. La comisión analizó el sistema que se utilizó en 2013, la documentación del sistema, el código fuente, el software y realizó experimentos en un laboratorio de recreación de voto por Internet.10 Según la comisión,

el sistema tiene varios problemas de seguridad: usa una arquitectura de seguridad que pudo haber sido adecuada cuando el sistema se introdujo hace una década pero que hoy está peligrosamente desactualizada. Desde que se diseñó el sistema, los ciberataques se volvieron una amenaza real y concreta. El sistema delega una extrema confianza en los servidores y las computadoras personales, el lugar más vulnerable para unataque. El informe demuestra múltiples maneras en las cuales se puede modificar votos ya emitidos, comprometer el secreto del voto, interrumpir el proceso electoral o sembrar dudas sobre la legitimidad del resultado.

Los expertos consideraron que se debía suspender la aplicación de esta forma de votación, pero las quejas fueron rechazadas por el Comité de Voto por Internet del país.

En 2015, Estonia celebró sus elecciones con el sistema de voto por Internet.

El voto electrónico en Estados Unidos

En Estados Unidos existe una serie de variantes de sistemas de emisión del voto, no solo de Estado a Estado si no de condado a condado. Un trabajo de tres organizaciones independientes (The Verified Voting Foundation, The Constitutional Litigation Clinic at Rutgers School of Law y The Common Cause Education Fund) revisó los sistemas y el funcionamiento de los sistemas en las elecciones de 2012, a partir de parámetros e indicadores construidos en elecciones anteriores por el Brennan Center.11 En el análisis se hace fuerte hincapié en una idea que en el debate argentino quiso instalarse como rectora: que la seguridad del voto electrónico estaba garantizada por el respaldo de papel que emiten las máquinas.

El informe de estas tres organizaciones divide los sistemas de votación que se usan en Estados Unidos en dos tipos: los sistemas de boleta de papel en los que el elector marca su voto (ya sea de forma manual o con un asistente tecnológico, el lápiz óptico) y los sistemas de voto electrónico, tengan o no tengan un respaldo en papel. En consonancia con los fallos e informes de otros países, el trabajo adhiere a la noción de que la impresión del voto cuando se procesa a través de un dispositivo tecnológico no modifica el carácter electrónico del voto.

Tras analizar la implementación de los sistemas en todo el país, los autores se manifiestan abiertamente en favor del sistema de boleta de papel por sobre cualquiera de los dos tipos de voto electrónico (el que imprime y el que no imprime un respaldo en papel). Dice el informe: “los autores creen que la boleta de papel y los sistemas ópticos de escrutinio, acompañados por sistemas de marcado de boletas accesibles para cualquiera, deben reemplazar a los sistemas de voto electrónico, con o sin respaldo de papel”.

Entre otras cosas, el informe lista una serie de fallas que ocurrieron en elecciones anteriores en sistemas que presentaban boleta de papel de respaldo y sistemas que no: principalmente, se hace referencia a “problemas de calibrado” en las máquinas, es decir, una mala configuración inicial de las máquinas que produjo retrasos en los centros de votación. Para esos casos, el sistema de respaldo de papel provocó dos escenarios: o el votante olvidó de contrastar su voto y registró un voto equivocado o lo contrastó, dio aviso a las autoridades y se frenó el proceso electoral para que se vuelvan a calibrar las máquinas. Cualquiera de ambos escenarios representa un perjuicio que el sistema de papel no tiene: en el primer caso, el votante con papel está chequeando su voto en el momento en que lo elige (no hay necesidad de doble instancia); en el segundo, con máquinas caídas y la necesidad de compartirlas entre todas las mesas, no solo para votar sino para escrutar, se termina con el único beneficio que el voto electrónico presenta frente al sistema de papel referido a la celeridad.

Sobre la posible “modernización” del sistema electoral argentino

Los casos analizados nos permiten extraer algunas enseñanzas y desafíos de cara al futuro para tratar temas vinculados a la “modernización” del sistema electoral argentino:

1) todos los procesos de implementación de tecnología se hicieron con amplios debates de reforma legislativa y posteriores pruebas piloto en circunscripciones pequeñas;

2) en todos los casos, se crearon comisiones evaluadoras antes y después de la implementación, conformadas por especialistas en la materia. De allí surgen referencias explícitas a las vulnerabilidades de los sistemas y a la necesidad de crear marcos regulatorios que no deleguen decisiones en las empresas;

3) un dato relevante surge de la cuestión del respaldo en papel: el proyecto del gobierno argentino “resuelve” la cuestión de la seguridad informática asegurando que la impresión de la boleta termina con cualquier riesgo. Sin embargo, países como Holanda, Alemania o Australia, aun advertidos de esta posibilidad, consideraron mejor volver o seguir con la boleta de papel. Eso demuestra que los problemas de vulnerabilidad no empiezan ni terminan en el momento de emitir el voto. El caso norteamericano es el más claro al respecto: el respaldo en papel no es un santo grial que permite terminar con las vulnerabilidades sino apenas el emparche a un sistema riesgoso que, a su vez, necesita de más resguardos. Sostener que “modernizar” el sistema de emisión del voto significa ir hacia un sistema emparchado resulta, cuanto menos, paradójico.

4) los controles y las auditorías fallaron en muchos países por el mismo motivo: el momento en que se pone en disputa el derecho de la empresa proveedora a resguardar su secreto comercial frente al derecho ciudadano a fiscalizar el sistema es un problema que aún no encontró solución;

5) la cuestión de los costos es uno de los principales motivos de debate en el mundo (no solo por la implementación sino por actualización y mantenimiento) y el proyecto argentino no tiene siquiera un estimativo acerca de cuáles serían esos costos para su implementación en todo el territorio.

El voto electrónico, está demostrado, introduce riesgos en la seguridad del voto y la vulnerabilidad del sistema, dos cuestiones que, a largo plazo, pueden generar el peor de los efectos: la desconfianza del electorado en un sistema al que solo pueden auditar por terceros. Es cierto, como se dice, que “todos los sistemas son vulnerables”, incluso los de papel en todas sus modalidades. Sin embargo, la diferencia en la seguridad del voto electrónico y el de papel radica en que el primero abre la puerta a un tipo de vulnerabilidad que, entre otros problemas, es capaz de manipular el sistema sin dejar rastros. La diferencia es cualitativa y uno de los fundamentos por los cuales muchos países del mundo encontraron que entre garantizar la seguridad del voto y tener un sistema superficialmente “más moderno” conviene resguardar el principio básico que sostiene el sistema democrático: la transparencia y seguridad de lo que decide la voluntad de los ciudadanos.

Notas

1 Fallo del Tribunal Constitucional Alemán, 2009. Disponible en: http://www.juridicas.unam.mx/publica/librev/rev/juselec/cont/27/dcl/dcl20.pdf

2 El informe “Secrecy, Accuracy and Testing of the Chosen Electronic Voting System” de la Commission on Electronic Voting de Irlanda está disponible en: http://www.umic.pt/images/stories/publicacoes1/Part%200%20Index.pdf

3 Informe disponible en http://www.stdlib.net/~colmmacc/e-voting-ireland.pdf

4 Informe disponible en http://www.cs.ru.nl/B.Jacobs/PAPERS/VotingSummaryConclusionsRecommendations.pdf

5 La ONG Electronic Frontier Finland publicó algunos de los resultados de esa auditoría, disponibles en https://effi.org/system/files?file=FinnishEVotingCoEComparison_Effi_20080801.pdf

6 Conclusiones finales de la conferencia disponibles en: http://www.aceeeo.org/en/events/22nd-annual-conference-warsaw-poland

7 El informe del Congreso australiano está disponible en: http://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Electoral_Matters/2013_General_Election/Second_Interim_Report

8 El informe está disponible en http://www.osce.org/odihr/77557?download=true

9 El análisis es parte del trabajo “The Application of I-voting for Estonian Parliamentary Elections of 2011”, disponible en http://research.cyber.ee/~jan/publ/evote2011.pdf

10 El informe se encuentra disponible en https://estoniaevoting.org/findings/summary/

11 El trabajo está disponible en http://countingvotes.org/sites/default/files/CountingVotes2012_Final_August2012.pdf

Sobre el autor

Tomás Aguerre es Licenciado en Ciencia Política de la Universidad de Buenos Aires (UBA) y co-editor del blog colectivo artepolítica.

Jueves 23 de marzo de 2017

Usemos Linux: Cómo mostrar la letra de las canciones de Spotify
Javier Smaldone

Javier Smaldone
Blog de Javier Smaldone

El voto electrónico no es la solución

Artículo de Delia Ferreira Rubio incluido en el libro Voto electrónico, una solución en busca de problemas.

Delia Ferreira Rubio

El ciclo electoral 2015, en nuestro país, ha dejado al descubierto falencias que han generado la desconfianza de la ciudadanía. El punto culminante fue el proceso electoral en Tucumán con su carga de clientelismo, violencia y trampas.2 Ante este lamentable espectáculo surge el clamor por la adopción del sistema de voto electrónico, cuya tarjeta de presentación destaca la experiencia de la Ciudad de Buenos Aires.

Cada problema reclama una solución y no se ha inventado aún la máquina que resuelva todos los flancos débiles de un sistema electoral como el argentino.3 El clientelismo, el abuso de recursos públicos con fines proselitistas, la violencia contra las autoridades de mesa, la quema de urnas, el negocio de los fiscales de un partido que se dejan comprar para no cumplir su función, la entrega fraudulenta de documentos argentinos a ciudadanos de otros países, la manipulación del padrón electoral, la manipulación en la carga de datos del escrutinio provisorio, todo esto puede seguir pasando aunque se instrumente un sistema de voto electrónico.

La implementación de cualquier sistema de voto electrónico abre –además– nuevas ventanas de oportunidad para los “vivos” de siempre. En la Ciudad de Buenos Aires, por ejemplo, un grupo de especialistas en seguridad informática detectó problemas que la auditoría encargada por el Tribunal Superior había pasado por alto.4 Llamativamente la reacción fue la persecución de quienes habían detectado las fallas.5 La trasmisión de información a través de Internet puede ser objeto de interferencias indeseadas. La utilización de códigos y otras formas de información cifrada suma un espacio de opacidad. Una línea de programa en un software puede modificar los resultados, tal como se demostró en algunos estados de Estados Unidos6 y también en el caso del sistema utilizado en Capital Federal.

La adopción de sistemas de voto electrónico –en cualquiera de sus variantes incluida la llamada “boleta única electrónica”– debe ser analizada con detenimiento no solo pensando en los problemas que supuestamente soluciona, sino en los que puede generar.

Moderno y rápido parecen ser los nuevos valores democráticos. Pero aun admitiendo que lo fueran, no se pueden dejar de lado otros valores prioritarios para la calidad de la democracia electoral:

—Moderno y rápido pero sin garantía del secreto del voto resulta una mala combinación. Venezuela y su sistema de voto electrónico es una buena prueba de ello.7

—Moderno y rápido pero no transparente tampoco contribuye a la legitimidad de las elecciones. El abandono del voto electrónico por decisión del Tribunal Constitucional Alemán8 lo dejó bien claro.

—Moderno y rápido pero no auditable no contribuye a la integridad de las elecciones. Los estándares internacionales en la materia son unánimes en el sentido de que se debe permitir la auditoría profesional y política de todo el sistema.

—Moderno y rápido pero privatizado pone en riesgo de dependencia la operación fundante de la legitimidad democrática.

Por otro lado, el reciente escándalo de Volkswagen puso de relieve que la sola utilización de la electrónica no garantiza el cumplimiento de los parámetros normativos. La alteración del software hizo que millones de automóviles entraran al mercado violando los estándares de seguridad ambiental.9

Sucedió a lo largo de varios años y no hizo falta mucha gente para concretar la maniobra. ¿Podría pasar con los sistemas de voto electrónico? No cabe duda.

Así, el otro interrogante que surge es ¿cuentan con capacidad técnica suficiente los organismos electorales argentinos para controlar eficientemente el sistema? No, y en los distritos que han implementado el voto electrónico lo que se ha visto es la creciente privatización de las etapas del proceso electoral y la tercerización de los controles en entidades académicas que no han visto o no han querido ver las falencias del sistema. Tampoco los partidos políticos están en condiciones de defender eficientemente sus derechos. En algunos casos ni siquiera se les proporciona acceso a la información necesaria. La fiscalización de un sistema de voto electrónico no se satisface con la “presencia de un fiscal informático” viendo cómo se encienden las máquinas. En los sistemas de voto electrónico, la manipulación es menos visible y puede llevarse a cabo con la intervención y conocimiento de muy pocas personas.

Es muy probable que Argentina se enfrasque –en los próximos años– en la modificación del sistema electoral a nivel nacional. Para que la eventual reforma contribuya a mejorar la calidad y confiabilidad del sistema debería abarcar no solo el análisis del instrumento de emisión del voto –la boleta–, sino los otros elementos del proceso electoral desde la emisión de los documentos y la elaboración del padrón hasta el escrutinio definitivo. Especial atención debe ponerse en el escrutinio provisorio hoy bajo la responsabilidad del gobierno de turno quien lo terceriza en una empresa privada. Este escrutinio que es el que concentra la atención de la ciudadanía no tiene valor jurídico, pero tiene una gran importancia política.

Si solo se concentra la atención en la forma de emisión del voto, me temo que los problemas más serios de la democracia argentina seguirán sin cambio. Sería lamentable perder una vez más la ocasión de sumar transparencia y legitimidad. Sin embargo, podemos enfrentarnos a ese escenario de discusión reducida a voto electrónico sí o no. En tal caso, a mi juicio, el debate debería girar en torno a una serie de garantías mínimas.10

En primer lugar, la discusión debe ser seria y no basada en falsos relatos. En la Ciudad de Buenos Aires, por ejemplo, la ley es clara al exigir que la adopción del voto electrónico pase por la Legislatura. No se hizo así. A lo que es sin duda un sistema de voto electrónico se le cambió el nombre y así se eludió la ley. La maniobra fue apañada por la Justicia con la honrosa excepción del entonces presidente del Tribunal Superior.11

Cualquier sistema de voto electrónico que se pretenda imponer debe garantizar efectivamente el secreto del voto. Esa garantía debe ser real a los ojos de cualquier elector, y efectiva desde el punto de vista tecnológico. Se debe evitar que, so pretexto de facilitar la emisión del voto, el acto de marcar la preferencia personal se transforme en una romería con electores frente a la máquina, acompañados de supuestos familiares, amigos, o auxiliares.

Se debe evitar la privatización del proceso electoral. La dependencia técnica de los organismos de control representa un grave riesgo para la limpieza de los comicios y la legitimidad de los electos. Los organismos de control electoral deben contar con la capacidad técnica y los recursos económicos necesarios para ejercer su función con plena independencia.

El sistema debe garantizar la más amplia auditoría por parte de los partidos políticos y la ciudadanía.12 Si el sistema no es manipulable no hay problema alguno en hacerlo transparente. Los expertos en informática, las organizaciones de la sociedad civil o incluso los ciudadanos individualmente tienen derecho a la información técnica. No solo a través de audiencias que son una mera formalidad, sino a través de la posibilidad de analizar el sistema en su integridad.

La transparencia y auditabilidad debe incluir el proceso de recuento de votos en la mesa de votación, en la carga de datos y contabilización del escrutinio provisorio y en el escrutinio definitivo. La información debe estar disponible para toda etapa del proceso en que se incorporen mecanismos electrónicos, sea para impresión y lectura de códigos, transmisión de datos, cómputo y publicación de los mismos.

La información sobre los resultados de mesa, escrutinio provisorio y definitivo debe permanecer disponible en Internet en forma accesible, amigable, en formato utilizable y en tiempo real. La importancia y utilidad de esta información no termina dos días después de la elección.

Creo que en la actualidad, lo más aconsejable sería ir a un sistema de boleta única en papel antes que embarcarnos en el negocio del voto electrónico. Pero más importante aún sería ocuparse de corregir el clientelismo y el abuso del poder con fines electoralistas. Si la forma de hacer política es el clientelismo (incluyo en ese rubro desde la entrega de bolsones de comida hasta el manejo político de los planes sociales), la máquina de votar no cambiará nada. Si no se garantiza la equidad en la campaña y solo se ponen límites a las fuerzas de oposición mientras el oficialismo utiliza los recursos del Estado para financiarse, la máquina de votar no cambiará nada. Si algunos políticos y sus seguidores están dispuestos a la violencia y la quema de urnas para ganar elecciones, la máquina de votar no cambiará nada, aunque sea rápida y moderna.

En síntesis, si se propicia la adopción del voto electrónico se deberían respetar algunas garantías mínimas:

a) Cualquier sistema de voto electrónico que se pretenda imponer debe garantizar efectivamente el secreto del voto. Esa garantía debe ser real a los ojos de cualquier elector, y efectiva desde el punto de vista tecnológico.

b) Se debe evitar la privatización del proceso electoral. La dependencia técnica de los organismos de control representa un grave riesgo para la limpieza de los comicios y la legitimidad de los electos. Los organismos de control electoral deben contar con la capacidad técnica y los recursos económicos necesarios para ejercer su función con plena independencia.

c) El sistema debe garantizar la más amplia auditoría por parte de los partidos políticos y la ciudadanía. Los expertos en informática, las organizaciones de la sociedad civil o incluso los ciudadanos individualmente tienen derecho a la información técnica necesaria para analizar el sistema en su integridad.

d) La transparencia y auditabilidad debe incluir el proceso de recuento de votos en la mesa de votación, en la carga de datos y contabilización del escrutinio provisorio y en el escrutinio definitivo. La información debe estar disponible para toda etapa del proceso en que se incorporen mecanismos electrónicos, sea para impresión y lectura de códigos, transmisión de datos, cómputo y publicación de los mismos.

e) La información sobre los resultados de mesa, escrutinio provisorio y definitivo deben permanecer disponibles en Internet en forma accesible, amigable, en formato utilizable y en tiempo real. La importancia y utilidad de esta información no termina dos días después de la elección.

Notas

1 Una versión diferente de este artículo fue publicada originalmente en Digital Rights, 27/10/15, http://www.digitalrightslac.net/es/el-voto-electronico-no-es-la-solucion/

2 La autora se refiere a las irregularidades acontecidas en las elecciones a gobernador en la provincia de Tucumán durante agosto de 2015. Más información puede leerse en http://www.lanacion.com.ar/1821620-elecciones-tucuman

3 El problema del robo de boletas se corrige con la boleta única, en la que constan todos los candidatos. El sistema de boleta única en papel implementado en Santa Fe (https://www.santafe.gov.ar/index.php/web/content/view/full/195312/(subtema)/195309) y Córdoba (http://www.justiciacordoba.gob.ar/bus/) ha funcionado bien y es más económico que el sistema de voto electrónico implementado en la Ciudad de Buenos Aires (https://eleccionesciudad.gob.ar/simulador/) o en Salta (http://simulador.electoralsalta.gob.ar/).

4 Más información al respecto en https://blog.smaldone.com.ar/2015/07/15/el-sistema-oculto-en-las-maquinas-de-vot-ar/

5 Bogado, David y Danny O’Brien, “Buenos Aires censors and raids the technologists fixing its flawed e-voting system”, 15/07/2015, https://www.eff.org/es/node/86903

6 Véase el documental Hacking democracy (HBO, 2006). Más información en http://www.hackingdemocracy.com/

7 Delgado, Antonio María, “Maduro admite que el voto no es secreto en Venezuela”, 18/05/2013, El Nuevo Herald, http://www.elnuevoherald.com/noticias/mundo/america-latina/venezuela-es/article2023161.html

8 “Alemania: urnas electrónicas anticonstitucionales”, 06/03/2009, http://www.vialibre.org.ar/2009/03/06/alemania-urnas-electronicas-anticonstitucionales/

9 “Dirty secrets. Volkswagen’s falsification of pollution tests opens door to a very different car industry”, 26/09/2015, The Economist, http://www.economist.com/news/leaders/21666226-volkswagens-falsification-pollution-tests-opens-door-very-different-car

10 Busaniche, Beatriz. “Voto electrónico. Los riesgos de una ilusión”, 28/07/2011, La Nación, http://www.lanacion.com.ar/1392827-voto-electronico-los-riesgos-de-una-ilusion

11 Ferreira Rubio, Delia. “BUE es voto electrónico”, 01/07/2015, Bastión digital, http://ar.bastiondigital.com/notas/bue-es-voto-electronico

12 Torres, Ariel. “Algunas reflexiones sobre el voto electrónico”, 11/07/2015, La Nación, http://www.lanacion.com.ar/1809389-algunas-reflexiones-sobre-el-voto-electronico

Sobre la autora

Delia Ferreira Rubio es abogada y Doctora en Derecho por la Universidad Complutense de Madrid. Entre 1990 y 2005, se desempeñó como Jefe de Asesores de Diputados y Senadores en el Congreso Nacional, trabajando con las Comisiones de Asuntos Constitucionales de ambas Cámaras del Congreso. Entre 2005 y 2007, cumplió el rol de Asesora de la Auditoría General de la Nación. A partir de 2007, trabaja como consultora independiente. Además, es investigadora de la Fundación CEPPA de Buenos Aires. Entre 2004 y 2010, fue miembro del board de Poder ciudadano y, entre 2008 y 2010, fue su Presidenta. También, fue miembro del board internacional de Transparency International por dos períodos consecutivos entre octubre de 2008 y octubre de 2014. Es autora de numerosas publicaciones sobre cultura democrática, instituciones políticas, política comparada, gobierno por decreto, ética pública y parlamentaria, financiamiento de los partidos políticos y sistemas electorales, entre otros temas.

Viernes 17 de marzo de 2017

Estructura de datos en python (Grafos)

Continuando con la serie de artículos sobre estructuras de datos en python. En este caso se tocará el tema de grafos con dos ejemplos, uno con listas y otro con matrices.

Los artículos anteriores son:

Este artículo se basa en los códigos en github Grafos con listas adyacentes y Grafos con matriz adyacente y del vídeo en youtube Grafos en Python.

De ejemplo de grafo se usará un modelo de procesos de colas, a continuación la imagen:


A continuación el código manejando el grafo como una lista:


#!/usr/bin/env python



class Vertice(object):

def __init__(self, n):

#Se define el nombre del vertice y la lista de vecinos

self.nombre = n

self.vecinos = list()



def agregarVecino(self, v):

if v not in self.vecinos:

self.vecinos.append(v)

self.vecinos.sort()







class Grafo(object):

#Se crea un diccionario de vertices.

vertices = {}



def agregarVertice(self, vertice):

#Se pregunta si vertice es una instancia de Vertice y si el nombre no esta en la lista de vertices.

#Si se cumple se agrega el vertice al diccionario de vertices.

if isinstance(vertice, Vertice) and vertice.nombre not in self.vertices:

self.vertices[vertice.nombre] = vertice

return True

else:

return False



def agregarBorde(self, u, v):

#Si u y v estan en vertices. se agregan como vecinos.

if u in self.vertices and v in self.vertices:

self.vertices[u].agregarVecino(v)

self.vertices[v].agregarVecino(u)

return True

else:

return False



def printGrafo(self):

#Se muestra el grafo.

for key in sorted(list(self.vertices.keys())):

print(key + str(self.vertices[key].vecinos))



if __name__ == '__main__':

g = Grafo()

cinco = Vertice('5')

tres = Vertice('3')

cuatro = Vertice('4')

uno = Vertice('1')

dos = Vertice('2')

for i in range(ord('1'), ord('6')):

g.agregarVertice(Vertice(chr(i)))



bordes = ['53','54','31','35','41','42','45','12','13','14','21','24']

for borde in bordes:

g.agregarBorde(borde[:1],borde[1:])



g.printGrafo()







Al ejecutar el script se tiene:
python grafo-listas.py
1['2', '3', '4']
2['1', '4']
3['1', '5']
4['1', '2', '5']
5['3', '4']


Como se ve, los vertices relacionados, el 1 se conecta con 2,3 y 4, el 2 con 1 y 4, el 3 con 1 y 5, el 4 con 1,2 y 5; y el 5 con 3 y 4.

El siguiente código muestra otra manera de crear el grafo, en este caso se puede manejar el peso de los bordes (aunque no se usa en el ejemplo).  A continuación el código:


#!/usr/bin/env python3



#Se importa nuevas caracteristicas de print

from __future__ import print_function





#Se crea la clace vertice que solo tiene como argumento su nombre.

class Vertice(object):

def __init__(self, n):

self.nombre = n





#Se crea la clase grafo con vertices e indices de bordes como diccionarios

#y bordes como una lista.

class Grafo(object):

vertices = {}

bordes = []

indices_bordes = {}





def agregarVertice(self,vertice):

#Si vertice es una instancia de su clase y su nombre no esta en el 

#diccionario de vertices se agrega.

if isinstance(vertice, Vertice) and vertice.nombre not in self.vertices:

self.vertices[vertice.nombre] = vertice

#Se recorre los bordes y se agregan.

for fila in self.bordes:

fila.append(0)

self.bordes.append([0] * (len(self.bordes)+1))

self.indices_bordes[vertice.nombre] = len(self.indices_bordes)

return True

else:

return False



def agregarBorde(self,u,v, peso=1):

#Se agrega el borde.

if u in self.vertices and v in self.vertices:

self.bordes[self.indices_bordes[u]][self.indices_bordes[v]] = peso

self.bordes[self.indices_bordes[v]][self.indices_bordes[u]] = peso

return True

else:

return False





def printGrafo(self):

#Se muestra el grafo

for v, i in sorted(self.indices_bordes.items()):

print(v + ' ', end='')

for j in range(len(self.bordes)):

print(self.bordes[i][j], end='')

print(' ')    





if __name__ == '__main__':

g = Grafo()

cinco = Vertice('5')

tres = Vertice('3')

cuatro = Vertice('4')

uno = Vertice('1')

dos = Vertice('2')

for i in range(ord('1'), ord('6')):

g.agregarVertice(Vertice(chr(i)))



bordes = ['53','54','31','35','41','42','45','12','13','14','21','24']

for borde in bordes:

g.agregarBorde(borde[:1],borde[1:])



g.p

rintGrafo()





Al ejecutar el script se tiene lo siguiente:
python grafo-matrix-adyacente.py 
1 01110 
2 10010 
3 10001 
4 11001 
5 00110 

Como en el caso anterior, el vertice 1 se conecta con 2,3 y 4, el vertice 2 se conecta con 1 y 4, el vertice 3 conecta a 1 y 5, el vertice 4 conecta a 1,2 y 5; y el vertice 5 conecta con 3 y 4.



Se tienen dos formas de representar un grafo, puede usar el que prefiera, dependiendo de la complejida, si se necesita manejar pesos, la opción es el de la matriz.


Domingo 12 de marzo de 2017

Ubuntips: ¿Ver porno mete virus en el ordenador?
Ubuntips: Nueva cita de la tecnología con el MWC 2017

Estructura de datos en Python (Lista Enlazada)

Continuando con la serie de estructuras de datos, en el artículo anterior se trato de la estructura de datos Nodo, en este artículo se usará el Nodo por medio de composición en la lista enlazada.

Este artículo se basa del tutorial en youtube llamado Python:Linked Lists donde pasan el enlace al código en github.

La lista enlazada se basa en el Nodo, como recordarán el Nodo tiene el dato y lo que apunta al próximo nodo.  En el caso de la lista enlazada contendrá lo siguiente:

  • Argumentos:
    • Nodo: Al crear la lista enlazada se crea un Nodo sin datos y que apunte a None.
    • primero: variable privada que apunta al primer nodo.
    • ultimo: variable privada que apunta al último nodo.
    • tamagno: variable privada que lleva la cantidad de nodos que maneja la lista.
  • Métodos:
    • obtenerTamagno: Devuelve el tamaño de la lista.
    • add: Agrega un nodo a la lista enlazada.
    • remove: Remueve un nodo de la lista enlazada.
    • find:Busca un dato en la lista, devuelve el dato o False.


El código de la lista enlazada se muestra a continuación:


#!/usr/bin/env python3

#Se importa Nodo de nodos.

from nodos import Nodo









class ListaEnlazada(object):

    def __init__(self,primero = Nodo(None,None)):

        """Se asigna como Nodo inicial a primero y ultimo por que apuntan al mismo nodo

        y se define el tamagno de la lista en cero"""

        self.__primero = primero 

        self.__ultimo = self.__primero

        self.__tamagno = 0





    def obtenerTamagno(self):

        """Devuelve el tamagno de la lista"""

        return self.__tamagno



    def add(self,d):

        """Agrega un nodo a la lista enlazada"""

        #Se crea una instancia de nodo donde se le pasa el dato d y se coloca

        #como proximo nodo el primer nodo.

        nodoNuevo = Nodo(d,self.__primero)

        #El primer nodo apunta al nodo nuevo y se incrementa el tamagno.

        self.__primero = nodoNuevo

        self.__tamagno += 1





    def remove(self,d):

        """Se elimina el nodo que tenga el dato d"""

        #Al nodo actual se le asigna el primer nodo

        nodoActual = self.__primero

        #Y al nodo anterior se le asigna None.

        nodoAnterior = None



        #Mientras exista el nodo actual-

        while nodoActual:

            #Si el dato de nodo actual es igual al dato que se esta buscando.

            if nodoActual.dato == d:

                #Si existe nodo anterior

                if nodoAnterior:

                    #Se asigna  al apuntador proximo del nodo anterior el proximo de nodo actual

                    nodoAnterior.proximo = nodoActual.proximo

                else: 

                    #A primero se le asigna el apuntador al proximo nodo del nodo actual

                    self.__primero = nodoActual.proximo

                #En cualquiera de los dos casos se decrementa el tamagno de la lista.

                self.__tamagno -= 1

                #Devuelve True por que se elimino.

                return True

            else:

                #Se asigna al nodo anterior el nodo actual

                nodoAnterior = nodoActual

                #Se asigna al nodo actual, el nodo proximo del nodo actual

                nodoActual = nodoActual.proximo





    def find(self,d):

        """Se busca d en la lista enlazada, si existe devuelve d, si no devuelve None"""

        #a nodo actual se le asigna el primer nodo.

        nodoActual = self.__primero

        #Mientras exista el nodo actual.

        while nodoActual:

            #Si el dato de nodo actual es igual a d, devuelve d

            if nodoActual.dato == d:

                return d

            else:

                #Si no, el nodo actual apunta al proximo nodo.

                nodoActual = nodoActual.proximo

        #Si no se encuentra devuelve None.

        return None 







if __name__ == '__main__':

    miLista = ListaEnlazada()

    miLista.add(1)

    miLista.add(8)

    miLista.add(12)

    print("size: {0}".format(miLista.obtenerTamagno()))

    print (miLista.find(8))

    miLista.remove(8)

    print("size: {0}".format(miLista.obtenerTamagno()))

    print(miLista.remove(12))

    print("size:{0} ".format(miLista.obtenerTamagno()))

    print(miLista.find(5))





Al ejecutar el script se tiene lo siguiente:

python listas.py 
size: 3
8
size: 2
True
size: 1
None


Como se puede ver se agregan 3 elementos a la lista, luego se muestra el tamaño de la lista, se va eliminando cada elemento de la lista, donde se muestra el tamagno de la lista mientras se va eliminando elementos, y por último se busca el valor de 5 en la lista donde devuelve None. 



Sábado 11 de marzo de 2017

Pruebas unitarias en Python usando mocking y docker

Hace un tiempo escribí un artículo de pruebas unitarias con python usando Docker.  En ese artículo se muestras las distintas opciones de métodos para hacer pruebas unitarias, este caso se enfoca en hacer un mocking de datos (simulación de datos).

Este artículo se basa en el artículo del sitio semaphoreci, el artículo se llama Getting Started with Mocking in Python.

A continuación dejo el código inicial del Dockerfile, de la calculadora.py y de la prueba:

Archivo Dockerfile:


FROM python
WORKDIR /code/

RUN pip3 install --upgrade pip
RUN pip3 install nose
RUN pip3 install nose-cov
RUN pip3 install rednose
RUN pip3 install pytest
RUN pip3 install pytest-cov
RUN pip3 install mock


#EXPOSE 5000

ADD . /code/
COPY . /code/


#CMD nosetests --with-coverage
#CMD nosetests -sv --rednose
CMD python -m unittest




Archivo docker-compose.yml:

pruebas:
  build: .

  volumes:
    - ".:/code"


Archivo calculadora.py:
#!/usr/bin/env python
#Se importa sqrt de math
from math import sqrt


#Clase calculadora
class Calculadora:
#Metodo suma de x y y, se evalua si son enteros si no, devuelve error.
def suma(self,x,y):
if type(x) == int and type(y) == int:
return x + y
else:
raise TypeError("Invalid type: {} and {}".format(type(x),type(y)))



Archivo calculadora_test.py:


#!/usr/bin/env python3

from unittest import TestCase
from app.calculadora import Calculadora





class TestCalculadora(TestCase):
def setUp(self):
self.calc = Calculadora()

def test_suma_retorna_resultado_correcto(self):
##Asegura que sea igual la operacion de suma 2+2 a 4
respuesta = self.calc.suma(2,4)
self.assertEqual(respuesta, 6)



Al ejecutar docker-compose up se tiene:

docker-compose up 
Starting tutorialespruebas_pruebas_1
Attaching to tutorialespruebas_pruebas_1
pruebas_1 | .
pruebas_1 | Name                 Stmts   Miss  Cover
pruebas_1 | ----------------------------------------
pruebas_1 | app.py                   0      0   100%
pruebas_1 | app/calculadora.py       6      0   100%
pruebas_1 | unit.py                  0      0   100%
pruebas_1 | ----------------------------------------
pruebas_1 | TOTAL                    6      0   100%
pruebas_1 | ----------------------------------------------------------------------
pruebas_1 | Ran 1 test in 0.022s
pruebas_1 | 
pruebas_1 | OK
tutorialespruebas_pruebas_1 exited with code 0

Ahora se hará un cambio. En vez de llamar a suma a partir de la calculadora se hará una simulación del resultado usando mocking. Para ello el único cambio que se hará es el de calculadora_test.py.

A continuación el código del archivo:

#!/usr/bin/env python3

from unittest import TestCase
from app.calculadora import Calculadora
from unittest.mock import patch



class TestCalculadora(TestCase):
    

    @patch('app.calculadora.Calculadora.suma', return_value=9)
    def test_suma_retorna_resultado_correcto(self,suma):
        self.assertEqual(suma(2,3), 9)




Se importa patch a partir de mock, y se llama al decorador patch  pasando como argumento el método suma de calculadora, donde se le define que va a devolver el valor de 9 sin importar los argumentos de entrada de dicho método.  Luego se ejecuta el método test_suma_retorna_resultado_correcto donde se le pasa suma y se asegura que la suma de 2 y 3 da 9. 



Al ejecutar docker-compose up se tiene el siguiente resultado:

docker-compose up 
Starting tutorialespruebas_pruebas_1
Attaching to tutorialespruebas_pruebas_1
pruebas_1 | .
pruebas_1 | Name                 Stmts   Miss  Cover
pruebas_1 | ----------------------------------------
pruebas_1 | app.py                   0      0   100%
pruebas_1 | app/calculadora.py       7      0   100%
pruebas_1 | unit.py                  0      0   100%
pruebas_1 | unittest/mock.py      1278   1278     0%
pruebas_1 | ----------------------------------------
pruebas_1 | TOTAL                 1285   1278     1%
pruebas_1 | ----------------------------------------------------------------------
pruebas_1 | Ran 1 test in 0.100s
pruebas_1 | 
pruebas_1 | OK


Como e muestra, la prueba pasa sin probemas, la razón es que se está pasando vía mocking el valor que tiene que devolver la suma sin importar la entrada de datos del método a ejecutar.

El código de los distintos archivos se pueden ver en el repositorio de gitlab en la rama mocking.




Martes 31 de enero de 2017

Ubuntips: ¿Qué es mejor, Linux o Windows?

Lunes 30 de enero de 2017

Eduardo Federico

Eduardo Federico
Paraiso Linux

Como agregar un certificado SSL gratuito desde Vesta Panel

Si están al tanto de las noticias sobre internet, webs, SEO y tecnologia en general, seguramente habrán leído los nuevos cambios que involucran a la seguridad de las webs y las transcacciones realizadas en distintas webs.

Lo voy a resumir muy facilmente:

  • Muchas webs estan implementando certificados SSL en sus webs. Esto les permite tener una url que empiece con https://
  • Esto es debido a que no tenerlo puede afectar al SEO de un sitio. Ver esta nota en el blog de webmasters de google.
  • Ademas Chrome y Mozilla muestran como inseguros los sitios que no cuenten con dicho certificado. Ver nota en ayudawp.

La cuestión es que hace unos años tener un certificado SSL significaba desenbolsar $50 dolares anuales por cada sitio. Pero gracias a los certificados de Let’s Encrypt podemos tener certificados 100% gratuitos y muy fáciles de instalar.

Y como se hicieron tan comunes, la ultima version del panel Vesta agrega una opcion para que agregar este tipo de certificados a tu web sea todavia mas facil. Vamos a ver como hacerlo.

En la seccion WEB de su panel Vesta, hagan click en EDIT del dominio en cuestion.

Veran que hay un check que dice SSL Support. Deben marcarlo y tambien marcar el que aparece debajo que dice Lets Encrypt Support.

Guardan los cambios.

Ahora en su navegador prueban escribir la url completa con https:// y el navegador deberia marcarles esa web como segura.

Redirigir http a https

Ahora lo que deben hacer es solución un pequeño problema muy grande, y es no tener 2 versiones del mismo sitio. Para ello vamos a editar el archivo .htaccess y agregamos esto:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://paraisolinux.com/$1 [R,L]

Obviamente poniendo tu url en lugar de la mia.

Para probar escriben en la navegador escriben la url sin el https y si se redirige esta bien.

Solucionar Error 403 forbidden

En la mayoría de los sitios con hacer lo anterior ya estaría todo solucionado. Pero si por ejemplo siguieron el tutorial de Laravel + Vesta veran que no funciona, lo que deberán hacer es:

sudo nano /home/admin/conf/web/sapache2.conf

Y editar las mismas lineas mencionadas en el tutorial mencionado.

 

La entrada Como agregar un certificado SSL gratuito desde Vesta Panel pertenece a Paraiso Linux.

Domingo 29 de enero de 2017

Eduardo Federico

Eduardo Federico
Paraiso Linux

Como añadir un subdominio en Vesta Panel

Ya hemos visto lo sencillo que es agregar un dominio a Vesta. Pero tambien vimos que es necesario tocar los RECORDS.

Para agregar un subdominio también tendremos que hacerlo. Pero sigue siendo una tarea super sencilla.

Primero nos dirigimos a la seccion WEB de Vesta. Alli vamos a agregar el subdominio haciendo click en 'ADD WEB DOMAIN'.

Al igual que cuando añadimos el dominio deberemos elegir correctamente la IP y crear un usuario FTP.

A continuación nos dirigimos a nuestra cuenta de Digital Ocean y en la seccion 'Networking' buscamos la opcion 'Manage Domain' del dominio que nos interesa.

En esta nueva pagina debemos agregar un nuevo Record del tipo A. Escribiendo en el primer campo el nombre del subdominio y en el segundo campo eligiendo el droplet a donde apuntara ese dominio.

Ahora si ingresan en ese subdominio deberían ver la pagina por defecto de Vesta.

Una cosa mas. Si por X casualidades de la vida, en ese subdominio desean tener un proyecto realizado con Laravel o Lumen, lo mejor seria seguir el tutorial para instalar Laravel en Vesta.

 

La entrada Como añadir un subdominio en Vesta Panel pertenece a Paraiso Linux.

Eduardo Federico

Eduardo Federico
Paraiso Linux

Como instalar un proyecto de Laravel en Vesta Panel

Voy a suponer que saben como instalar un proyecto básico de Laravel. Este tutorial no es para cubrir esa parte. Sino una situacion que seguramente le pasa a muchos desarrolladores. Y es esta:

-Tenemos un proyecto realizado en laravel, seguramente en github o bitbucket

-Deseamos hacer publico ese proyecto usando nuestro panel Vesta

-Ya hemos realizado al instalacion de Vesta, creado el nuevo dominio y brindado acceso via SSH.

-Pero obviamente no podemos simplemente hacer un git pull del proyecto dentro de la carpeta public_html porque no queremos que todo el proyecto sea accesible sino simplemente la carpeta public.

Si se te presento esa situación, esto es lo que debes hacer:

Paso 1- Acceder via SSH

ssh admin@[la ip]

Paso 2- Acceder a la carpeta del dominio

cd web/[tu dominio]/public_html

Paso 3- Eliminar los archivos existentes que no nos interesen. Ej:

rm index.html robots.txt

Paso 4- Clonar el repositorio de interes

git clone git@bitbucket.org:sefsinalas/project-d-site.git .

Notar el punto del final. Eso es para que todo se clone en el directorio actual.

Paso 5- Volver a la carpeta home escribiendo

cd

Y abrir el siguiente archivo

sudo nano conf/web/apache2.conf

En ese archivo nos encontraremos con la configuracion del virtualhost de apache.

Buscamos la linea que dice

DocumentRoot /home/admin/web/[tu dominio]/public_html

Y la cambiamos por

DocumentRoot /home/admin/web/[tu dominio]/public_html/public

Tambien donde dice

<Directory /home/admin/web/[tu dominio]/public_html>

por

<Directory /home/admin/web/[tu dominio]/public_html/public>

Paso 6- Opcional

Revisar la version de node escribiendo

nodejs --version

Si es una version menor a la 6 entonces lo mejor sera desinstalarla e instalar una version nueva. Algo asi:

sudo apt-get purge nodejs npm
curl -sL https://deb.nodesource.com/setup_7.x | sudo -E bash -
sudo apt-get install -y nodejs

Paso 7- Por supuesto necesitan volver al directorio public_html y hacer las cosas que ya saben sobre laravel. Dar permisos a la carpeta storage, hacer npm install, copiar el archivo .env y cualquier otra cosa que requiera su proyecto.

Paso 8- Reiniciar el servidor. Pueden hacerlo desde la consola o desde el panel Vesta en la sección Server.

Eso seria todo. Por supuesto esto es solo una forma de hacerlo, existen varias otras, mas fáciles o difíciles, mas seguras o inseguras. Una de ellas seria olvidar GIT y usar FTP, y aqui tienen otra forma de parte de Bobby Allen.

Consejo: para probar que el tutorial salio bien recomiendo cambiar momentáneamente los nombres de los archivos public/.htaccess y public/index.php y crear un archivo index.html que diga algo como 'En mantemiento'.

La entrada Como instalar un proyecto de Laravel en Vesta Panel pertenece a Paraiso Linux.

Lunes 09 de enero de 2017

Mariano Mendez

Mariano Mendez
[A]NTRAX - [L]ABS

BING: El buscador olvidado


Posicionamiento WEB

Hoy día, quien tiene una un sitio Web de cualquier naturaleza, sea para ofrecer un servicio, producto, o incluso para compartir materiales o documentación digital, si quiere marcar presencia en la red de redes, necesariamente tendrá que considerar el posicionamiento WEB o SEO (Search Engine Optimization). 

Sabemos que el SEO comprende una serie de estrategias, técnicas, o incluso habilidades para lograr las primeras posiciones en los resultados de los buscadores clásicos: Google, Bing, Yahoo, etc.
Va de suyo que podemos pagar marketing publicitario para tales fines; sin embargo las destrezas del SEO nos permiten lograr estupendos posicionamientos en las búsquedas gratuitamente,  aunque impliquen laboriosidad.

En mi opinión, se leen muchísimos tips para el SEO de Google, pero me queda la sensación que tanto Bing como Yahoo, no siempre son tenidos en cuenta en este trabajo de posicionar nuestro sitio digital. 

Aclaro que no es mi idea en esta entrada enumerar estrategias o sugerencias para mejorar el SEO, sino apuntar a que se consideren otros buscadores diferentes de Google a la hora de posicionar un espacio cibernético.  Sino llamar a la reflexión para tener presente al  segundo motor de búsqueda más importante: BING.


Números en BING

La cuota de mercado de BING, según señalan  los expertos va en ascenso:

“...Bing actualmente cuenta con el 21,9% de la cuota de mercado en escritorio en Estados Unidos. Una información que ha llamado nuestra atención y que demuestra que el buscador de Microsoft no ha dejado de crecer. Un punto en el que podrían tener que ver las últimas novedades incorporadas por el gigante tecnológico. Pero vayamos con los datos.



 “En concreto, la cifra supone un incremento de un 0,1 porcentual respecto del mes de junio, cuando contaba con el 21,8%. Los datos ofrecidos por la citada compañía, asimismo, muestran una caída del 0,4 por parte de Google...”

Los números de la gráfica hablan por sí mismos.


Otros comentarios sobre Bing

Más allá de las cifras expuestas, es oportuno recordar que Facebook y Skype emplean a Bing como buscador por defecto y las redes sociales o la mensajería instantánea son puntos claves en el SEO, tanto  por su extendido uso como por su  notoriedad.

Si a esto le agregamos los aspectos técnicos que a Bing le preocupan como, por ejemplo: velocidad, link rotos del sitio, evitar contenidos flash, entre otros; se torna una sumatoria de elementos que no deberían estar olvidados para el SEO de nuestra Web.

Posicionar un espacio digital no es tarea sencilla, pero es la base para el éxito del mismo.
Como comenté antes, no dejaré un tutorial de sugerencias, pero quiero destacar en lo referente al SEO en bing una interesante guía para que al momento de poner manos a la obra la consideren.

Mariano Mendez

Mariano Mendez
[A]NTRAX - [L]ABS

Cómo comprar BITCOINS


En esta entrada hablaremos de las criptomonedas, en particular de los Bitcoin. Seguramente todos han oído hablar de este tipo de moneda digital, pero no está de más recordar qué es y para qué sirven los Bitcoins, sin perjuicio de algunas reflexiones personales sobre las ventajas de su uso.

Referencias previas del término Bitcoin

Si consultamos en Wikipedia el término Bitcoins:


“Bitcoin (signo: BitcoinSign.svg; abr.: BTC, XBT) es una criptodivisa concebida en 2009. El término se aplica también al protocolo y a la red P2P que lo sustenta y de forma común se denomina como una moneda digital. Generalmente se usa «Bitcoin» para referirse a la red o al protocolo y «bitcoin» (plural: «bitcoines») para referirse a las unidades monetarias.”


De la transcripción precedente puede inferirse que bajo la expresión “Bitcoin” se comprenden tres aspectos diferentes:

Como moneda digital o unidades  de pago en intercambios comerciales vía online.


Como protocolo estandarizado que da soporte a las transacciones electrónicas, sin la mediación de terceros.

Como red para donde se negocian las operaciones comerciales.
Desglosadas estas referencias, hay que destacar que la criptomoneda se sustenta en un sistema totalmente peer-to-peer(persona a persona) donde los intermediarios quedan excluidos. La no intervención de terceros y la ausencia de una Autoridad Central bancaria de país alguno,  es una de las ventajas de los Bitcoins, en la medida que inhibe la especulación y la participación en ganancias como lo hacen las entidades financieras. 

Apoyando estas líneas de pensamiento, en bitcoins.org se reseña: 


“De la misma manera que nadie controla la tecnología detrás del correo electrónico, Bitcoin tampoco tiene propietarios. Bitcoin lo controlan todos los usuarios de Bitcoin del mundo. Aunque los programadores mejoran el software, no pueden forzar un cambio en el protocolo de Bitcoin porque todos los demás usuarios son libres de elegir el software y la versión que quieran. Para que sigan siendo compatibles entre sí, todos los usuarios necesitan utilizar software que cumpla con las mismas reglas. Bitcoin sólo puede funcionar correctamente si hay consenso entre todos los usuarios. Por lo tanto, todos los usuarios y programadores tienen un gran aliciente en proteger dicho consenso.”


Se señala como creador del sistema a  Satoshi Nakamoto y el 12/01/2009 se anota como la primera transacción con esta moneda; y desde esa fecha no solo se ha disparado el uso de Bitcoins, sino el valor que los respalda. Razones evidentes por las que se hace recomendable su uso.  

¿Cómo comprar Bitcoins?

Adscribirse al sistema no es difícil y en lo particular recomiendo las orientaciones del siguiente enlace como comprar bitcoins en Argentina, donde se explica detalladamente los pasos a seguir para la adquisición y operaciones con la moneda criptográfica de la que hablamos. Además de contener un estupendo FAQ de preguntas frecuentes que solventan toda duda. 

A modo de cierre de la entrada y en forma sintética  se pueden destacar cuatro puntos a saber:

Seguridad del sistema: basado en un sistema criptográfico altamente seguro.


    Anonimicidad en las transacciones: la privacidad es un elemento fundamental al momento de adquirir, vender, enviar o recibir pagos. 

      Operaciones en tiempo real al instante:se puede enviar y recibir pagos a cualquier lugar del mundo en forma instantánea.
Expansión de la criptomoneda:actualmente casi todos los negocios online aceptan el Bitcoin como medio de pago. Se habla del Bitcoin como la moneda futurística.


Domingo 08 de enero de 2017

David Moreno

David Moreno
dm's blog

Thanks Debian

I sent this email to debian-private a few days ago, on the 10th anniversary of my Debian account creation:

Date: Fri, 14 Aug 2015 19:37:20 +0200
From: David Moreno 
To: debian-private@lists.debian.org
Subject: Retiring from Debian
User-Agent: Mutt/1.5.23 (2014-03-12)

[-- PGP output follows (current time: Sun 23 Aug 2015 06:18:36 PM CEST) --]
gpg: Signature made Fri 14 Aug 2015 07:37:20 PM CEST using RSA key ID 4DADEC2F
gpg: Good signature from "David Moreno "
gpg:                 aka "David Moreno "
gpg:                 aka "David Moreno (1984-08-08) "
[-- End of PGP output --]

[-- The following data is signed --]

Hi,

Ten years ago today (2005-08-14) my account was created:

https://nm.debian.org/public/person/damog

Today, I don't feel like Debian represents me and neither do I represent the
project anymore.

I had tried over the last couple of years to retake my involvement but lack of
motivation and time always got on the way, so the right thing to do for me is
to officially retire and gtfo.

I certainly learned a bunch from dozens of Debian people over these many years,
and I'm nothing but grateful with all of them; I will for sure carry the project
close to my heart — as I carry it with the Debian swirl I still have tattooed
on my back ;)

http://damog.net/blog/2005/06/29/debian-tattoo/

I have three packages left that have not been updated in forever and you can
consider orphaned now: gcolor2, libperl6-say-perl and libxml-treepp-perl.

With all best wishes,
David Moreno.
http://damog.net/


[-- End of signed data --]

I received a couple of questions about my decision here. I basically don’t feel like Debian represents my interests and neither do I represent the project – this doesn’t mean I don’t believe in free software, to the contrary. I think some of the best software advancements we’ve made as society are thanks to it. I don’t necessarily believe on how the project has evolved itself, whether that has been the right way, to regain relevancy and dominance, and if it’s remained primarily a way to feed dogmatism versus pragmatism. This is the perfect example of a tragic consequence. I was very happy to learn that the current Debian Conference being held in Germany got the highest attendance ever, hopefully that can be utilized in a significant and useful way.

Regardless, my contributions to Debian were never noteworthy so it’s also not that big of a deal. I just need to close cycles myself and move forward, and the ten year anniversary looked like a significant mark for that.

Poke me in case you wanna discuss some more. I’ll always be happy to. Specially over beer :)

Peace.

Jueves 15 de diciembre de 2016

Mariano Mendez

Mariano Mendez
[A]NTRAX - [L]ABS

XSS por POST


Hace unos días reportaron un XSS por POST en el formulario de contacto de Underc0de. Por suerte no era nada riesgoso, pero era una vulnerabilidad que debíamos arreglar.
En esta ocasión usaremos el código de ese formulario de contacto para reproducir la falla y para ver como probar si nuestras aplicaciones son vulnerables a los XSS por POST.

El código del formulario de contacto está acá: www.hospedando.com.mx/descargas/formulario.zip por si alguno desea realizar la prueba.

Además, necesitaremos alguna herramienta que modifique los parámetros que enviemos por POST. Yo usare Tamper Data que es un complemento de Firefox:

https://addons.mozilla.org/es/firefox/addon/tamper-data/

Una vez montado el formulario de contacto se vera algo así:



El primer paso será completar todos sus campos y abrie Tamper Data. Una vez hecho esto, damos en "Comenzar Modificación" (En el tamper data) y enviamos el formulario de contacto.
Seguido a esto, nos aparecerá una alerta en Tamper Data para modificar los datos que estamos enviados.


Damos en modificar, y revisamos los valores que está enviando del lado derecho, que son los que hemos cargado desde el formulario.


Ahora es momento de jugar con estos campos. Este formulario de contacto no filtra sus variables, asique colocaremos algún vector de XSS en sus parámetros.
En este caso, coloqué un simple alert en el campo correo.

<script>alert('XSS')</script>

Pero podemos buscar o usar cualquier otro. Al dar en Aceptar, el sitio seguirá cargando con la nueva información suministrada...


Y como podrán apreciar, apareció el Alert con nuestro mensaje.

Espero que les sirva!

Lunes 29 de agosto de 2016

David Moreno

David Moreno
dm's blog

Webhook Setup with Facebook::Messenger::Bot

The documentation for the Facebook Messenger API points out how to setup your initial bot webhook. I just committed a quick patch that would make it very easy to setup a quick script to get it done using the unreleased and still in progress Perl’s Facebook::Messenger::Bot:

use Facebook::Messenger::Bot;

use constant VERIFY_TOKEN => 'imsosecret';

my $bot = Facebook::Messenger::Bot->new(); # no config specified!
$bot->expect_verify_token( VERIFY_TOKEN );
$bot->spin();

This should get you sorted. What endpoint would that be, though? Well that depends on how you’re giving Facebook access to your Plack’s .psgi application.

Domingo 21 de agosto de 2016

David Moreno

David Moreno
dm's blog

WIP: Perl bindings for Facebook Messenger

A couple of weeks ago I started looking into wrapping the Facebook Messenger API into Perl. Since all the calls are extremely simple using a REST API, I thought it could be easier and simpler even, to provide a small framework to hook bots using PSGI/Plack.

So I started putting some things together and with a very simple interface you could do a lot:

use strict;
use warnings;
use Facebook::Messenger::Bot;

my $bot = Facebook::Messenger::Bot->new({
    access_token   => '...',
    app_secret     => '...',
    verify_token   => '...'
});

$bot->register_hook_for('message', sub {
    my $bot = shift;
    my $message = shift;

    my $res = $bot->deliver({
        recipient => $message->sender,
        message => { text => "You said: " . $message->text() }
    });
    ...
});

$bot->spin();

You can hook a script like that as a .psgi file and plug it in to whatever you want.

Once you have some more decent user flow and whatnot, you can build something like:



…using a simple script like this one.

The work is not finished and not yet CPAN-ready but I’m posting this in case someone wants to join me in this mini-project or have suggestions, the work in progress is here.

Thanks!

Miércoles 29 de junio de 2016

PCTux: El hashtag que pide a Messi que no se vaya

Lunes 13 de junio de 2016

Javier Ledesma

Javier Ledesma
Ubuntronics

Richard Stallman nos explica: ¿Por que no usar celulares?

Richard Matthew Stallman (nacido en Manhattan, Nueva York, 16 de marzo de 1953), con frecuencia abreviado como «rms» es un programador estadounidense.


Es principalmente conocido por el establecimiento de un marco de referencia moral, político y legal para el movimiento del software libre, como una alternativa al desarrollo y distribución del software no libre o privativo.

Continuar leyendo »

Domingo 12 de junio de 2016

Javier Ledesma

Javier Ledesma
Ubuntronics

¿Cómo crear una lista de los paquetes instalados con Pacman y Yaourt?

Hacer una lista de todos los paquetes instalados en nuestro sistema ─en mi caso Arch Linux─ por medio de los gestores: Pacman y Yaourt, ¡es muy fácil!


Con ejecutar un solo comando en un Terminal es posible conocer los paquetes que hemos instalados, a excepción de los paquetes "base" y "base-devel".

Continuar leyendo »

Lunes 06 de junio de 2016

Javier Ledesma

Javier Ledesma
Ubuntronics

Jugar a Game Boy Advance en Linux con mGBA

Game Boy Advance (abreviada como GBA) es una popular consola de videojuegos de la compañía Nintendo. Hubo juegos de todos los géneros para esta consola que también, es compatible con todos los juegos de Game Boy y todos los de Game Boy Color.


mGBA en un emulador de Game Boy Advance con el que podrás disfrutar de todos los juegos de la fantástica consola de Nintendo en tu ordenador.

Continuar leyendo »

Viernes 05 de febrero de 2016

PCTux: Cupones de descuento en Argentina

Domingo 08 de noviembre de 2015

Sergio A. Alonso

Sergio A. Alonso
Bunker Blog

Taller de Linux y Ruby on Rails

Hace tiempo que no posteo en el Blog
Sepan disculpar: no solo no me he retirado, sino que gracias a mis dos últimos empleos, Belatrix y Supercanal (donde sigo trabajando) he aprendido mucho y apenas me ha alcanzado el tiempo para transmitir conocimientos nuevos
Como para no dejar completamente de lado la docencia, lanzo la cuarta edición de este Taller, con muchas novedades.
Si bien el Taller es presencial, incluye un aula virtual propia con todo lo necesario para crear los primeros algoritmos en Ruby, diseñar aplicaciones web, hacer scripting, y armar ambientes reales de producción.
El taller es muy intenso: incluye varios meta conocimientos alrededor de esta tecnología adquiridas a lo largo de 20 años de experiencia: intercambio de llaves, GIT, seteo de Apache, balanceadores de carga, debug sobre el terreno, despliegue de nodos, deploy en clouds, y una larga lista de habilidades tanto del desarrollador web como de esa nueva profesión que se viene gestando llamada DevOp.


Ejemplo del aula, la cual gracias a Screen y al fantástico Codebox IDE me permite asistir rápidamente a los alumnos:

Para los impacientes, aquí les dejo un enlace a la descripción del Taller, clase por clase: https://goo.gl/ngQ2BE

Enlace hacia la nota completa: http://goo.gl/BLyqdy

Se agradece su difusión.

Martes 13 de octubre de 2015

¿Que es QRDA? #QRDA @QRDAve

QRDA nace bajo la idea de proveer soluciones tecnológicas a distintas organizaciones sin fines de lucro, a través del apoyo de twitter.com/delbosquetech y con el respaldo de la Comunidad del Software Libre en Venezuela.

Esta idea la propone Luis Ortiz, gran amigo y compañero de trabajo. Se desarrolla en una reunión social (agua, cerveza, jugos, refresco, pizza) por lo que es considerado un evento entre panas que buscamos un mismo fin: dar apoyo con nuestro conocimiento tecnológico para desarrollar proyectos determinados.

Luis en la Charla de Inicio de QRDA

Luego de establecer las bases que sustentarían este proyecto, se fueron creando diferentes tickets en github que permitieran establecer un orden a las actividades que se van desarrollando, para luego crear las diferentes listas de correo y comenzar a trabajar.

Al final de la actividad pudimos compartir con personas que se acercaron de diferentes parte de Venezuela y que integran la Comunidad del Software Libre, gente con la cual me identifico y que se ha ganado mi respeto.

La lista de agradecimiento es extensa, son muchos los involucrados en este maravilloso proyecto que, aún y cuando está comenzando, podría asegurar que ayudará a muchas personas y tendrá un crecimiento positivo. Muchas gracias a todos.

Les dejo las redes sociales de QRDA para que también puedan seguir este proyecto y, si lo desean, puedan unirse a nosotros:

https://twitter.com/QRDAve/
https://instagram.com/qrda.ve
https://www.facebook.com/QRDA.com.ve
http://qrda.com.ve

Nuevamente Gracias por venir.

Lunes 14 de septiembre de 2015

La accesibilidad web para personas con discapacidad visual

“La Accesibilidad” hoy en día es una de las palabras más utilizadas cuando nos referimos a las persona con alguna discapacidad, más específicamente la discapacidad visual. Ésta no solamente abarca los aspectos de software y hardware, sino que además se centra en la vida misma de estas personas, cómo puede hacerse más fácil la tarea de convivir con personas que no tienen este tipo de desventaja; debido a esto, las instituciones del Estado se han interesado y comprometido a realizar medios más accesibles para ellos, así por ejemplo tenemos los pasos peatonales, incluso hoy en día hablamos de la creación de páginas web o sistemas de información accesibles. Es importante resaltar que se debe hacer un buen uso de la tecnología para poder romper las barreras que se presentan.
La construcción de estos sistemas o páginas web son de gran ayuda para las personas que viven con esta discapacidad debido a que han sido de alguna forma discriminados, sin dejar a un lado que este grupo está ya formado por más de 30 mil personas en nuestro país, esto de acuerdo a las cifras arrojadas en el censo realizado por CONAPDIS (Consejo Nacional para las Personas con Discapacidad). Es por ello que en estos momentos se debe luchar por incluir a todas estas personas en las actividades cotidianas del hombre, más específicamente en el mundo de las tecnologías, permitiéndoles conocer, por medio de páginas web por ejemplo, todo el contenido que puede ser de su interés y así pueda salir adelante de una mejor manera. El objetivo principal es que estos sistemas estén disponibles para todas estas personas y que sean incluidas en el aparato productivo de nuestro país, además de que la misión es producir, transformar e implantar bienes y servicios lo suficientemente accesibles para ellos.
La tiflotecnología ha logrado grandes avances; a nivel mundial existen organizaciones dentro de las cuales podemos mencionar a La Once (Organización Nacional de Ciegos Españoles), la cual ha sido pionera en el uso de herramientas o dispositivos que ayudan a las personas con esta discapacidad, a ser independientes. También existen escuelas destinadas a la enseñanza completa de estas personas, como son la Lighthouse International en Estados Unidos, encargada de enseñar de manera completa con la finalidad de lograr el desenvolmiento de estos; les proporcionan ayuda en cuanto a la orientación, el uso del computador, el uso del bastón, además de otras actividades, todo con la finalidad de que cada uno de ellos no pase a ser una carga para sus familias, sino que sean personas independientes y capaces de desenvolverse tanto tecnológicamente como en las relaciones de su vida diaria.
La metodología aplicada en esta investigación es documental, ya que trata de ver lo que existe hoy en día, cómo se puede mejorar y cómo se pueden crear herramientas que verdaderamente sean útiles para el trabajo diario, ya que no tendría ningún sentido desarrollar aplicaciones sin tomar en cuenta a los usuarios interesados acerca de cómo se les puede ayudar.
Palabras Claves: Hardware, Software, Software Libre, Tiflotecnología, Discapacidad, Discapacidad Visual.

Este es uno de los tantos articulo arbitrado realizado en el proceso de postgrado, luego explicare las fases y las herramientas a usar.

Sábado 12 de septiembre de 2015

Instalar Samba en Debian

Primero que nada hacemos la instalación del paquete
root@orthanc:/home/julioh# aptitude install samba

En nuestro home creamos el nombre de una carpeta que vamos a usar para compartir
mkdir share
chmod 777 share

Luego modificamos el archivo de configuración de samba

root@orthanc:/home/julioh# nano /etc/samba/smb.conf


# Samba config file created using SWAT
# from UNKNOWN (192.168.42.219)
# Date: 2014/05/15 14:19:36
[global]
server string = %h server
map to guest = Bad User
obey pam restrictions = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
dns proxy = No
usershare allow guests = Yes
panic action = /usr/share/samba/panic-action %d
idmap config * : backend = tdb
hosts allow = 127.0.0.1, 192.168.41.0/24, 192.168.40.0/24
#hosts deny = 0.0.0.0/0
#Comentamos el HostDeny para que me acepte los rangos de ip #de nuestra red interna
#[homes]
# comment = Home Directories
# valid users = %S
# create mask = 0700
# directory mask = 0700
# browseable = No

#[printers]
# comment = All Printers
# path = /var/spool/samba
# create mask = 0777
# printable = Yes
# print ok = Yes
# browseable = No
[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
[SALA]
comment = Archivos Compartidos
path = /home/julioh/share
#admin users = root, SalaP, sala01, sala02
#username = root
#hosts allow = 192.168.41.0
#read list = @users
#public = yes
#only guest = yes
#Le descomentamos para que puedan escribir
writable = yes
read only = yes
valid users = SalaP, root, sala01, sala02
write list = SalaP, root, sala01, sala02
# Lineas agregadas
# crear archivos con permisos rxw
create mask = 0700
# crear directorios con permisos rxw
directory mask = 0700

Luego Detenemos el demonio y lo volvemos a levantar
root@orthanc:/home/julioh# /etc/init.d/samba restart
[ ok ] Stopping NetBIOS name server: nmbd.
[ ok ] Starting NetBIOS name server: nmbd.
[ ok ] Stopping SMB/CIFS daemon: smbd.
[ ok ] Starting SMB/CIFS daemon: smbd.
[ ok ] Stopping Samba AD DC daemon: samba

Luego de esos podremos compartir archivos en un directorio seguro para una red interna.

Lunes 07 de septiembre de 2015

Sergio A. Alonso

Sergio A. Alonso
Bunker Blog

Shot of work's laptop




A typical work session with Arch, Mate Window Manager, Numix Theme + my own colors.

Vim Janus with Molokai theme, Oh-my-zsh with Agnoster theme, Terminator, Tig, and Fuck correct typos. 

Wallpaper is one of my favorites related to Owl's Moving Castle, downloadable from here: http://www.allmacwallpaper.com/get/iMac-21-inch-wallpapers/-Howl's-Moving-Castle-1920x1080/5226-9.jpg

Jueves 02 de julio de 2015

Che … ¿y los datos?

Hace mas de un año, en abril de 2014, hice una presentación sobre Gobierno Abierto / Datos Abiertos para Libres del Sur / FAP.

En dicha presentación me enteré que dentro de la Secretaría de Desarrollo Tecnológico se había iniciado un proceso de apertura de datos de la administración municipal.

Como con todo aquello que hace el Intendente Pulti, me pareció bien la iniciativa pero me reservé las opiniones para mas adelante, ya que su costumbre siempre es patear para adelante y esperar que los reclamantes se cansen.

Ah, y también hacer mucha parafernalia y ruido con poquitas nueces.

Así fue como apareció el “Portal de Datos Abiertos” de la MGP. Y se hizo un Hackaton. Y un Concurso de Aplicaciones.

Me voy a referir al primer punto, el portal de datos abiertos.

Se suponía que allí uno iba a poder encontrar la información que necesitara sobre la Municipalidad y la ciudad, en formatos libres y abiertos, y actualizada.

Lo que realmente se encuentra (con la excepción de los datos de llamadas al 147, que parecen ser extraídas directamente del sistema que usa el call center), es todo lo que publicaron hace un año y olvidaron ahí.

Asi se ve la parte sobre datos sobre seguridad:

datos_seguridad_20150701

Así los referidos a medio ambiente:

datos_medioambiente_20150701

datos_medioambiente_osse_20150701

Los de movilidad:

datos_movilidad_20150701

Los de economía y presupuesto:

datos_economía_20150701

datos_presupuesto_20150701

Adicionalmente, en la página de Información Presupuestaria, los archivos que hasta el 2014 se publicaban en formato de planilla de cálculo, ahora han pasado a estar publicados en pdf, dificultando así cualquier análisis que uno quiera hacer, u obligando a convertirlos, con los problemas que implica cuando se tratan de datos en esquemas de tablas.

Todo sigue igual. O peor. Pero manteniendo el relato.

Domingo 17 de mayo de 2015

25 años de Internet en Argentina

patchcord_keyboardHoy es el día en que se conmemora el “día de Internet”. En realidad, el Día Mundial de las Telecomunicaciones y de la Sociedad de la Información, pero a veces es bueno simplificar un poco 😉 .

Este festejo surge de una propuesta de la Cumbre Mundial sobre la Sociedad de la Información, que pidió a la Asamblea General de las Naciones Unidas instituir el 17 de mayo como Día Mundial de la Sociedad de la Información, lo cual resultó decidido en forma afirmativa. Luego, la ITU (International Telecommunication Union) decide unificarlo con su Día de las Telecomunicaciones, dado que en esta fecha, y de eso también hoy se festejan los 150 años, se fundaba dicha unión.

Pero, lo que es la casualidad, resultó que un día 17 de mayo de 1990, en la ciudad de Buenos Aires y de la mano de Jorge Amodio, Argentina ponía en marcha su primer enlace a Internet.

Como fue que esto sucedió pueden leerlo en el blog del propio Amodio, haciendo click aquí.

También destaco este documento histórico: el e-mail en el cual se informa al administrador en USA que el enlace estaba funcionando.

>From pete Thu May 17 19:55:20 1990
>Subject: Line up ….
>To: atina!umd5.umd.edu!rcoltun (Rob Coltun)
>Date: Thu, 17 May 90 19:55:20 GMT-3:00
>
> Hi Rob,
>
> glad to contact you again, and very glad now because I’m
>looking the Cisco console showing “line up” over our link.
>
> I sent to Glenn the formal Internet Number and Autonomus
>System registration.
>
> Can you help me with the configuration of the Cisco router,
>I believe that we are able to do real networking tests ( your words
>sometime ago ) …
>
> I’ll wait your response,
>
> Best regards,
> Jorge.

Por esto es que quiero enviar mi saludo y las felicitaciones a quienes fueron los pioneros de Internet en Argentina, los que tras 25 años nos han dejado un legado de posibilidades extrarordinarias.

Gracias colegas!!!

Domingo 05 de abril de 2015

A 10 años del ICANN Meeting en Mar del Plata

Hace 10 años, un día 4 de abril de 2005, se iniciaba en Mar del Plata el ICANN Meeting XXII, el primero en ser realizado en nuestro país.

No fue casualidad que se haya organizado en la ciudad donde vivo. Un año antes, un grupito de marplatenses propusimos que se hiciera en nuestra ciudad y tuvimos la suerte de que los costos de alojamiento y comida estuvieran, en ese momento, bastante mas bajos que en la Ciudad de Buenos Aires, lo que nos dio ventaja en la decisión final de donde se hacía.

Y así empezó esta aventura que hoy es uno de los mas gratos recuerdos de mi vida profesional.

El evento se llevó a cabo en el Hotel Sheraton de Mar del Plata, quien tuvo que acelerar la instalación de su red inalámbrica para poder brindar la conectividad a los que terminaron siendo 604 participantes de 80 países distintos, con 60 APs

La conectividad a Internet se contrató a Comsat, quien tuvo que poner dos parabólicas de 2.5 metros de diámetro para poder brindar los 10 mbps simétricos que nos solicitaron con un rango /23 para contar con 512 Ips.

6 servidores DHCP, DNS y SMTP, con una estación de monitoreo de red, 20 PCs de uso público, transmisión en vivo de las reuniones y hasta hacer de service de los equipos que se le iban rompiendo a los miembros de ICANN.

Todo el grupo estuvo compuesto por gente de primera.

En la organización, Oscar García, del Polo Informático Mar del Plata, Antonio Harris, de Cabase, OTI Internacional en los servicios turísticos y Congress Rental en servicios de audio, video en pantalla gigante, registración, traducción, etc.

En la técnica, Steve Conte, Alexander Kulik, Tim Cole y Mike Evans, de ICANN, Guillermo Pereira Irujo, Claudio Roulliet, Alexis Bertola, Martín Salinas y yo, de Comtron, Marcelo Valencia y Hector Blanche, de Comsat, Juan Gimeno Rossi y German Paak, del Hotel Sheraton.

Y, a continuación, la “medalla” que nos quedó de recuerdo, con la firma, nada mas y nada menos, que de Vinton Cerf.

Para el final, el agradecimiento a Ignacio Marcos, que pasó una tarde para conocernos personalmente y que terminó a un costado, tomando un mate y mirándonos ir de un lado para otro, ya que gracias a el y a esa visita este blog existe como tal.

Jueves 06 de noviembre de 2014

Martín Albisetti

Martín Albisetti
Martin Albisetti's blog

Click packages and how they’ll empower upstreams

As the pieces start to come together and we get closer to converging mobile and desktop in Ubuntu, Click packages running on the desktop start to feel like they will be a reality soon (Unity 8 brings us Click packages). I think it's actually very exciting, and I thought I'd talk a bit about why that is.

First off: security. The Ubuntu Security team have done some pretty mind-blowing work to ensure Click packages are confined in a safe, reliable but still flexible manner. Jamie has explained how and why in a very eloquent manner. This will only push further an OS that is already well known and respected for being a safe place to do computing for all levels of computer skills.
My second favorite thing: simplification for app developers. When we started sketching out how Clicks would work, there was a very sharp focus on enabling app developers to have more freedom to build and maintain their apps, while still making it very easy to build a package. Clicks, by design, can't express any external dependencies other than a base system (called a "framework"). That means that if your app depends on a fancy library that isn't shipped by default, you just bundle it into the Click package and you're set. You get to update it whenever it suits you as a developer, and have predictability over how it will run on a user's computer (or device!). That opens up the possibility of shipping newer versions of a library, or just sticking with one that works for you. We exchange that freedom for some minor theoretical memory usage increases and extra disk space (if 2 apps end up including the same library), but with today's computing power and disk space cost, it seems like a small price to pay to empower application developers.
Building on top of my first 2 favorite things comes the third: updating apps outside of the Ubuntu release cycle and gaining control as an app developer. Because Click packages are safer than traditional packaging systems, and dependencies are more self-contained, app developers can ship their apps directly to Ubuntu users via the software store without the need for specialized reviewers to review them first. It's also simpler to carry support for previous base systems (frameworks) in newer versions of Ubuntu, allowing app developers to ship the same version of their app to both Ubuntu users on the cutting edge of an Ubuntu development release, as well as the previous LTS from a year ago. There have been many cases over the years where this was an obvious problem, OwnCloud being the latest example of the tension that arises from the current approach where app developers don't have control over what gets shipped.
I have many more favorite things about Clicks, some more are:
- You can create "fat" packages where the same binary supports multiple architectures
- Updated between versions is transactional so you never end up with a botched app update. No more holding your breath while an update installs, hoping your power doesn't drop mid-way
- Multi-user environments can have different versions of the same app without any problems
- Because Clicks are so easy to introspect and verify their proper confinement, the process for verifying them has been easy to automate enabling the store to process new applications within minutes (if not seconds!) and make them available to users immediately

The future of Ubuntu is exciting and it has a scent of a new revolution.

Martes 30 de septiembre de 2014

Sergio A. Alonso

Sergio A. Alonso
Bunker Blog

El Mundo Según JuanCPovE: Día de la Tierra, ese pequeño punto azul pálido en...

El Mundo Según JuanCPovE: Día de la Tierra, ese pequeño punto azul pálido en...: Siempre en este día cito a Carl Sagan y su obra "Pale Blue Dot". Una buena razón para reflexionar y cambiar de una buena vez nue...

Lunes 01 de septiembre de 2014

PCTux: Mejorar la velocidad de carga de aplicaciones con Prelink

Jueves 31 de julio de 2014

Martín Albisetti

Martín Albisetti
Martin Albisetti's blog

Engineering management

I'm a few days away from hitting 6 years at Canonical and I've ended up doing a lot more management than anything else in that time. Before that I did a solid 8 years at my own company, doing anything from developing, project managing, product managing, engineering managing, sales and accounting.
This time of the year is performance review time at Canonical, so it's gotten me thinking a lot about my role and how my view on engineering management has evolved over the years.

A key insights I've had from a former boss, Elliot Murphy, was viewing it as a support role for others to do their job rather than a follow-the-leader approach. I had heard the phrase "As a manager, I work for you" a few times over the years, but it rarely seemed true and felt mostly like a good concept to make people happy but not really applied in practice in any meaningful way.

Of all the approaches I've taken or seen, a role where you're there to unblock developers more than anything else, I believe is the best one. And unless you're a bit power-hungry on some level, it's probably the most enjoyable way of being a manager.

It's not to be applied blindly, though, I think a few conditions have to be met:
1) The team has to be fairly experienced/senior/smart, I think if it isn't it breaks down to often
2) You need to understand very clearly what needs doing and why, and need to invest heavily and frequently in communicated it to the team, both the global context as well as how it applies to them individually
3) You need to build a relationship of trust with each person and need to trust them, because trust is always a 2-way street
4) You need to be enough of an engineer to understand problems in depth when explained, know when to defer to other's judgments (which should be the common case when the team generally smart and experienced) and be capable of tie-breaking in a technical-savvy way
5) Have anyone who's ego doesn't fit in a small, 100ml container, leave it at home

There are many more things to do, but I think if you don't have those five, everything else is hard to hold together. In general, if the team is smart and experienced, understands what needs doing and why, and like their job, almost everything else self-organizes.
If it isn't self-organizing well enough, walk over those 5 points, one or several must be mis-aligned. More often than not, it's 2). Communication is hard, expensive and more of an art than a science. Most of the times things have seemed to stumble a bit, it's been a failure of how I understood what we should be doing as a team, or a failure on how I communicated it to everyone else as it evolved over time.
Second most frequent I think is 1), but that may vary more depending on your team, company and project.

Oh, and actually caring about people and what you do helps a lot, but that helps a lot in life in general, so do that anyway regardless of you role  🙂

Jueves 15 de mayo de 2014

Martín Albisetti

Martín Albisetti
Martin Albisetti's blog

A story on finding an elusive security bug and managing it responsibly

Now that all the responsible disclosure processes have been followed through, I’d like to tell everyone a story of my very bad week last week. Don’t worry, it has a happy ending.

 

Part 1: Exposition

On May 5th we got a support request from a user who observed confusing behaviour in one of our systems. Our support staff immediately escalated it to me and my team sprung into action for what ended up being a 48-hour rollercoaster ride that ended with us reporting upstream to Django a security bug.

The bug, in a nutshell, is that when the following conditions lines up, a system could end up serving a request to one user that was meant for another:

- You are authenticating requests with cookies, OAuth or other authentication mechanisms
- The user is using any version of Internet Explorer or Chromeframe (to be more precise, anything with “MSIE” in the request user agent)
- You (or an ISP in the middle) are caching requests between Django and the internet (except Varnish’s default configuration, for reasons we’ll get to)
- You are serving the same URL with different content to different users

We rarely saw this combination of conditions because users of services provided by Canonical generally have a bias towards not using Internet Explorer, as you’d expect from a company who develops the world’s most used Linux distribution.

 

Part 2: Rising Action

Now, one may think that the bug is obvious, and wonder how it went unnoticed since 2008, but this really was one was one of those elusive “ninja-bugs” you hear about on the Internet and it took us quite a bit of effort to track it down.

In debugging situations such as this, the first step is generally to figure out how to reproduce the bug. In fact, figuring out how to reproduce it is often the lion’s share of the effort of fixing it.  However, no matter how much we tried we could not reproduce it. No matter what we changed, we always got back the right request. This was good, because it ruled out a widespread problem in our systems, but did not get us closer to figuring out the problem.

Putting aside reproducing it for a while, we then moved on to combing very carefully through our code, trying to find any hints of what could be causing this. Several of us looked at it with fresh eyes so we wouldn’t be tainted by having developed or reviewed the code, but we all still came up empty each and every time. Our code seemed perfectly correct.

We then went on to a close examination of all related requests to get new clues to where the problem was hiding. But we had a big challenge with this. As developers we don’t get access to any production information that could identify people. This is good for user privacy, of course, but made it hard to produce useful logs. We invested some effort to work around this while maintaining user privacy by creating a way to anonymise the logs in a way that would still let us find patterns in them. This effort turned up the first real clue.

We use Squid to cache data for each user, so that when they re-request the same data, it’s queued up right in memory and can be quickly served to them without having to recreate the data from the databases and other services. In those anonymized  Squid logs, we saw cookie-authenticated requests that didn’t contain an HTTP Vary header at all, where we expected it to have at the very least “Vary: Cookie” to ensure Squid would only serve the correct content all the time. So we then knew what was happening, but not why. We immediately pulled Squid out of the middle to stop this from happening.

Why was Squid not logging Vary headers? There were many possible culprits for this, so we got a *lot* of people were involved searching for the problem. We combed through everything in our frontend stack (Apache, Haproxy and Squid) that could sometimes remove Vary headers.

This was made all the harder because we had not yet fully Juju charmed every service, so could not easily access all configurations and test theories locally. Sometimes technical debt really gets expensive!

After this exhaustive search, we determined that nothing our code removed headers. So we started following the code up to Django middlewares, and went as far as logging the exact headers Django was sending out at the last middleware layer. Still nothing.

 

Part 3: The Climax

Until we got a break. Logs were still being generated, and eventually a pattern emerged. All the initial requests that had no Vary headers seemed for the most part to be from Internet Explorer. It didn’t make sense that a browser could remove headers that were returned from a server, but knowing this took us to the right place in the Django code, and because Django is open source, there was no friction in inspecting it deeply.  That’s when we saw it.

In a function called fix_IE_for_vary, we saw the offending line of code.

del response['Vary']

We finally found the cause.

It turns out IE 6 and 7 didn’t have the HTTP Vary header implemented fully, so there’s a workaround in Django to remove it for any content that isn’t html or plain text. In hindsight, if Django would of implemented this instead as a middleware, even if default, it would have been more likely that this would have been revised earlier. Hindsight is always 20/20 though, and it easy to sit back and theorise on how things should have been done.

So if you’ve been serving any data that wasn’t html or plain text with a caching layer in the middle that implements Vary header management to-spec (Varnish doesn’t trust it by default, and checks the cookie in the request anyway), you may have improperly returned a request.

Newer versions if Internet Explorer have since fixed this, but who knew in 2008 IE 9 would come 3 years later?

 

Part 4: Falling Action

We immediately applied a temporary fix to all our running Django instances in Canonical and involved our security team to follow standard responsible disclosure processes. The Canonical security team was now in the driving seat and worked to assign a CVE number and email the Django security contact with details on the bug, how to reproduce it and links to the specific code in the Django tree.

The Django team immediately and professionally acknowledged the bug and began researching possible solutions as well as any other parts of the code where this scenario could occur. There was continuous communication among our teams for the next few days while we agreed on lead times for distributions to receive and prepare the security fix,

 

Part 5: Resolution

I can’t highlight enough how important it is to follow these well-established processes to make sure we keep the Internet at large a generally safe place.
To summarise, if you’re running Django, please update to the latest security release as quickly as possible, and disable any internal caching until then to minimise the chances of hitting this bug.

If you're running squid and want to check if you could be affected, here's a small python script to run against your logs we put together you can use as a base, you may need to tweak it based on your log format. Be sure to run it only against cookie-authenticated URLs, otherwise you will hit a lot of false positives.

Jueves 04 de octubre de 2012

LugSaJu: La tecla que te salva del DESASTRE

Jueves 09 de agosto de 2012

Dear Martínez

Dear Martínez
La vida Linux

Software de mensajería instantánea Jitsi 1.0

La competencia entre los programas de mensajería instantánea a través de VoIP, video conferencia y más, es grande y todas satisfacen nuestras necesidades. Competidores somo Skype, Ekiga, lideran el poderío de uso, pero existen otras alternativas menos utilizadas por no ser famosas, pero de mejor dicción y predisposición de servicio al usuario, tal como Jitsi, antes conocido como SIP Communicator y que desde hace tan solo días, ha lanzado su nueva versión estable.

Jitsi 1.0 Software de mensajería instantánea Jitsi 1.0

El renovado Jitsi 1.0 reúne todas las funciones que se pueden encontrar en diversos programas con las herramientas VoIP, video conferencia, mensajería instantánea tanto para Windows como para Mac y GNU/Linux. Esta interfaz es sumamente cómoda y amigable, siendo intuitiva y fácil de utilizar. Es compatible con los protocolos más populares de mensajería instantánea y telefonía, pero también se le puede dar uso con las cuentas habituales de correo tales como Hotmail, Gmail o Yahoo, o bien otros como AIM, XMPP, Jabber, SIP y la posibilidad de emparejar la cuenta de la red social Facebook.

Entre sus características más destacadas se encuentra la de transferencia de llamadas atendidas o ciegas, el cambio de estado automático cuando el usuario no se encuentre utilizando el ordenador, la autoconexión, además de permitir grabar las llamadas para seguridad del usuario y el cifrado de protocolos SRTP Y ZRTP. No obstante, también permite establecimiento de conexión de medios directa mediante protocolo ICE, streaming de escritorio, almacenamiento de contraseñas cifradas, transferencia de archivos, soporte IPv6 para SIP y XMPP, etc.

 

Jueves 02 de agosto de 2012

Dear Martínez

Dear Martínez
La vida Linux

Aprende a tocar la guitarra con TuxGuitar

Un nuevo software para los amantes de la guitarra y la música, además de para aquellos aficionados que siempre quisieron aprender, existe una herramienta llamada TuxGuitar, siendo un editor visual de tablaturas y partituras de código abierto. Esta aplicación ha de ser ideal para llevarla consigo a cualquier parte. Desarrollada hace tiempo, es una idea que surgió para crear una herramienta que le haga competencia al popular Guitar Pro, pero que esta pueda ser utilizada por todo el mundo de forma gratuita.

Tux Guitar Aprende a tocar la guitarra con TuxGuitar

La herramienta de Tux Guitar es muy útil para el aprendizaje de la música y el arte de utilizar cualquier guitarra, aunque también cuenta con bajo, teclado y batería con el cual el usuario podrá aprender lo que no, o poner en práctica lo conocido en la materia. Desarrollado por la compañía Java, se puede abrir y exportar ficheros GP3, GP4 y GP5, además de ser compatible con los archivos del Guitar Pro, permitiendo que se pueda utilizar las partituras creadas para ese programa.

No solamente el Tux Guitar es un simple editor visual de partituras con el que se puede componer la música, sino también ofrece una gran variedad de efectos de sonido, soporte multipista, tempo, posibilidad de tercetos, scroll automático en la reproducción y muchas otras herramientas que lo ayudarán a formar su música tal como la disponga.

Lunes 16 de julio de 2012

Dear Martínez

Dear Martínez
La vida Linux

Nueva versión de MythTV 0.25 con soporte para Windows

El conocido reproductor de TV se ha escondido en la sombra de las noticias tecnológicas respecto a Linux durante un año y medio, sin tener novedades de ellas y varios retrasos en el desarrollo de la última versión del reproductor, por lo que MythTV anunció que ha sido liberado y trae 5200 cambios como si fuera poco. Muchos saben en qué consiste este software reproductor de TV y multimedia, por lo que les interesará saber sobre las novedades de cambios.

MythTV Nueva versión de MythTV 0.25 con soporte para Windows

En la versión 0.25 de MythTV se incluyen nuevas características que destacan el interés en los usuarios, como nuevas capacidades de aceleración de video, tales como VAAPI y video de DirectX2, mejoras de audio, incluyendo soporte para E-AC3, TrueHD y DTS-HD, mejoras de los metadatos que integra gestión de grabaciones y videos, una API para aplicaciones de terceros, para aprovechar la interacción con el frontend y backend, control del televisor y otros componentes AV a través del consumer electronics control, o la inclusión de un HTTP Live Streaming, para compartir el contenido de video en tiempo eral a través de la API integrada.

También se destaca en el nuevo reproductor MythTV, el MythMusic que ha sido completamente reescrito y MythVideo que ahora se ha integrado completamente, en lugar de ser distribuido como un plug-in por separado. Además, a través de MythThemes, todos los temas, incluyendo los de terceros, se pueden descargar directamente desde el selector de temas de la interfaz.

 

Jueves 05 de abril de 2012

Soft-Libre: GNOME 3.4 disponible con interesantes novedades
Soft-Libre: Wallpapers para Ubuntu 12.04 LTS
Soft-Libre: LibreOffice adquiere capacidad colaborativa en la nube + LibreOffice 3.5.2

Domingo 26 de febrero de 2012

Luciano Bello

Luciano Bello
Luciano's webpage

Lessons Learned: Fettisdagen y Semla

Fettisdagen, (martes de carnaval). Fet es grasa, mientras tisdag es martes. El sufijo en es el artículo determinado. Por lo tanto, el martes graso

Semla, Comida. Etimológicamente, viene de semilla. También llamado fastlagsbulle, es una berlinesa (bola de fraile, que le dicen) con crema y pasta de almendras en su interior.

SemlaFlickr
En el post sobre Lucía ya hemos hablado sobre lo sorprendentemente apegado que son los suecos a ciertas fiestas de origen religioso, incluso cuando solo el 23% de ellos dice cree en algo llamado dios (ya no decir "ser cristiano"). Este parece ser un nuevo caso de lo mismo.

En Argentina, así como en muchos (por no decir todos) países de América existe el carnaval. En otras palabras, festejar y comer antes de los 40 día de ayuno y penitencia por la Cuaresma que comienza el día siguiente, es decir, el Miércoles de Ceniza.

Acá, y en otros países nórdicos, no parece haber carnaval. Lo que sí hay es Fettisdagen. Éste podría ser un martes de lo más común, si no fuese porque se consumen enormes cantidades de semla.

Casualmente, ese martes me tocó ser el anfitrión del PhD fika (cuando los estudiantes de doctorado nos juntamos a tomar café y conversar), por lo me subí a la tradición y los invité con semla de distintos sabores. El sabor está dado por la crema, que puede ser común, de vainilla, con canela y otras variantes.

Los semlor (plural de semla) es algo tan popular en la cultura sueca que un detective de cuentos para chicos llamado Ture Sventon es adicto a estos (y también vuela en una alfombra mágica, pero no viene al caso).

Y este podría no ser único caso sueco de adición a semla. En el siglo XVII, rey Adolfo Federico habría muerto (literalmente) de un atracón después de clavarse 14 porciones de semla (tradicionalmente servidos con un tazón de leche caliente) como postre.

La receta, aquí.

Domingo 15 de enero de 2012

Luciano Bello

Luciano Bello
Luciano's webpage

Corriendo Debian en un server fanless

Debido a una reciente mudanza, he bajado unos servers que tenía corriendo en casa de mis padres. Sin embargo, en mi nuevo hogar estoy en proceso de generar una nueva DMZ, esta vez, sin ventiladores.

El primer paso de este proceso ocurrió en forma de weekend project y consiste en hacerme de un "servidor". Las comillas hacen referencia a que no se trata de un gran server sino un procesador ARM de 200Mhz y 32MB de RAM, lo que es suficiente para que corra Debian y algunos otros servicios que pueden ser interesantes.

Los ingredientes

  • Un all-in-one LAN server que es la forma en que DealExtreme llama a unos dispositivos con chips de la familia str8132. Dado que vamos a instalar snake-os en ellos (en este caso se trata de la versión 1.3.2-20111019), es importante chequear la lista de compatibilidad. En particular me hice de un NS-K330 por 40 dólares.
  • Storage USB, puede ser en la forma de stick o como disco portable.
  • Un RS232 to TTL level converter, también conocido como cable para Nokia N1200/1208/1650/2630/2670. Es para conectarse por serie a la consola. No lo necesitamos ahora mismo, pero está bueno tenerlo a mano en caso de brickearlo, aunque es un procedimiento que no explicaré esta vez.

Instalación de Snake-OS

Es realmente sencillo. Lo primero es bajar snake-os, desde la sección de downloads de la web. Es importante que el archivo sea de la forma snakeos-<versión>-from-original.zip Instalar el que dice from-snake lleva definitivamente al brickearlo y recuperarlo puede ser complejo.
Desde la página de administración del dispositivo hay que subir el archivo snakeos-<versión>-from-original.bin contenido en el zip bajado. Confirmar el md5sum no está de más.

Acceso inicial

Los datos para acceder a la nueva interfaz con el browser:

http://192.168.0.240 (si es que no hay un DHCP en la red)
usuario: admin
contraseña: snake

Por SSH la contraseña de root la misma y, al cambiarla por la página de administración, se cambia en todos los accesos.

Post instalación

Incluso cuando Max opine que el uso de memoria virtual está rumbo a la extinción (lo cierto es que tal vez no es la mejor idea cuando el storage es de estado sólido como en los pendrives), activé el uso de SWAP desde el menú Service-Swapfile.

Si se quieren las mismas prestaciones que se tenían con el firmware original, hay que instalar unos paquetes adicionales. El sistema de paquetes que utiliza snake-os es opkg y tiene que ser primero activado desde Service-Opkg. Los paquetes pueden bajarse desde la página de download de snake-os y se instalan desde System-Packages. En particular, pueden ser interesantes (siempre pensando en los features originales):
Transmission: Es un cliente de BitTorrent, para dejar tus descargas corriendo. Es bastante mejor que el original.
miniDLNA: Es el server de streaming compatible con DLNA/UPnP-AV. Está un poco verde, pero se está trabajando en su mejora.

Corriendo Debian dentro

Las instrucciones están acá. Aunque esto es lo más obvio y necesario:

wget http://snake-os.googlecode.com/files/debian_chroot.tgz
tar -xvf debian_chroot.tgz
mount -o bind /proc /usb/sda1/debian/proc
mount -o bind /dev /usb/sda1/debian/dev
chroot /usb/sda1/debian/

Esta instalación base requiere unos 200MB. Tiene todo el potencial de un Debian (¡porque lo es!).
Claro que falta ajustar varios detalles, pero será la piedra inicial para el resto.

Lunes 12 de diciembre de 2011

Luciano Bello

Luciano Bello
Luciano's webpage

Lessons Learned: Lucia

Lucia, fiesta (13 de diciembre). Tradicional fiesta sueca asociada a Santa Lucía de Siracusa, el solsticio y las velas.

Según el santoral católico, el 13 de Diciembre (o sea, en un par de horas) es el día dedicado a Santa Lucía. Dato que seguramente pasa totalmente desapercibido para la gran mayoría de la personas del mundo. A menos claro, que se sea habitante de Suecia (o de Sicilia, pero no viene al caso).

El día de Santa Lucía, o simplemente Lucia como prefieren llamarlo acá, es de la fiestas más importantes de la cultura sueca. Y, como extranjero, me es sumamente difícil de entender como en un país tan poco religioso algo así tiene cabida. Así que analicemos los hechos.

La santa en cuestión: Durante el siglo III y principios del IV vivió en Siracusa (una ciudad de Sicilia, Italia) una joven católica de familia potentada llamada Lucía, quien tenía intensiones de consagrarse a Dios. Pero un despechado pretendiente la denunció a la autoridades (eran tiempos de persecución a los católicos) y fue enjuiciada y sentenciada a muerte. La tradición cuenta que se ordenó torturarla arrancándole los ojos y que aún así siguió viendo por milagro divino (sí, lo que tiene en la bandeja de la estampita son un par de ojos). Más datos sobre su vida en la Wikipedia y referencias.
Es, obviamente, patrona de los ciegos. También, aunque bastante menos evidentemente, de los electricistas, choferes, afiladores y cristaleros. Tal vez en este último caso exista alguna relación con el tradicional arte de soplar vidrio que existe en Suecia.

Su asociación con la luz: El nombre Lucía, hace clara referencia al latín, Lux. La leyenda de los ojos también parecen referir a la luz (o a la falta de ésta). Aunque no pude encontrar referencias, algunas personas me comentan que Santa Lucía fue condenada a la hoguera y que el fuego no la consumía. Y que por esto hay velas durante la celebración. Aún más simpático es que parece ser que, por errores acumulados durante la Edad Media en el calendario Juliano, la festividad de Lucía coincidía con el día más corto del año, el solsticio de invierno.

Conociendo lo odioso que puede ser la oscuridad en estos lares y lo fanático de las velitas y de los artefactos lumínicos que son lo locales, no parece ser tan loco que quieran festejar que los días empiezan a alargarse (aunque esto no ocurrirá hasta dentro de poco más de una semana).

Las velas también pueden hacer referencia a una leyenda pre-cristina en que la noche más larga del año lo animales nocturnos adquirían poderes sobrenaturales (incluso podían hablar) y había que mantenerlos alejados con fuego.

Luciatåg: Significa procesión de Lucia. Es el acto por excelencia y se celebra totalmente independiente de la fiesta religiosa. Se realiza en escuelas (especialmente en las guarderías) y en ámbitos públicos en donde una mujer representa a Lucia llevado "la luz" con una corona de velas (electrónicas en muchos casos, matando cierta divertida tensión macabra). La vestimenta es una túnica blanca ceñida por una faja roja, representando el martirio. Las tärnor (literalmente, golondrinas, aunque también puede ser las damas de honor o doncellas) acompañan a Lucia llevando velas en las manos y cantando canciones tradicionales. Hay más personajes, pero quedarán para otro post.

Entre las muchas tradiciones gastronómicas asociadas a esta época del año, hay una que hace referencia directa a Lucia: los lussekatter. Son como unas facturas dulces de azafrán y que representan ojos. La palabra lussekatt se traduce como gatos de Lucia y se suele acompañar con Glögg, una especie de glühwein local.

Para terminar, durante esta fecha se elige en Estocolmo la Sveriges Lucia. Es una especie de concurso por representar a Lucia a nivel nacional en donde cada ciudad propone su candidata. Las participantes representan a una entidad de beneficencia y tengo entendido que se valoran las cualidades para canto y la personalidad con entrevistas que son televisadas. Se puede votar por tu Lucia favorita a través de SMS, aunque creo que la votación para este año ya está cerrada. ¿Que qué se lleva la ganadora? No tengo idea...

Pero acá les dejo las candidatas finalistas de este año:

Lunes 07 de noviembre de 2011

Punto Libre: サイトマップ

Viernes 01 de abril de 2011

Tecnoscopio: Clon de Counter-Strike Gratis en tu navegador

Miércoles 30 de marzo de 2011

Tecnoscopio: Gestor de Descargas para Megaupload Depositefiles y otros

Lunes 28 de marzo de 2011

Tecnoscopio: Generación de electricidad con peatones y tránsito de autos

Miércoles 09 de marzo de 2011

Punto Libre: デートを成功させる

Martes 09 de noviembre de 2010

Fabián Flores Vadell

Fabián Flores Vadell
Speed Books Argentina

Proyectos

Inicia una nueva etapa que implica materializar la idea, que originalmente tomó forma con este pequeño proyecto, de producir documentación en español sobre tecnologías libres que pudieran tener un nicho de interés en la comunidad y que particularmente interesen a los participantes de este proyecto. Los primeros proyectos que verán la luz estarán relacionados con: La programación con Smalltalk.
Fabián Flores Vadell

Fabián Flores Vadell
Speed Books Argentina

¿Libertad o propiedad? Antorchas en la Biblioteca

A continuación el video y la transcripción de la conferencia de Carlos Sánchez Almeida En este ocaso somos aún antorchas, luz que sobresale en el horizonte. Y, mientras esta muralla resista, seremos custodios de la Palabra divina. - Así sea –dijo Guillermo con tono devoto–. Pero, ¿qué tiene que ver eso con la prohibición de visitar la biblioteca? - Mirad, fray Guillermo –dijo el Abad–,

Domingo 31 de octubre de 2010

Fabián Flores Vadell

Fabián Flores Vadell
Speed Books Argentina

PHP 5 Power Programming

In this book, PHP 5's co-creator and two leading PHP developers show you how to make the most of PHP 5's industrial-strength enhancements in any project—no matter how large or complex. Their unique insights and realistic examples illuminate PHP 5's new object model, powerful design patterns, improved XML Web services support, and much more. Whether you're creating web applications, extensions,