«Nuevo» logo de Flatpak

Hace unos instantes hemos publicado un artículo en el que os hablábamos de las sensaciones que nos dan los paquetes snap y flatpak. La frecuencia de las actualizaciones es algo en lo que los flatpak quedan por delante, lo que no siempre significa que sea mejor, y eso es algo que también podemos ver en el software que usan para empaquetar el software. Sólo dos meses después de la versión anterior, ya está disponible Flatpak 1.15.0.

Entre las novedades más destacadas, hay cambios en cuanto a la compilación: a partir de ahora este tipo de paquetes se puede compilar usando Meson en vez de Autotools. Para poder hacerlo es necesario usar Meson 0.53.0 o posterior y Python 3.5 o posterior. Según dicen, es probable que el sistema de construcción Autotools sea eliminado durante el ciclo de 1.15 o 1.17.

Otras novedades de Flatpak 1.15

Esta versión permite la llamada del sistema modify_ldt como parte de --alow=multiarch, lo que aumenta la superficie de ataque, pero es necesario al usar ejecutables de 16-bit en algunas versiones de WINE. También se puede compartir el socket gssproxy, lo que actúa como un portal para la autentificación de Kerberos y permite a las apps usar esta autentificación sin un agujero en el sandbox. Por último, se ha añadido una variable httpbackend a flatpak.pc, permitiendo a objetos dependientes como GNOME Software detectar si son compatibles con libflatpak.

Por otra parte, se han corregido estos errores:

• Terminar los servicios flatpak-session-helper y flatpak-portal cuando la sesión, para que las aplicaciones no hereden direcciones de socket Wayland y las direcciones de los sockets X11.
• Cuando se utiliza fish shell, no se sobrescribe un XDG_DATA_DIRS previamente establecido.
• No intenta habilitar HTTP 2 si está vinculado a una versión de libcurl que no lo soporta.
• Se detiene systemd reportando la sesión-ayudante como fallida cuando se termina por una señal.
• Corregida una advertencia al listar un documento sin permisos.
• Corregida la compilación con GLib 2.66.x (como se usa en Debian 11).
• Corregida la compilación con GLib 2.58.x (como se usa en Debian 10).
• Se ha hecho que los archivos generados sean más reproducibles.
• Actualizaciones de traducción: cs, id, pl, pt_BR

Flatpak 1.15 se ha anunciado hace menos de 24 horas, y se puede descargar desde este enlace en GitHub, en donde se ha publicado toda la información sobre este lanzamiento. En los próximos días/semanas llegará a los repositorios oficiales de la mayoría de distribuciones Linux.

from Linux Adictos https://ift.tt/untFxPm
via IFTTT

Ya hace bastante tiempo desde que se empezaron a usar los paquetes snap y flatpak. Aunque llevaban ya un tiempo en pruebas, ambos se empezaron a usar de verdad en 2016, por lo que cualquier usuario de Linux habrá probado ya algún que otro paquete de este tipo. A principios de este año, mi compañero Diego escribió un artículo explicando las diferencias, ventajas y desventajas de cada uno, y hoy vamos a hacer un poco lo mismo, pero enfocando la información hacia el uso personal.

Adelantando un poco el veredicto, o parte de él, yo diría que hay que elegir uno u otro sólo cuando un paquete esté en los dos formatos, dependiendo de cómo nos funcione cada uno. También hay que tener en cuenta que los flatpak se actualizan más, mientras que los snap lo hacen sólo cuando se sube de versión. Es habitual ver que el flatpak se actualiza a la misma versión muchas veces, porque se supone que han corregido algo y la actualización llega tan pronto en cuanto suben el parche.

Snap y Flatpak, cuestión de gustos

Hay algunos paquetes en Flathub que llevan la etiqueta de alfa o beta, y lo hacen en el repositorio oficial, nada del beta. Otros paquetes se actualizan muy pronto, parecido a como lo hacen las distribuciones Rolling Release, y esto no siempre nos trae cosas buenas. Los snap se actualizan algo menos y suelen ofrecer versiones que parecen más estables, pero esta diferencia en general es poca.

Entonces, de cara al usuario final, ¿qué diferencias hay entre ambas opciones? Ya explicó bastante Diego, pero yo me quedaría con cuatro:

Software disponible

Creo que en cuanto a software disponible, Flathub gana por mucho a Snapcraft. De hecho, he visto en varias ocasiones como aplicaciones que estaban en Snapcraft desaparecían, mientras que en Flathub siguen estando y actualizándose. Los desarrolladores, por lo menos los medianos y pequeños, suelen elegir Flathub, y allí aparecen pronto todas las nuevas aplicaciones que llegan al círculo de GNOME. Una de las últimas, Retro, un reloj que se puede editar con reglas CSS.

