¿Qué demonios está pasando?

Asisto perplejo a las recientes noticias sobre vulnerabilidades encontradas en las implementaciones SSL/TLS tanto de Linux como de iOS. Por si no estáis enterados, os pongo en antecedentes.

A principios de año se liberó una actualización para iOS6, iOS7 y Apple TV 6, y se sabe que también afectaba a OS X 10.9.x. El parche corregía una cagada de las históricas. En post anteriores, os he explicado el mecanismo de funcionamiento de los certificados digitales, su firma y verificación por parte de las CA’s. Pues bien, el problema consistía en el mal funcionamiento de una función, en concreto SSLVerifySignedServerKeyExchange, que, como su nombre bien indica, se encarga de verificar la firma de un mensaje. He aquí el código en cuestión: 

SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa,
                                 SSLBuffer signedParams, uint8_t *signature,
                                 UInt16 signatureLen)
{
            OSStatus            err;
            ...
            if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
                   goto fail;
            if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                   goto fail;
                   goto fail;
            if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
                   goto fail;
            ...
fail:
            SSLFreeBuffer(&signedHashes);
            SSLFreeBuffer(&hashCtx);
            return err;

No hay que ser programador avanzado para darse cuenta del error. Ese segundo goto fail; que os he resaltado, hace que se salga de la función sin haber terminado todas las verificaciones de la firma, dando un resultado válido, aunque el certificado utilizado para firmar sea falso o incluso no exista. Sorprendente, ¿verdad?

Pues ojiplático me quedé al comprobar, pocas semanas después, ya en Marzo, que GnuTLS padecía del mismo, o similar, fallo de programación. Y para no ser menos que nuestros amigos de Cupertino, esta cagada venía arrastrándose desde el 2005, sin que nadie se hubiera dado cuenta…o no es así, y entonces es para echarse a temblar.

Aquí el fallo venía dado por goto’s erróneos, haciendo que el código de error detectado en un certificado, fuera pasado a la instrucción cleanup, en vez de fail. Así, podía darse el caso de que nuestro sistema detectase un certificado erróneo (entiéndase por erróneo, falso o no verificado) y lo diese por válido. La verdad es que no sé qué cagada es peor. Pero no voy a entrar en la prolífica discusión de si es mas seguro Linux o iOS. Sinceramente, me da igual. Porque cuando ya creía haberlo visto todo, hace su aparición estelar….. TACHAN!!!.....Heartbleed.

Este “palabro” viene a describir el fallo de seguridad conocido más importante hasta la fecha (nótese que he subrayado la palabra “conocido”). Si bien los fallos anteriores eran corregidos rápidamente por una simple actualización o parche en nuestros sistemas, nuestro amigo Heartbleed nos tiene, a día de hoy, y perdonarme la expresión, cogidos por las pelotas. Y os voy a explicar porqué.

Los fallos anteriores afectaban a nuestro lado de la comunicación segura. Así, si era lanzada una web “falsa”, nuestros sistemas podían no darse cuenta del error. Pero no pasaba nada si nos conectábamos a nuestro banco, o comprábamos en nuestra tienda habitual de Internet, o accedíamos a nuestro correo web. Las páginas eran válidas y seguras, y no había posibilidad de robo de credenciales o datos de tarjetas, por poner un ejemplo.

Heartbleed hace que el fallo de seguridad resida en el servidor al que nos conectamos. Da igual que lo hagas con Linux, iOS, Windows, Android, señales de humo o tam tam. Los servidores han sido comprometidos, y gravemente.

En este caso, ha sido un teutón llamado Robin Seggelmann el artífice del caos. El pobre hombre debe estar pasando las de Caín y no estoy de acuerdo en realizar un linchamiento público, ya que, si bien es cierto que el error en el código ha sido suyo, no es menos cierto que el sistema de revisión de dicho código por parte de su supervisor ha fallado.

El fallo se encuentra en la implementación OpenSSL, software instalado en multitud de servidores de Internet, que proveen de acceso seguro a protocolos tales como HTTPs o FTPs, por poner un ejemplo. Vamos a destripar el fallo.

En post anteriores os he descrito el uso de certificados digitales. Vamos a repasarlo de nuevo. Estamos sentados en nuestra casita, tranquilos, y decidimos conectarnos para ver si Hacienda nos ha realizado ya la devolución de los impuestos. Cada vez me devuelven menos, por cierto. Gracias Montoro, ya mismo tendré que pagar por trabajar.

Que me voy, que me voy del tema… Si es que me tiráis de la lengua…

En el servidor del banco al que nos conectamos reside su certificado digital, expedido por una CA, con sus claves pública y privada. Al conectarnos, el servidor nos facilita su clave pública, con la que encriptamos la información que le enviamos al Banco. No estoy hablando de credenciales de acceso. Me refiero a que nuestro equipo encripta una serie de información para establecer una comunicación cifrada simétrica con el servidor (recordar que el cifrado simétrico es mucho más rápido que el asimétrico). Así, la información que ciframos con la clave pública del servidor, es descifrada con la clave privada del mismo y se establecen los parámetros para realizar una comunicación cifrada de manera simétrica, utilizando la misma clave de cifrado en ambos lados de la comunicación. Esto es el funcionamiento habitual en una conexión a un servidor seguro. Hasta ahora todo va bien. Y ahora viene la parte complicada. A ver si consigo que todos lo entendamos (yo incluído)

Vamos a hacer una abstracción e imaginar que estamos hablando Frannoe y yo mismo. A ver si así queda claro. Vamos a imaginar que estamos en una conversación telefónica y nos aseguramos de que nuestro interlocutor es realmente quien dice ser.

[Frannoe dixit]
Ya me cogió de conejillo de indias…

[Jose respondere]
Ah… se siente. Haber dedicado el Blog a la cría de gusanos de seda.


F: Hola Jose.
J: Hola Fran
F: La lluvia en Sevilla… (es la clave pública de Fran. Es que es de un poético...)
J: ...buena sombra le cobija (propuesta de clave simétrica, encriptada con la clave pública)
F: Aceptamos barco (aceptada y establecida clave simétrica)

(a partir de aquí va todo cifrado, pero lo dejo en plano)

J: ¿Para cuándo la DMDc 3 en x86, Fran?
F: ¿No has leído mi último post? Que no doy abasto…
J: Si es que te metes en unos berenjenales…
F: Tú tienes parte de culpa, te recuerdo.
J: Espérate Fran, que me hago de vientre…
F: Sin comentarios
.
.
J: Ya he vuelto.
F: Lo siento, ya no estoy seguro de que seas tú realmente. Así que…. La lluvia en Sevilla…
J: (mierda, a empezar de nuevo…)

Para evitar esto, que es una sobrecarga de trabajo enorme para un servidor, se establece un procedimiento por el que le decimos al servidor: “Oye, que soy yo, no me empieces de nuevo la comunicación”. Lógicamente, el procedimiento consiste en el envío de una cierta información desde el cliente, muy similar a un ping. En concreto, lo que se envía desde el cliente al servidor es una estructura de datos llamada TLS1_HB_REQUEST que consiste en dos partes: un mensaje o payload con datos aleatorios y el tamaño de dicho mensaje. Cuando el servidor recibe este mensaje, devuelve una estructura de datos llamada TLS1_HB_RESPONSE, que copia el mensaje recibido y lo envía de vuelta. A este procedimiento se le vino a llamar HEARTBEAT, o latido de corazón, para mantener viva la conexión con el servidor aunque no haya intercambio de datos.

El problema surge aquí. El error consiste en que el servidor no comprueba si los datos enviados en TLS1_HB_REQUEST tienen realmente la longitud indicada en el mensaje. Así que enviamos a nuestro servidor un TLS1_HB_REQUEST de 1 byte, pero indicándole que el tamaño del mismo es de 64 kb (65.535 bytes).

Como el servidor confía ciegamente en que el payload recibido es de 64 kb, procede a generar el TLS1_HB_RESPONSE, copiando el payload original, y completando hasta llenar los 64 kb del mensaje con los datos que en ese momento tiene la memoria RAM del servidor.

[Frannoe dixit]
¿Y qué hay en la memoria RAM del servidor?

[Jose respondere]
Todo, querido amigo. En la RAM del servidor se encuentra ejecutándose OpenSSL, así que tenemos código de OpenSSL, contraseñas, claves de cifrado… Claro, de 64 kb en 64 kb, se tarda en recopilar información, pero potencialmente es infinita.

Así que… ¿en qué situación nos encontramos? Pues para ponernos en el peor de los casos, podemos asumir que todas nuestras claves bancarias y contraseñas de servicios web están comprometidas.

[Frannoe dixit]
Pues las cambio todas y a correr

[Jose respondere]
Es lo mínimo que tienes que hacer...cuando sepas que el servidor al que te conectas ya está parcheado. Te recuerdo que las claves de los certificados de esos servidores pueden haber sido comprometidas. Así que los administradores deberían actualizar dichas claves y/o generar nuevas. Si han sido descubiertas, da igual que cambies tus claves de acceso. Van cifradas con las claves del servidor que han sido comprometidas, ¿recuerdas?.

[Frannoe dixit]
Pero eso ya estará hecho, ¿no? Ha pasado una semana desde que saltó la liebre…

[Jose respondere]
Yo no digo nada, que después todo se sabe… Aquí te dejo un enlace a una herramienta que puedes utilizar para comprobar si el servicio al que te conectas está parcheado o no. Sólo te diré que los que yo he probado (bancos inclusive), me dicen que ya está solucionado (es decir, que ya no se traga el payload de 64 kb), pero advierte que los certificados de los sitios no han sido actualizados….

Y así nos va...


Me parece que voy a dar de baja el Internet, la tele por cable, el móvil y el teléfono fijo… Y vuelta al cartero de toda la vida… y a las postales… qué tiempos...

En breve DMDc 3.0 IL (testing)

Está al caer la versión 3.0 (testing). Por ahora tan solo en 64 bit. A ver que tal funciona.
No hace mucho comenté que iba a esperarme a la liberación de MATE 1.8. El motivo principal es la gran inestabilidad que se produce en algunos procesos en MATE como son con Caja y el Panel. Pensaba que en las sucesivas revisiones esto se iba a solucionar, pero no es así. Y lo suponía así ya que creía que el problema era de MATE. Pues nada mas lejos de la realidad.
Para que os hagáis una idea y para que veáis por vosotros mismo la gravedad de la situación, aquí os dejo un vídeo de un ejemplo practico.
El proceso a seguir para provocar esta situación es tan simple como abrir una carpeta como root (desde el menú contextual) y luego abrir un terminal como usuario normal, y el resultado es el que podéis ver:

Como podéis apreciar, Caja empieza abrir ventanas en un bucle infinito imposible de matar, ni tan siquiera cerrando la sesión. Si no se sabe donde tocar, nos vemos obligados sin remisión a reiniciar el sistema para salir de esta situación.
Pero cuando es el panel el que se queda pillado de este modo, la cosa aún es mucho peor ya consume toda la memoria física y virtual de nuestro sistema en pocos segundos dejándolo patitieso.

Llevo bastante tiempo dándole vueltas a este asunto (desde antes de la liberación 2.0), pero sin coger el toro por los cuernos ya que pensaba que el problema venía de MATE.
Systemd es desde luego una maravilla, el arranque del sistema con él es asombroso. Se reduce el tiempo en más de un 50%. Ya no quiero hablar del cierre del sistema. El Pc se apaga tan rápido que parece que se rompa!..¡Menudo susto!.

El problema en MATE vienen ya que Systemd utiliza la variable de entorno XDG_RUNTIME_DIR que es de obligado acceso tanto tanto para usuario normal como el usuario root. El acceso a esta variable desde gksu(root) a User no hay problema, pero sí los hay (como podemos ver en el vídeo) desde User a root. Este acceso se realiza a una copia del archivo de usuario dconf /user. En este caso lógicamente al ser creada por el usuario root, cualquier otro usuario no tiene acceso (por encontrarse con permisos root) y el sistema se colapsa intentando acceder a ella.

Reportes de ello he visto desde el 2012:
 /run/user/1000/dconf': Permission denied y soluciones ninguna.
Una solución fácil y obvia pero muy drástica, sería eliminar gksu del sistema para imposibilitar abrir aplicaciones gráficas con permisos de root. Pero muchos no estamos dispuestos a prescindir de esta practica utilidad, y por otro lado hay aplicaciones que utilizan gksu como dependencia, con lo cual tampoco podremos utilizar éstas.
No se hasta que punto el problema es de Systemd o más bien que sería necesario una revisión-adaptación de gksu. Hasta lo que yo se, si no utilizamos Systemd todo funciona con normalidad, pero si utilizamos Systemd y eliminamos gksu todo también parece ir con normalidad, así que...

Lo que tenía muy claro, es que para esta versión 3.0 no quería prescindir de Systemd y ya puesto tampoco de mi queridísimo gksu.
Llevo varias semanas dándole vueltas al asunto en busca de alguna solución.
La liberación de la 3.0 con este problema a sido hasta ahora un verdadero quebradero de cabeza, ya que no instalar gksu tan solo sería una solución muy temporal, pues los usuarios (la mayoría), tardarían bien poco en instalarlo al ver que no está y se encontrarían rápidamente con la desagradable sorpresa del que el sistema se les viene abajo a la primera de cambio.

A la espera de que surja algo mejor para solucionarlo definitivamente, al final se me ha ocurrido una pequeña solución (no muy limpia seamos sinceros) pero si lo suficientemente buena y a la vez fácil para evitar este tremendo problema, con lo cual poder disfrutar plenamente de nuestro DMDc 3.0, con todo a la última. Por lo tanto, una vez salvado este escoyo, no hay razón para demorar más la liberación de la 3.0 que tras unos pequeños ajustes será subida en breve. No creo que tarde más de una semana.

Lamentablemente la versión en 32 bit tardará bastante más. Los recursos en personal en dedicación son muy escasos y yo no doy para más. El pasar DMDc a la versión Testing (sin mencionar la reescritura por completo del instalador) me ha traído muchos quebraderos de cabeza y más de un problema como el expuesto anteriormente, pero el resultado al final parece ser mucho mejor de lo esperado...
Como escuché en una bonita película,...

..."Al final, todo saldrá bien... si no ha salido bien, es que entonces aún no es el final"

En preparación de DMDc 3.0

Tengo pensado subir la versión 3.0 tan pronto sea liberada la versión 1.8 de MATE. Como sabéis he estado muy liado reescribiendo el instalador de DMDc y ya creo tenerlo terminado:

También he pulido (a mi entender) bastante el tema del inicio gráfico de plymouth. Podréis elegir entre estos dos themes:

A parte del cambio estético, (pero guardando el mismo estilo) los temas se han aligerado mucho, con lo cual el impacto en el arranque es menor. Y por lo que veo se ha ganado en vistosidad, creo que ahora sí me han quedado bastante bien.

Otro tema también modificado sutilmente (o no) es el de la pantalla de login. Considero que el logo de DMDc en el Sol era demasiado ostentoso. Creo que de este modo gana bastante más, y el logo lo he situado abajo de forma más sutil, sustituyendo el anterior por un sol bastante más realista. También he eliminado el cartelito informativo que aparecía abajo a la derecha:

Por cierto, cualquiera de estos temas ya los tenéis disponibles en los repositorios de DMDc.

Por último comentar que esta versión 3.0 de DMDc estará orientada por completo a la rama Testing de Debia, pero de una forma muy controlada que espero explicar más adelante cuando lo tenga casi todo a punto.

Comparte archivos, carpetas o chatea en tu red local

Buenas tardes a todo el mundo!!!

Quería hablaros de un programa muy sencillo que puede ser de mucha utilidad para los que tengan varios equipos en su red local, el programa en cuestión se llama IPTUX y lo podemos instalar como siempre desde el synaptic o terminal, ya sabéis todos y para el que no pues.....

sudo apt-get install iptux

Venga, instalado, ahora vamos a ver su funcionamiento, la verdad es que aquí hay poco que explicar, porque ya vereis que es muy sencillo e intuitivo, esto es más para el que no lo conozca pues eso, darlo a conocer.

Una vez iniciado, el solito nos buscará los equipos que están conectados en ese momento a la red, y los identifica por su IP (hablo en todo momento de la ip local) y el nombre que tengamos puesto en la configuración para darnos a conocer.

Bueno, ya veis la ip, el nombre del usuario y el nombre de nuestro equipo, ahora os explicaré como hacer para configurarlo, aunque repito es muy muy sencillo su funcionamiento, al menos, para el uso básico que yo le doy, si tiene alguna opción más "compleja" el que lo sepa que me lo explique a mi, jejeje.

 

 

Como veis, poco hay que explicar, como mucho en la última captura de pantalla, en la opción de red, que nos da la opción de elegir el rango de ip's que queramos tener, yo lo he dejado en blanco como veis.

Ahora, vamos a configurar si queremos compartir algún directorio concreto o un archivo, para ello nos iremos  Herramientas / administrador de compartidos y seleccionaremos lo que queremos compartir.

Como podéis ver, podemos establecer una clave para intentar "proteger" un poquito más nuestros archivos o carpetas compartidas, siempre podéis pasar la clave a la persona interesada mientras chateáis.
Para ver lo que comparte esa persona, tienes que situarte sobre el en la ventana principal y pulsando en el botón derecho seleccionas pedir recursos compartidos tal como veis en la captura.

En este caso para que veáis el funcionamiento en la configuración puse una contraseña con lo cual nos encontraremos esto.

Introducimos la contraseña, y entonces nos mostrará los archivos o carpetas compartidas, ya sólo nos queda seleccionar donde queremos guardarlo y ya está.

Si lo que queréis es iniciar una conversación, no tenéis más que hacer doble click con quien queráis hablar y se os abrirá una ventana como esta:

Bueno, y esto es todo, como podéis ver, es un programa muy sencillo, básico y si tienes varios equipos en casa o en tu trabajo pues te puede servir para estar conectado entre ellos y compartir lo que sea, es de esas aplicaciones que siempre instalo, nunca se sabe si te puede hacer falta en algún momento.

Un saludo a todos.

Gestiona tu negocio con Linux (PYMES)

¿Quien dijo que para poder gestionar una empresa necesitaba tener Win...$ instalado?, urrrghhh sólo de pensarlo me da un yuyu.
Bueno, el otro día, en mi trabajo, que dicho sea de paso, mi trabajo con la informática tiene el mismo parentesco que Iron Maiden y Camarón de la Isla, pero bueno, eso es otro tema, estando en un cliente, me sorprendió bastante ver que tenían instalado Linux, más concretamente Ubuntu (vamos, el que más y el que menos de los que andamos en este mundillo, hemos "coqueteado" un poco con esta distro) ¿verdad?, pues eso, que me pareció un poco raro, puesto que creo que el 90% bueno, por decir algún porcentaje, usan Win...$ urrrghhhh otra vez.
Hablando con el responsable del almacén, le pregunté sobre que programa utilizaban para gestionar el almacén y demás y me comentó que utilizaban "ENEBOO", pues ya os podéis imaginar, me faltó tiempo cuando llegué a casa para empezar a buscar información, pensando que era un "software" creado por alguna empresa concreta para ellos, pero NO, mira tu por donde, hay muchísima información sobre ellos en su pagina.
Os dejo el enlace a su pagina que de todos modos lo explica bastante bien, yo intentaré hacerlo a mi manera.

enlace a pagina oficial eneboo 

Venga, vamos a por faena, una vez estemos en su pagina web, nos iremos a la sección de descargas y seleccionaremos la ultima versión estable, en este caso es la Eneboo 2.4.0.2 y una vez descargado nos iremos a la sección que pone módulos y descargaremos el paquete que pone: standar.eneboopkg

Bueno, ya lo tenemos descargado y descomprimido, lo descomprimimos en la misma carpeta y luego lo copiaremos en la carpeta /opt

Para que nos funcione bien, nos pide que instalemos para la base de datos postgreSQL, nos recomiendan la versión  (8.4) y la podemos descargar desde  

Aquí

Bien, ya lo tenemos descargado, vereis que no tiene permisos de ejecución, así que botón derecho, y marcamos permisos de ejecución.

Vereis que cuando intentamos ejecutarlo nos pide tener permisos de root, como siempre me he liado con eso de dar permisos con chmod y bla bla bla, lo hice a "mi manera" abro el directorio con botón derecho, abrir como administrador y veremos que caja se nos abre con ese fondo "colorao" tan bonito, ale, con dos cojones ya tenemos los permisos necesarios, damos doble click y se empieza a instalar.

Se nos instalará en nuestro directorio /opt, bueno, la instalación es muy sencilla, sobre todo, procurad recordar la contraseña que pongáis en la instalación, que es la que luego tendremos que usar para poder conectarnos a eneboo.

Ya lo tenemos descomprimido en nuestra carpeta /opt, ahora vamos a crearnos un lanzador como siempre.

Comando: /opt/eneboo-v2.4.0.2-dba/bin y seleccionamos el ejecutable eneboo

La imagen para el lanzador la encontraremos en este directorio:
/opt/eneboo-v2.4.0.2-dba/share/eneboo/images

Ya lo tenemos casi listo, ahora vamos a iniciarlo, damos doble click y nos encontraremos con esta ventana

Como podéis ver, en base de datos, teclearemos Standard, en usuario postgres y la contraseña pues..... los puntitos que hayáis decidido vosotros.
Dando en la flecha de la derecha os encontrareis con más opciones, que las dejaremos tal cual lo veis.

Una vez iniciado, nos dirá que no existe la base de datos y si queremos crearla, le decimos que Sí y empezamos a funcionar.

Ya con eneboo funcionando, lo que haremos será cargar el paquete de módulos, que es el que nos trae todo lo necesario, haremos lo siguiente, pulsaremos sobre Sistema/administración y seleccionaremos Cargar paquete de módulos.

Seleccionaremos el paquete de módulos standard que nos bajamos al principio desde la pagina web oficial, se supone que las habréis copiado también en el directorio de /opt/eneboo, vamos en teoría lo encontrareis en esta ubicación: /opt/eneboo-v2.4.0.2-dba y seleccionáis standard.eneboopkg

Ya con todo los módulos instalados, empezaremos a crear nuestra propia base de datos, con este programa, podemos gestionar practicamente todo lo necesario para "nuestra" empresa, os dejo unas capturas para que veáis todo lo que podéis hacer.

Bueno, ya veis que en el área de facturación podéis controlar Facturas, pedidos, albarenes, presupuestos, ventas, compras......

Controlar el almacén, incluir artículos, podemos incluso asignarles un código de barras, bueno, yo ya tengo uno preparado para frannoe, aquí lo dejo.

También podemos gestionar todo lo relacionado con el "área financiera" como IVA, libro diario, libro mayor,  sumas y saldos, etc etc etc....

Bueno, opciones hay muchisimas, no soy un experto en este tema, pero bueno, supongo que trasteando seguro que lo sacáis todo.

Como ya dije en su momento, por suerte en Linux tenemos muchas "alternativas" y además creo que son muy buenas y completas.

Espero que pueda servir a alguno y ahorrarse un dinerillo, sin que tenga que pagar por un software de gestión.

Un saludo.

MATE 1.8 ya está aquí

Nunca casó tanto el dicho..: No hay mal que por bien no venga.
Y es que la verdad señores/as, hemos salido ganando todos. Tanto todos aquellos que apostaban por Gnome3 (ahí está bonito y coleando y mejor que nunca) como los que apostábamos por más de lo mismo y que gracias a un entusiasta grupo de personas que decidieron y apostaron porque no desapareciera el gran Gnome2, lo transformaron en el MATE que todo el mundo (en Linux) conoce ya. ¿Veis como sí cabemos todos?. En la variedad se encuentra el buen gusto.

MATE que ya en su versión 1.8 se consolidad definitivamente y su continuidad está más que garantizada.
MATE 1.8 en si, no trae notables novedades (que algunas hay) sino que es la estabilización y depuración de todo lo acontecido hasta este momento en su desarrollo desde que empezó este proyecto. El asentamiento definitivo. La versión 1.8 es la culminación de todo este gran trabajo, y a partir de ahí ya podremos decir que poseemos de un entorno estable y seguro y a todos los efectos tal y como lo fue Gnome2 en sus mejores momentos.

Como sus propios responsables indican:

MATE 1.8 es el resultado de 11 meses de intenso desarrollo y contiene 1.845 contribuciones de 57 personas, y más de 291 traductores

Y sí, todo ese trabajo se nota y se agradece enormemente.

Como dije tambien hace bien poco, la inclusión de MATE en los repositorios de Debian Jessie, es otro valor añadido al gran trabajo de este equipo y su profesionalidad, seriedad y saber hacer.

Algunas de las novedades que aporta esta versión 1.8 son:
Nota: Se creía, que en esta versión estaría listo el soporte para GTK3. Pero no estará disponible hasta su versión 1.10.

Caja (administrador de archivos)

• Ahora utilizará unidades de información IEC en vez de SI.

 

Unidades de información (del byte)
Sistema Internacional (decimal)		ISO/IEC 80000-13 (binario)
Múltiplo (símbolo)	SI	Múltiplo (símbolo)	ISO/IEC
kilobyte (kB)	103	kibibyte (KiB)	210
megabyte (MB)	106	mebibyte (MiB)	220
gigabyte (GB)	109	gibibyte (GiB)	230
terabyte (TB)	1012	tebibyte (TiB)	240
petabyte (PB)	1015	pebibyte (PiB)	250
exabyte (EB)	1018	exbibyte (EiB)	260
zettabyte (ZB)	1021	zebibyte (ZiB)	270
yottabyte (YB)	1024	yobibyte (YiB)	280
Véase también: nibble • byte • octal

Wikipedia

• Se añade una opción al menú contextual de búsqueda para ir al directorio principal del archivo en cuestión.

Marco (gestor de ventanas)

• Se añade side-by-side (window snapping). Esto es adaptar las ventanas en mosaico automáticamente arrastrándolas a los bordes de la pantalla. Nota: Me da, que como en otros casos será incompatible con el cubo giratorio de Compiz.

Panel

• Soporte para combinaciones de teclas para Metacity en el diálogo de ejecución y el menú principal. 
• Nueva barra de progreso para el diálogo de cierre.

Centro de control 

•  Se da soporte para usar Metacity como gestor de ventanas.

Biblioteca del escritorio MATE

• Nueva guía del usuario para MATE.
• Añadido mpaste herramienta para http://paste.mate-desktop.org.

Eye Of MATE (visor de imágenes)

• Nuevo modo aleatorio para la presentación de diapositivas.

Engrampa (empaquetador de ficheros)

• Mostrar siempre Extraer en... del menú de contextual para Caja.

Screensaver (Salvapantallas)

• Ahora se mostrará también la fecha y la hora en la pantalla de bloqueo.

Applets

• Funcionalidad deshacer añadida al applet de Notas.
• Se ha añadido un nuevo applet Command para mostrar la salida de un comando.
• Se ha reescrito por completo en C el applet Timer.
• Ahora al hacer clic en el botón central del ratón sobre el applet de volumen, éste enmudece.

Paquetes eliminados o remplazados:

• mate-doc-utils reemplazado por yelp-tools.
• libmatekeyring y mate-keyring remplazados por libsecret y gnome-keyring.
• libmatewnck remplazado por libwnck.
• mucharmap remplazado por gucharmap.
• mate-bluetooth remplazado por blueman.
• Merged y las extensiones de Caja se han unificado en tan solo un paquete.
• Se ha eliminado el applet de del módem ya que el applet netspeed, proporciona una funcionalidad similar.

Hay que decir que la versión 1.8 aunque está concluida, aún no ha sido liberada. Habrá que espera unos días más o semanas. Hasta entonces, ir preparando vuestro sistema para la gran acogida.

Tenéis todo la información aquí:
MATE 1.8 released

ConnMan: alternativa a NetworkManager y Wicd en Debian

ConnMan es un gestor de red que junto a ConnMan-UI puede proporcionarnos una alternativa muy interesante a los ya establecidos gestores de red como son NetworkManager y Wicd (este último bastante parado su desarrollo)

ConnMan está desarrollado por Intel y fue diseñado específicamente para ser ligero y utilizar la menor cantidad de recursos posibles del sistema. Desde Archlinux se nos indica que es tremendamente rápido a la hora de resolver direcciones. 

Las siguientes funciones están incorporadas en dicho gestor:
- Conexión a infraestructuras genéricas
- Abstracción de red y dispositivos (con soporte de almacenamiento básico)
- IPv4, IPv4-LL (creación de redes IP ) y DHCP
- IPv6, DHCPv6 y túneles 6to4 (transmisión de paquetes IPv6 sobre redes IPv4)
- Enrutamiento avanzado y configuración DNS
- Proxy DNS incorporado y cache inteligente
- WISPr (Protocolo de conexión a proveedores de internet inalámbricos)
- Configuración de hora y de zona horaria (manual o con NTP)
- Uso de proxy (manual y automático con WPAD)
- Soporte de Tethering (con USB, Bluetooth y el modo Punto de Acceso Wi-Fi)
- Uso de estadísticas (de manera local o de roaming)

Plugins para la creación de redes de apoyo:
- Plugin de Ethernet
- Plugin de WiFi con WEP40/WEP128 y WPA/WPA2
- Plugin de Bluetooth (instalando BlueZ)
- 2G/3G/4G complemento (instalando oFono)

Plugins con funciones adicionales:
- Loopback interfaz de configuración
- PACrunner manejo de proxy
- Apoyo autorización PolicyKit

Estas son las característica de su versión 1.0, que es la que se encuentra en los repositorios de Debian. Su versión actual 1.21 se encuentra bastante más desarrollada, pero aun no se encuentra dichos repositorios.

Para todos aquellos que no utilizamos el entorno Gnome, es muy interesante el uso de este gestor en vez de NetworkManager y sus dependencias. Esto nos libera aún más si cabe de (valga la redundancia) depender de paquetería extra de un entorno que no estamos utilizando.

Aunque hasta ahora podíamos estar utilizando ConnMan desde Debian estable, no es hasta Jessie/Testing que se incorpora su interfaz gráfica ConnMan-UI. Esta no es la única interfaz que hay para este gestor, pero Debian por ahora se ha decantado por ella. Destaca por su funcionalidad y ligereza.

Si queremos instalar este gestor con su GUI correspondiente y no estamos en la rama Testing o con los repositorios de  Jessie, no nos queda otra que apuntar nuestros repositorios de manera puntual a Debian Jessie o Testing e instalar el paquete connman-ui desde el Synaptic o vía terminal:

• sudo apt-get install connman-ui rcconf

Con esto tan solo bastará para que se instalen todos los paquetes necesarios.
Nota: El paquete  rcconf es el gestor de servicios al inicio del sistema que lo utilizaremos si es necesario más adelante.
Cuando se instalen estos paquetes, como tendremos ya en funcionamiento otro gestor de red (NetworkManager o Wicd) el servicio de inicio de ConnMan no se encontrará activado.
Lo que realizaremos seguidamente (aunque parezca raro) es reinstalar los paquetes del gestor de red network-manager network-manager-gnome o wicd. Esto lo podemos hacer como siempre desde el Synaptic o vía Terminal:

Para el caso de NetworkManager:

• sudo apt-get --reinstall install network-manager network-manager-gnome

Para el caso de Wicd:

• sudo apt-get --reinstall install wicd python-wicd rfkill wicd wicd-daemon wicd-gtk

¿Y esto porqué lo hacemos?. Pues sencilla y llanamente para que estos paquetes se añadan a nuestra cache de archivos y poder disponer de ellos si los necesitáramos aún sin tener conexión. Si por cualquier motivo ConnMan no nos funcionara y nos quedáramos sin conexión, siempre podremos desinstalarlo y volver a instalar el gestor de red que estábamos utilizando. Tanto desde el Synaptic como desde el terminal y aun estando sin conexión, podremos hacerlo ya que los paquetes necesarios se hallarán como dije anteriormente en la cache de archivos.
Esto es en: /var/cache/apt/archives/

Hecho esto, procederemos con toda tranquilidad a eliminar de nuestro sistema cualquier rastro del anterior gestor de red. Si utilizamos el Synaptic clicaremos en los paquetes correspondientes y seleccionaremos Marcar para desinstalar completamente, si lo hacemos desde el Terminal:

Para el caso de NetworkManager:

• sudo apt-get --purge remove network-manager network-manager-gnome

Para el caso de Wicd:

• sudo apt-get --purge remove wicd python-wicd rfkill wicd wicd-daemon wicd-gtk

El paso siguiente es crear una nueva aplicación al inicio (Sistema --> Preferencias --> Aplicaciones al Inicio) de ConnMan-UI, y en la casilla Comando poner connman-ui-gtk, para que se inicie al arrancar nuestra sesión.

Por otra parte, si queremos hacer este arranque común a todos los usuarios habidos y por haber, ejecutaremos lo siguiente (todo a la vez) desde un Terminal Root:

cat > "/etc/xdg/autostart/connman-ui.desktop" << CONNM
[Desktop Entry]
Version=1.0
Type=Application
Name=Connman-ui
Comment=GUI del Gestor de red ConnMan
Icon=nm-device-wireless
Terminal=false
Exec=connman-ui-gtk
X-MATE-Autostart-enabled=true
CONNM

Ojo, cuando digo un Terminal Root no me refiero al uso del sudo. Tenéis que proceder del siguiente modo:
- Abrir un Terminal cualquiera
- Teclear su
- Introducimos nuestra clave Root y copiamos todo el contenido anteriormente citado (desde cat al último CONNM) y lo pegamos en el Terminal. Pulsamos Intro y se nos creará el lanzador correspondiente común a todos lo usuarios.

Por último, lo que nos queda (habiendo eliminado nuestro anterior gestor de red) es ver si el servicio connman se encuentra activo.
Tenemos dos maneras simple de activar su servicio:
Desde el Terminal:

• sudo update-rc.d connman enable

Desde el gestor de servicios rcconf, que comentamos al principio y que hallaremos en el menú:
Sistemas --> Administración -- > Servicios

 

Algunos comandos útiles de ConnMan:

sudo /etc/init.d/connman start

Y su variantes:

stop

status

restart

force-reload

Reiniciamos el sistema y listo.

Para finalizar debo comentar que la GUI se encuentra en Ingles, pero que he realizado su traducción al Español.
Si queréis tenerlo en nuestro idioma bajaros este archivo:
ConnMan-UI-es
Descomprimirlo y añadir el archivo connman-ui.mo  en la siguiente ruta: /usr/share/locale/es/LC_MESSAGES

Por cierto: Gracias José por la ayuda prestada. De no ser por ti, aún estaría dándole vueltas a algunas cosas.

Más información:
ConnMan
ConnMan-UI