Ahora bien, el diseño de los snap les hace ser una mejor opción para empaquetar y distribuir otro tipo de software, como drivers o incluso versiones de Python como la 3.8.

Integración con el sistema operativo

Tal y como decía Diego, «los paquetes snap tienen un completo sistema de permisos por lo que es posible configurarlos para que interactúen con el sistema operativo y las aplicaciones instaladas por el modo habitual«. Estos permisos permiten, valga la redundancia, que los paquetes snap se integren mejor con el sistema que los flatpak. Por ejemplo, hay aplicaciones multimedia que muestran información en el gestor de tareas de KDE cuando usamos la versión snap, pero sólo el icono de la aplicación cuando usamos la versión flatpak.

Velocidad de apertura

Esto puede parecer una tontería, pero no lo es. Hay que tirarle de las orejas a Canonical y decir que no se pueden esperar 10s a que se abra una aplicación en formato snap si se tiene un equipo con un buen procesador y disco SSD. Se está mejorando mucho con el paquete de Firefox, por lo que hay margen de mejora y hay que reducir el tiempo de carga. Los flatpak se abren mucho antes.

Software privativo

Puede ser algo que no gusta a muchos usuarios de la comunidad Linux, pero a veces es necesario usarlo. En Snapcraft está el Visual Studio Code de Microsoft (oficial) o el Steam de Valve con absolutamente todo en el mismo paquete. Las compañías importantes suelen elegir los snap, en parte por su diseño, pero también cuenta que Canonical llega a acuerdos con las empresas para que les den prioridad.

¿Qué instalo: snaps o flatpaks?

Como dije en el spoiler al inicio del post, creo que no hay que decantarse por uno por decreto. Hay que probarlos. Si se quiere algo más actualizado, probablemente haya que elegir el flatpak. Si se necesita mayor integración, quizá merezca la pena usar el snap. Si no se puede aguantar unos segundos a que se abra el snap, pues hay que ir a por el flatpak, y si se quiere algo menos corporativo, aunque Diego ya explicó que la sombra de Red Hat está presente, merecen la pena los flatpak. Por supuesto, si una de las dos opciones no funciona en nuestro equipo hay que usar la otra.

En lo personal, yo uso más los flatpak que los snap, pero principalmente por un motivo: el programa o aplicación que uso está en Flathub y no en Snapcraft. Ahora bien, si está en repositorios oficiales… Adiós a ambos.

from Linux Adictos https://ift.tt/McE2Xrz
via IFTTT

Hacía tiempo que estaba en fase de pruebas, y ya han lanzado la versión estable. Este lenguaje de programación con nombre de serpiente es uno de los preferidos por muchos desarrolladores, por lo que el lanzamiento de Python 3.11 es un acontecimiento de cierta importancia. Es una actualización mayor, o mediana si se prefiere etiquetar de mayores a las que cambian el primer número, pero no se puede negar que ha mejorado bastante.

En Phoronix, medio que debe gran parte de su fama a sus pruebas de software y hardware, estuvieron testando el rendimiento de Python 3.11 y confirmaron que es entre un 10% y un 60% más rápido que Pyhon 3.10, la que hasta hoy era la versión estable más actualizada. Pero no absolutamente todo son buenas noticias, por lo menos para los usuarios de Linux, ya que una actualización como esta podría romper la compatibilidad con software que estemos usando, y una muestra de ello es lo que estamos sufriendo los usuarios de Kodi en Linux desde que se subió a «Matrix».

Cambios generales de Python 3.11

Lo más destacado de Python 3.11 incluye que ahora se incluyen localizaciones de error de grano fino en los trazados, lo que, en teoría, permitirá reconocer mejor los fallos; grupos de excepciones y except*; en tomllib, se ha añadido soporte para el análisis de TOML en la biblioteca estándar; introducidos grupos de tareas en asyncio; la agrupación atómica ((?>…)) y los cuantificadores posesivos (*+, ++, ?+, {m,n}+) están ahora soportados en las expresiones regulares.

Pero lo más destacado es la velocidad:

El proyecto Faster CPython ya está dando algunos resultados interesantes. Python 3.11 es hasta un 10-60% más rápido que Python 3.10. De media, hemos medido un aumento de velocidad de 1,22 veces en el conjunto de pruebas estándar.

Aunque todo pinta muy bien, hay que tener en cuenta que los cambios en los lenguajes de programación pueden dar problemas, como el de Kodi. Los desarrolladores deben adaptar su código a las nuevas versiones, y si no todo el código, sí la versión «camuflada» para que no les roben su trabajo. Por lo tanto, si se depende de algo así, es mejor aguantar la actualización lo máximo posible.

Python 3.11 ha sido anunciado hoy (ayer en huso horario del proyecto), y su tarball ya se puede descargar desde la página de descargas del proyecto. Su llegada a los repositorios oficiales dependerá de la filosofía de la distribución que estemos usando, pero en la mayoría de casos pasarán semanas o incluso meses.

Más información y logo de la imagen: foro de Python.

from Linux Adictos https://ift.tt/6L1PIU0
via IFTTT

La manera en como introducir código malicioso continua evolucionando tomando los antiguos métodos y mejorando la forma en como engañar a las victimas

Tal parece que la idea del caballo de Troya sigue siendo bastante útil hoy en día y de una formas tan sutiles que muchos podemos pasar desapercibidas y es que hace poco investigadores de la Universidad de Leiden (Países Bajos) estudiaron el problema de publicar prototipos de exploits ficticios en GitHub.

La idea de utilizar estos para poder atacar a los usuarios curiosos que desean probar y conocer la forma en la que se pueden explotar algunas vulnerabilidades con las herramientas ofrecidas, hace que este tipo de situaciones sean las ideales para introducir código malicioso para atacar a los usuarios.

Se informa que en el estudio se analizaron un total de 47.313 repositorios de exploits, que cubren vulnerabilidades conocidas identificadas desde 2017 hasta 2021. Un análisis de exploits mostró que 4893 (10,3%) de ellos contienen código que realiza acciones maliciosas.

Es por ello que se recomienda a los usuarios que decidan utilizar exploits publicados que primero los examinen en busca de inserciones sospechosas y ejecuten exploits solo en máquinas virtuales aisladas del sistema principal.

La prueba de concepto (PoC) de exploits para vulnerabilidades conocidas se comparte ampliamente en la comunidad de seguridad. Ellos ayudan a los analistas de seguridad a aprender unos de otros y facilitan evaluaciones de seguridad y tareas de red teaming.

Durante los ultimos años, se ha vuelto bastante popular distribuir los PoC por ejemplo, a través de sitios web y plataformas, y también a través de repositorios de códigos públicos como GitHub. Sin embargo, los repositorios de códigos públicos no proporcionan cualquier garantía de que cualquier PoC dado proviene de una fuente confiable o incluso que simplemente hace exactamente lo que se supone debe de hacer.

En este trabajo investigamos PoC compartidos en GitHub para vulnerabilidades conocidas descubiertas en 2017–2021. Descubrimos que no todos los PoC son confiables.

Sobre el problema se han identificado dos categorías principales de exploits maliciosos: exploits que contienen código malicioso, por ejemplo, para dejar una puerta trasera en el sistema, descargar un troyano o conectar una máquina a una botnet y exploits que recopilan y envían información confidencial sobre el usuario.

Además, también se identificó una clase separada de exploits falsos inofensivos que no realizan acciones maliciosas, pero tampoco contienen la funcionalidad esperada, por ejemplo, diseñados para engañar o advertir a los usuarios que ejecutan código no verificado desde la red.

Algunas pruebas de concepto son falsos (es decir, en realidad no ofrecen funcionalidad PoC), o
incluso maliciosos: por ejemplo, intentan exfiltrar datos del sistema en el que se están ejecutando, o intentan instalar malware en ese sistema.

Para abordar este problema, hemos propuesto un enfoque para detectar si un PoC es malicioso. Nuestro enfoque se basa en detectar los síntomas que hemos observado en el conjunto de datos recopilados, por
ejemplo, llamadas a direcciones IP maliciosas, codificado de código, o binarios troyanizados incluidos.

Con este enfoque, hemos descubierto 4893 repositorios maliciosos de 47313
repositorios que se han descargado y comprobado (es decir, el 10,3% de los repositorios estudiados presentan codigo malicioso). Esta cifra muestra una prevalencia preocupante de peligrosos PoC maliciosos entre el código de explotación distribuido en GitHub.

Se utilizaron varios controles para detectar exploits maliciosos:

• El código de explotación se analizó para detectar la presencia de direcciones IP públicas cableadas, después de lo cual las direcciones identificadas se verificaron adicionalmente en bases de datos con listas negras de hosts utilizados para controlar botnets y distribuir archivos maliciosos.
• Los exploits proporcionados en forma compilada se han comprobado con el software antivirus.
• Se detectó en el código la presencia de volcados hexadecimales atípicos o inserciones en formato base64, tras lo cual dichas inserciones fueron decodificadas y estudiadas.

Tambien se recomienda para aquellos usuarios que gustan por realizar las pruebas por su propia cuenta, tomen en primer plano fuentes como Exploit-DB, ya que estas intentan validar la efectividad y la legitimidad de los PoC. Ya que, por el contrario, el código público en las plataformas como GitHub no tienen el proceso de verificación de exploits.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles del estudio en el siguiente archivo, del cual te comparto su enlace.

from Linux Adictos https://ift.tt/J1FpEs8
via IFTTT

Linus Benedict Torvalds es un ingeniero de software finlandés-estadounidense, ​ conocido por iniciar y mantener el desarrollo del kernel Linux,

Hace poco mientras se discutía las soluciones en los procesadores x86 que no admiten la instrucción «cmpxchg8b», Linus Torvalds afirmó que podría ser el momento de hacer que esta instrucción sea obligatoria para que el kernel se ejecute y elimine la compatibilidad con los procesadores i486 que no admiten «cmpxchg8b», en lugar estar de «tratando de emular el funcionamiento» de esta instrucción en procesadores que «ya nadie usa».

Actualmente, casi todas las distribuciones de Linux que continúan admitiendo sistemas x86 de 32 bits han cambiado a compilar el kernel con la opción X86_PAE, que requiere compatibilidad con «cmpxchg8b».

Según Linus, en términos de soporte en el kernel, los procesadores i486 han perdido relevancia, a pesar de que todavía se encuentran en la vida cotidiana. En cierto punto, los procesadores se convierten en piezas de museo, y para ellos es bastante posible arreglárselas con núcleos de «museo».

Cabe mencionar que en dado caso de proceder la eliminación del soporte para el i486 clásic, este no afectará a los procesadores Quark embebidos de Intel, que, aunque pertenecen a la clase i486, incluyen instrucciones adicionales típicas de la generación Pentium, entre ellas «cmpxchg8b».

Ademas de ello se menciona que lo mismo se aplica a los procesadores Vortex86DX. La compatibilidad con los procesadores i386 se eliminó en el kernel hace 10 años.

Tal vez deberíamos morder la bala y decir que solo admitimos x86-32 con ‘cmpxchg8b’ (es decir, Pentium y versiones posteriores).

Deshágase de todos los «emular atómicos de 64 bits con cli/sti, sabiendo que nadie tiene SMP en esas CPU de todos modos», e implemente una configuración genérica x86-32 xchg() usando ese bucle try_cmpxchg64.

Creo que la mayoría (¿todas?) de las distribuciones ya habilitan X86_PAE de todos modos, lo que hace que X86_CMPXCHG64 sea parte del requisito básico.

No es que esté convencido de que la mayoría de las distribuciones incluso hacen desarrollo de 32 bits en estos días.
…
Nos deshicimos de la compatibilidad con i386 en 2012. ¿Quizás es hora de eliminar la compatibilidad con i486 en 2022?

La finalización del soporte de i486 podría ser un hito a considerar, ya que desde no hace mucho diversas distribuciones de Linux, optaron por eliminar el soporte para procesadores de 32 bits, lo cual realmente no repercutió como muchos esperaban. Ya que como tal si, aún existen miles de usuarios que cuentan con ordenadores de bajos recursos, lo que convertía a Linux en una excelente opción para continuar dándoles un uso a estos, en especial en muchas zonas marginadas.

Y aunque se continuara dado el soporte para este tipo de equipos por parte de las principales distribuciones, los requisitos actuales de ellas, hacían que uso fue realmente imposible de realizar. Lo cierto es que aún hay algunas distribuciones que continúan dando el soporte para esta arquitectura y sobre todo que están optimizadas para el uso de equipos de bajos recursos.

Sobre el caso de la finalización del soporte, se menciona que los usuarios que tengan sistemas con procesadores i486 podrán utilizar las versiones LTS del kernel, las cuales se mantendrán por muchos años más.

Por otro lado, tambien vale la pena mencionar que el desarrollador del controlador Linux de código abierto para la GPU Apple AGX utilizada en los chips Apple M1 informó que superó con éxito el 99,3% de las pruebas del conjunto dEQP-GLES2, que verifica el nivel de soporte para la especificación OpenGL ES 2. En el trabajo se utilizaron dos componentes: un controlador DRM para el kernel de Linux, escrito en Rust, y un controlador Mesa escrito en C.

El desarrollo de controladores se complica por el hecho de que Apple M1 usa su propia GPU, diseñada por Apple, ejecuta firmware patentado y usa estructuras de datos compartidas bastante complejas. No hay documentación técnica para la GPU y el desarrollo de controladores independiente utiliza ingeniería inversa de controladores de macOS.

El controlador de código abierto desarrollado para Mesa se probó inicialmente en un entorno macOS hasta que se preparó el controlador DRM (Direct Rendering Manager) requerido para el kernel de Linux, lo que permitió que el controlador desarrollado para Mesa se usara en Linux.

Además del éxito actual al pasar las pruebas dEQP-GLES2, a fines de septiembre, el controlador de Linux para chips Apple M1 alcanzó un nivel adecuado para ejecutar una sesión de GNOME basada en Wayland y ejecutar el juego Neverball y YouTube en el navegador Firefox.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/2G91Qaf
via IFTTT

Caliptra, es una especificación abierta para incorporar mecanismos de seguridad dentro de los chips

Hace poco Google, AMD, NVIDIA y Microsoft dieron a conocer mediante una publicación de blog, la noticia del proyecto en conjunto «Caliptra», con el cual han desarrollado un bloque de diseño de chip abierto (bloque IP) para incorporar herramientas en chips para crear componentes de hardware confiables (RoT, Root of Trust).

Caliptra es una unidad de hardware separada con su propia memoria, procesador e implementación de primitivas criptográficas, que proporciona verificación del proceso de arranque, el firmware utilizado y la configuración del dispositivo almacenada en la memoria no volátil.

Caliptra se puede utilizar para integrar en varios chips una unidad de hardware independiente que realiza comprobaciones de integridad y garantiza que el dispositivo utiliza firmware verificado y autorizado por el fabricante. Caliptra puede simplificar y unificar significativamente la integración de mecanismos de verificación criptográfica de hardware incorporados en CPU, GPU, SoC, ASIC, adaptadores de red, unidades SSD y otros equipos.

La implementación básica del bloque IP se basa en el procesador abierto RISC-V SWeRV EL2 y está equipado con 384 KB de RAM (128 KB DCCM, 128 KB ICCM0 y 128 KB SRAM) y 32 KB de ROM. Los algoritmos criptográficos admitidos incluyen SHA256, SHA384, SHA512 ECC Secp384r1, HMAC-DRBG, HMAC SHA384, AES256-ECB, AES256-CBC y AES256-GCM.

El proyecto Caliptra gira en torno al establecimiento de una raíz de confianza (RoT): construir capas de seguridad en el silicio para que los datos se cifren y no estén expuestos mientras viajan en los centros de datos o en la nube.

«El día de hoy marca un gran paso adelante en la colaboración de seguridad de toda la industria con el lanzamiento de las especificaciones de Caliptra 0.5 por parte de OCP y la disponibilidad de Caliptra 0.5 RTL a través de CHIPS Alliance. AMD seguirá siendo un participante activo en Caliptra y Open Compute Project. en apoyo de nuestros clientes y socios en todo el ecosistema». Mark Papermaster, CTO y vicepresidente ejecutivo de tecnología e ingeniería de AMD

«Los ecosistemas abiertos y los proyectos son fundamentales para el negocio de Google y lo han sido desde el primer día», dijo Partha Ranganathan, vicepresidente y miembro de ingeniería de Google Cloud y miembro de la junta de OCP. «Con Caliptra, estamos llevando la velocidad del desarrollo de código abierto a la seguridad de la infraestructura, lo que permite a la comunidad fortalecer colectivamente un sólido bloque de IP en el que todos podemos confiar en un conjunto diverso de ofertas de silicio». 

«Se necesita una mayor transparencia y consistencia en la seguridad del hardware de bajo nivel. Estamos abriendo Caliptra con nuestros socios para abordar estas necesidades». Mark Russinovich, director de tecnología y miembro técnico de Microsoft Azure.

Los medios de verificación criptográfica de integridad y autenticidad proporcionados por la plataforma protegerán los componentes de hardware de la introducción de cambios maliciosos en el firmware y asegurarán el proceso de carga y almacenamiento de la configuración para evitar que el sistema principal se vea comprometido como resultado de ataques a componentes de hardware o sustitución de cambios maliciosos en las cadenas de suministro de chips.

Caliptra también brinda la capacidad de autenticar actualizaciones de firmware y datos relacionados con la plataforma (RTU, Root of Trust for Update), detectar daños en el firmware y datos críticos (RTD, Root of Trust for Detection), restaurar firmware y datos dañados (RTRec, Root de Fideicomiso para la Recuperación).

Caliptra se está desarrollando sobre la plataforma del proyecto conjunto Open Comput , cuyo objetivo es desarrollar especificaciones abiertas para equipos para equipar centros de datos.

Las especificaciones relacionadas con Caliptra se distribuyen mediante el Acuerdo de Fundación Web Abierta (OWFa), diseñado para promover estándares abiertos (similar a una licencia de fuente abierta para especificaciones). El uso de OWFa hace posible crear sus propios productos e implementaciones derivadas basadas en la especificación sin deducir regalías y permite que cualquier organización participe en el desarrollo de la especificación.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/OUzsbBM
via IFTTT

Como ellos mismos dicen, los Service Pack de este sistema operativo llegan con novedades interesantes, pero esta vez no ha sido así a no ser que se entienda como «interesante» que es más seguro. En el SP del mes pasado sí se incluyeron mejoras notables, como que se subió a Phosh 0.21 y a Phoc 0.21.1. El postmarketOS 22.06.3 recién lanzado tiene una lista larga de novedades, pero en realidad se podrían resumir todas en dos, o una.

Todos los puntos de la lista menos uno dicen que han subido el kernel a una versión superior, siendo la elección en la mayoría de casos Linux 6.0.2. También hay casos en los que se ha subido a Linux 5.19 o una versión más nueva que ya incluye los parches, pero todos estos puntos se podrían resumir en que se ha actualizado el kernel para usar uno que ya tenga parcheados los problemas de seguridad en WLAN.

postmarketOS 22.06.3 no incluye nuevas funciones

Normalmente los service packs son para llevar las características de edge a estable, y las correcciones de seguridad se trasladan directamente a estable sin esperar a un service pack. Sin embargo, esta vez la corrección no era un parche trivial (como el de dirtypipe), y decidimos actualizar el kernel a la versión 6.0.2 cuando fuera posible. Esto requería más tiempo para el empaquetado y las pruebas, y tenía sentido agrupar todo esto en un paquete de servicio y hacer un anuncio adecuado al respecto. Así que aquí estamos.

El punto que falta, y en el que no se ha subido el kernel, ha sido para bajar la versión del núcleo que usaba el Nokia N900. El viejo rockero de Nokia (13 años va a hacer en las próximas semanas) estaba usando Linux 5.18.1, un kernel de ciclo normal que hace tiempo que ya ha llegado al final de su ciclo de vida. Podrían haberlo subido a Linux 5.19, si no fuera por una regresión en el USB que han descubierto recientemente. Por lo tanto, la única opción que les quedó fue bajar el kernel a Linux 5.15, la última versión LTS que sigue estando soportada.

Para instalar postmarketOS 22.06.3, hace ya un tiempo que se introdujo una herramienta para actualizar desde el terminal. Para el que no la tenga instalada, se puede añadir con el comando apk add postmarketos-release-upgrade, y luego lanzarla con el comando postmarketos-release-upgrade. Eso si se está en v21.12. Para versiones anteriores, los comandos de instalación serían:

wget https://gitlab.com/postmarketOS/postmarketos-release-upgrade/-/raw/master/upgrade.sh
chmod +x upgrade.sh

Las nuevas imágenes están disponibles en la página de descargas.

from Linux Adictos https://ift.tt/PaUqJHm
via IFTTT

Esta semana, Canonical ha lanzado Ubuntu 22.10, y el resto de la familia también ha puesto a disposición de cualquier interesado su versión Kinetic Kudu. Entre los componentes de dicha familia está Kubuntu, el sabor oficial que usa escritorio KDE/Plasma, pero KDE también desarrolla algo que controla más, algo que les da más libertad, y ese sistema operativo recibe el nombre de KDE neon. Como Kubuntu, está basado en Ubuntu, pero hay algunas diferencias a tener en cuenta.

Para empezar, KDE neon se basa en versiones LTS de Ubuntu, y para seguir usa repositorios especiales que le permiten instalar más pronto que nadie software como Plasma o KDE Frameworks. Jammy Jellyfish llegó en abril de 2022, pero KDE no quiso subir de 20.04 hasta tener claras algunas cosas. Por ejemplo, se sabe que retrasaron la actualización porque no sabían qué hacer con su versión de Firefox. Con las dudas resueltas, neon ya se basa en Ubuntu 22.04.

KDE neon usa la versión DEB de Firefox

Las últimas imágenes del sistema operativo hace días que se llaman KDE neon 5.26, ya que la numeración que usan coincide con la última versión de Plasma. También tienen siempre a la última KDE Frameworks y KDE Gear, pero en la base son más conservadores. La suben cada dos años, y esta vez se ha retrasado un tiempo en parte porque querían saber qué opinaba la comunidad sobre la versión snap de Firefox.

Que KDE tenga casi todo el control sobre lo que añade o deja de añadir en un sistema operativo tiene estas cosas. A la mayoría no le gustan los paquetes snap, y a la pregunta que les hizo KDE respondieron que preferían la versión DEB. Para ser más concretos, el «equipo K» quería saber si sus usuarios preferían el Firefox como snap que recomienda Canonical o la versión de toda la vida, también conocida como DEB, aunque tuvieran que añadir el repositorio de Mozilla. La elección ya es bien conocida.

Los usuarios interesados ya pueden descargar el KDE neon 5.26 basado en Ubuntu 22.04 desde la página web oficial del proyecto, disponible en este enlace. Las actualizaciones desde el sistema operativo se activarán el lunes.

from Linux Adictos https://ift.tt/9aSdwXN
via IFTTT

Como mi compañero Darkcrizt decidió ahorrarles mi queja semestral sobre las cada vez más insípidas versiones de Ubuntu, voy a reseñar un lanzamiento que me gustó. El de Ubuntu Budgie 22.10.

Ubuntu Budgie 22.10 confirma lo que vengo pensando hace tiempo, que las versiones desarrolladas por la comunidad suelen ser mucho mejores que la original. Canonical debería hacer lo mismo que Red Hat y separar Ubuntu en una versión comunitaria y otra corporativa.

Características de Ubuntu Budgie 22.10 Kinetic Kudu

Durante mucho tiempo el escritorio estuvo vinculado a la distribución Linux Solus y se basaba en las bibliotecas del escritorio GNOME del que utiliza algunas de sus aplicaciones. Hoy, convertido en un proyecto independiente está en vías de desprenderse tanto de las bibliotecas como de las aplicaciones.

Los componentes principales de este escritorio son:

• Budgie Menu: Un menú de estilo tradicional que en Ubuntu Budgie 22.10 encontramos en la esquina superior izquierda.  Muestra las aplicaciones por orden alfabético o por categoría. Además, puede buscarse por nombre.
• Raven: Desde la esquina superior derecha podemos controlar nuestros dispositivos multimedia, ver las notificaciones, apagar y reiniciar el equipo y controlar nuestro calendario entre otras funciones.
• Pantalla de bienvenida: Cuando iniciamos el equipo por primera vez, nos muestra una pantalla en la que podemos configurar en forma rápida nuestro equipo seleccionando un navegador, instalando controladores privativos y eligiendo un tema de escritorio.
• Centro de control de Budgie: Un panel de control a partir del cual podemos controlar todas las configuraciones del sistema operativo.
• Dock: Una barra inferior que nos permite acceder en forma rápida a nuestras aplicaciones más usadas.
• Burbuja de notificaciones: Si las aplicaciones permiten las alertas visuales, Budgie nos las mostrará y nos permitirá interactuar con ellas.
• Diálogo de ejecución: Permite iniciar una aplicación escribiendo su nombre.
• Applets: Miniaplicaciones para funciones específicas que pueden instalarse en el escritorio.

Estas son las novedades

Además de las mejoras en la traducción y de la adecuación del tema por defecto al del proyecto Budgie, podemos encontrar los siguientes cambios:

• Un renovado menú principal que da acceso a ubicaciones de archivos además de al Centro de Control de Budgie y a las opciones del aspecto visual.
• El centro de control permite compartir la pantalla mediante los protocolos VNC y RDP.
• Mejor soporte para el escalado fraccional.
• El Centro de control de Budgie solo admite perfiles de color si el monitor lo utiliza. Además ahora puede verse la tasa de refresco de este.
• Ya pueden espaciarse los applets globalmente en lugar de hacerlo en forma individual.

Aplicaciones

Google Maps y Google Calendar ya no forman parte de la instalación.  Es por eso que el calendario debajo del reloj ya no se integra. Otras aplicaciones como la calculadora y monitor del sistema fueron cambiadas por las correspondientes al escritorio Mate.

Otros cambios son:

• Atril reemplaza a Evince como lector de documentos.
• Font-manager reemplaza al visor de tipografías de GNOME.
• Parole reemplaza a Celluloid como reproductor de video.
•  Lollypop + Goodvibes + gpodder reemplazan a Rhythmbox para reproducción de audio y podcast.

Mi opinión sobre Ubuntu Budgie 22.10

Acostumbrarse a un nuevo escritorio cuesta un poco. Casi más que cambiar de distribución

Sin embargo, Budgie hace muy fácil la transición. La pantalla de Bienvenida es muy fácil de entender, aunque no esté completamente traducida. Es posible que los usuarios del calendario extrañen que no haya una aplicación de calendario y que los de Parole y Rhythmbox no se sientan cómodos con las nuevas aplicaciones, pero siguen en los repositorios.

En conjunto, la experiencia de uso es muy agradable. Budgie incluye una variedad de temas tanto para quienes gustan de los temas oscuros como de los claros.  Un punto en contra es que el cambio entre ventanas no resulta del todo cómodo.

Si te gustan los escritorios despojados, es una buena opción para tener en cuenta. También lo es si te gustan los accesorios. Los extras de Budgie permiten agregarle funcionalidades de acuerdo con tus necesidades.

Puedes descargarlo desde aquí.

from Linux Adictos https://ift.tt/qW7lAIf
via IFTTT

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Se ha identificado una vulnerabilidad (ya catalogada bajo CVE-2022-37454) en la implementación de la función hash criptográfica SHA-3 (Keccak), ofrecida en el paquete XKCP (eXtended Keccak Code Package).

La vulnerabilidad identificada puede provocar un desbordamiento del búfer durante el procesamiento datos formados. El problema se debe a un error en el código de una implementación específica de SHA-3, no a una vulnerabilidad en el algoritmo en sí.

El paquete XKCP se promociona como la implementación oficial de SHA-3, desarrollado con la ayuda del equipo de desarrollo de Keccak, y se utiliza como base para funciones para trabajar con SHA-3 en varios lenguajes de programación (por ejemplo, el XKCP El código se usa en el módulo Python hashlib, el paquete Ruby digest-sha3 y las funciones PHP hash_*).

Según el investigador que identificó el problema, pudo usar la vulnerabilidad para violar las propiedades criptográficas de la función hash y encontrar la primera y segunda preimágenes, así como determinar colisiones.

El motivo de la falla de segmentación es que los scripts intentarán escribir más datos en un búfer de los que puede contener. Tal vulnerabilidad se conoce como desbordamiento de búfer, que OWASP describe como» probablemente la forma más conocida de vulnerabilidad de seguridad de software «.

Una pequeña variante del código causará un bucle infinito: simplemente reemplace 4294967295 con 4294967296. Tenga en cuenta la similitud con CVE-2019-8741 , otra vulnerabilidad que encontré que afectó el firmware de más de 1.400 millones de dispositivos Apple, que también provocó un bucle infinito.

Además, se anuncia la creación de un exploit prototipo, que permite lograr la ejecución de código al calcular el hash de un archivo especialmente diseñado. Potencialmente, la vulnerabilidad también se puede usar para atacar algoritmos de verificación de firmas digitales usando SHA-3 (por ejemplo, Ed448). Está previsto que los detalles de los métodos de ataque se publiquen más adelante, después de la eliminación generalizada de la vulnerabilidad.

Se supone que este tipo de comportamiento no debe ocurrir en lenguajes «seguros» como Python y PHP, ya que verifican que todas las operaciones de lectura y escritura estén dentro de los límites del búfer. Sin embargo, el problema es que la vulnerabilidad está presente en el lenguaje C «inseguro» subyacente…

Aún no está claro cómo afecta la vulnerabilidad a las aplicaciones existentes en la práctica, ya que para que el problema se manifieste en el código, se debe usar el cálculo de hash cíclico en bloques, y uno de los bloques procesados ​​debe tener un tamaño de aproximadamente 4 GB (al menos 2 ^ 32 – 200 bytes).

Al procesar los datos de entrada a la vez (sin cálculo secuencial del hash por partes), el problema no aparece. Como método de protección más simple, se propone limitar el tamaño máximo de los datos involucrados en una iteración del cálculo hash.

El código vulnerable se publicó en enero de 2011, por lo que se tardó más de una década en encontrar esta vulnerabilidad. Parece ser difícil encontrar vulnerabilidades en las implementaciones criptográficas, a pesar de que juegan un papel fundamental en la seguridad general de un sistema. (¡Quizás la gente ni siquiera esté buscando tales vulnerabilidades, ya que ni esta vulnerabilidad en XKCP ni la vulnerabilidad de Apple mencionada anteriormente son elegibles para ningún programa de recompensas por errores!)

La vulnerabilidad se debe a un error en el procesamiento de bloques de los datos de entrada. Debido a una comparación incorrecta de los valores con el tipo «int», se determina un tamaño incorrecto de los datos pendientes, lo que hace que la cola se escriba fuera del búfer asignado.

En particular, se menciona que al comparar, se utilizó la expresión «parcialBlock + instancia->byteIOIndex«, que, con valores grandes de las partes componentes, condujo a un desbordamiento de enteros. Además, hubo un encasillado incorrecto «(int sin firmar)(dataByteLen – i)» en el código, lo que provocó un desbordamiento en los sistemas con un tipo size_t de 64 bits.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/vfjbXs2
via IFTTT