Spine, un nuevo emulador de PS4 ha llegado a la ciudad y nos permite jugar a cientos de títulos en Linux

Spine PS4 Emulator

Hace un tiempo me dio por probar un emulador de PS3 en mi portátil. Y bueno, sólo diré que no funcionaba tan bien como PPSSPP porque mi hardware no era el mejor (no recuerdo qué portátil usé). Para los usuarios que tengan un equipo más potente y usen Linux, hace unos días que se ha presentado Spine, un emulador de PS4 que llevaba desarrollándose en secreto desde hace aproximadamente dos años.

Tal y como leemos en Tom’s Hardware, ahora mismo Spine está dando sus primeros pasos, o mejor dicho, se acaba de lanzar la primera demo, disponible en este enlace, donde también hay información sobre cómo instalarla. Si estáis pensando que se podrá ejecutar cualquier juego de PS4, lamento deciros que no es así, que la lista actual es algo corta, pero se irá ampliando con el paso del tiempo.

Spine ya nos permite jugar a títulos de PS4 en Linux, pero no a todos

A lo que podemos jugar en Spine ahora mismo son juegos en 2D que ya están disponibles para PC, por lo que, de momento, hay que olvidarse de jugar al God of War, por ejemplo. Y los juegos en 2D tampoco funcionan perfectamente, como podéis ver en el Sonic naranja que, sinceramente, en un principio había pensado que era Knuckles.

Otra cosa a tener en cuenta es que Spine aun no tiene interfaz gráfica. Y lo peor es que hay que buscar el firmware para que funcione, lo mismo que los juegos (Roms), pero esto es así en casi cualquier emulador del mundo.

En mi opinión, teniendo en cuenta los colores y la falta de interfaz gráfica, creo que deberían haber esperado unos meses más para presentar a Spine, pero la noticia ya ha tenido lugar y ya nadie les quitará el puesto del primer emulador de PS4 para Linux. Ahora falta que lo pulan un poco y, por parte del que quiera usarlo, tener un equipo con una potencia por encima de la media.

from Linux Adictos https://ift.tt/392JkBW
via IFTTT

Armbian 21.08 llega con versiones con Cinnamon, Budgie y mas

Hace pocos dias se presentó la liberación de la nueva versión de la distribución de Linux, «Armbian 21.08» en la cual se han realizado una gran cantidad de actualizaciones de las cuales se destaca la inclusión del Kernel de Linux 5.13, asi como también el soporte añadido para más placas, compilaciones con Cinnamon, budgie y más.

Para quienes desconocen de Armbian deben saber que es una distribución de Linux que proporciona un entorno de sistema compacto para una variedad de computadoras de placa única basadas en ARM.

Para la formación de compilaciones se utilizan los paquetes base de Debian 11 y Ubuntu 21.04, pero el entorno está completamente reconstruido utilizando su propio sistema de compilación con la inclusión de optimizaciones para reducir el tamaño, aumentar el rendimiento y aplicar mecanismos de protección adicionales.

Por ejemplo, la partición /var/log se monta usando zram y se almacena en la RAM en forma comprimida con los datos descargados en la unidad una vez al día o al apagar. La partición / tmp se monta usando tmpfs.

Actualmente la distribución es compatible con los siguientes dispositivos:

  • Banana Pi
  • Beelink X2
  • Clearfog base
  • Clearfog pro
  • Cubieboard
  • Cubietruck
  • Outernet Dreamcatcher
  • Cubox-i
  • Lemaker Guitar
  • Libre Computer Project AML-S905X-CC (Le Potato)[2]
  • Libre Computer Project ALL-H3-CC (Tritium) H2+/H3/H5
  • Lamobo R1
  • Olimex Lime
  • Orange Pi
  • MQmaker Miqi
  • Friendlyarm Nano
  • Odroid
  • Xunlong Orangepi
  • LinkSprite Pcduino
  • pine64so
  • Pinebook64
  • Rock Pi 4
  • RockPro64
  • Roseapple Pi
  • Asus Tinkerboard
  • Udoo
  • Udoo Neo

Principales novedades de Armbian 21.08

En esta nueva versión de la distribución una de las novedades que se destaca son las compilaciones con los entornos de escritorio de Cinnamon y Budgie, con lo cual como resultado, a partir de esta nueva versión se proporcionan cuatro opciones de compilación: mínima, servidor y compilaciones con escritorios Xfce, Cinnamon y Budgie, además de que tambien se ha proporcionado una compilación experimental con el escritorio KDE.

En Armbian 21.08 podremos encontrar que viene con el kernel de Linux versión 5.13 y que además cuenta con el soporte de arranque SPI ahora está disponible para las placas Odroid HC4 y se implementó la selección de idioma automatizada en el primer lanzamiento.

Por otra parte, se destaca que la implementación del sistema de archivos ZFS se ha actualizado a OpenZFS 2.1, se ha añadido el soporte agregado para placas Khadas VIM1-3 y Edge y Avnet Microzed y la compatibilidad con VPU está habilitada para placas Rockchip junto con compilaciones para QEMU.

Otra de las novedades que podremos encontrar es que se ha añadido el soporte de aceleración 3D habilitada cuando es compatible, tambien se proporcionó la capacidad de usar el shell ZSH o BASH.

De los demás cambios que se destacan de esta nueva version:

  • Se agregaron máscaras de CSC para Tinkerboard 2 y Rockpi N10.
  • Se agregó soporte para kernels antiguos para placas OrangepiZero2 y Nvidia Jetson.
  • Capacidad de compilación estabilizada con los paquetes Ubuntu 21.04 y Debian 11. Se agregó soporte para Ubuntu 21.10 y Debian Sid como beta.

Por la parte de los problemas conocidos los desarrolladores mencionan que la aceleración de gráficos 3D tuvo que desactivarse en Amlogic debido a la inestabilidad, el problema de arranque de Odroid C4/HC4 persiste, pero se solucionará en la próxima versión, y varios entornos de escritorio (Deepin, Enlightenment, Gnome, i3, KDE plasma, Mate, Xmonad) que por el momento no son oficialmente candidatos para estar dentro de las compilaciones, aunque todavía está disponible en el sistema de compilación, debido a la falta de espacio y mantenimiento.

Finalmente, si quieres conocer más al respecto sobre esta nueva versión de la distribución, puedes consultar los detalles en el siguiente enlace.

Descargar Armbian

Para quienes estén interesados en poder descargar la nueva versión de esta distribución para su dispositivo, podrán hacerlo directamente desde la página de descarga de en donde podremos encontrar un listado de todas las computadoras basadas en ARM en las que se ejecuta la distribución.

En cuanto a la herramienta que puedes utilizar para grabar la imagen del sistema, puedes hacer uso de Etcher la cual es una herramienta multiplataforma o directamente en Linux desde la terminal con ayuda del comando DD o alguna que ustedes consideren pertinente.

El enlace de descarga es este.

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

postmarketOS 21.06 Service Pack 2 llega con Phosh 0.12.1 y otras mejoras

 

PostmarketOS 21.06

Lo de los sistemas operativos móviles basados en Linux, Android aparte, es una historia con muchos capítulos en la que se avanza despacio. En la actualidad no son pocos los proyectos que lo están intentando, entre los que destacan Mobian, Arch Linux, Manjaro, Ubuntu Touch o el protagonista de este artículo que hoy ha lanzado postmarketOS 21.06 Service Pack 2. Llega con algunas novedades, de entre las que destacan su núcleo e interfaz gráfica.

postmarketOS 21.06 Service Pack 2 ha subido Phosh a la versión 0.12.1, pero no menos importantes son las actualizaciones del núcleo y este SP2 usa el  Linux 5.13-20210819-1611 de megi. Sobre el resto de novedades, no son muchas, y tenéis un resumen tras el corte.

Novedades más destacadas de postmarketOS 21.06 Service Pack 2

  • Megapixels 1.3.0, con mejoras de rendimiento y nuevo post-procesamiento de imágenes. La imagen de la nota de lanzamiento de este Service Pack fue tomada con esta versión de Megapixels en un PinePhone, lo que tiene emocionados a sus desarrolladores hasta el punto de animar a los usuarios a probar la cámara de sus dispositivos de PINE64.
  • Phosh 0.12.1
  • El kernel 5.13-20210819-1611 de megi para el PinePhone y el PineTab.
  • Light daemon ya está disponible para su uso en Sxmo.
  • gpodder-adaptive 3.10.21, con importantes correcciones de rendimiento y de la interfaz de usuario.
  • u-boot-pinephone 2017.07 con una nueva versión de la corteza que mejora significativamente la vida de la batería en espera.

La v21.06 de postmarketOS llegó a principios de junio basada en Alpine 3.14. En cuanto a Phosh, es uno de los entornos preferidos por muchos, sobre todo para aquellos que usan el sistema en un teléfono móvil o en una tablet con teclado. Si se prefiere Plasma, podéis visitar nuestro tutorial sobre cómo instalarlo en, por ejemplo, un PinePhone o una PineTab. Aunque tengo que avisar de que, aunque apunta maneras y nos permita hacer mucho más que Ubuntu Touch, Plasma Mobile tiene muchos más bugs que Phosh.

from Linux Adictos https://ift.tt/3htY7tV
via IFTTT

Apache OpenMeetings 6.1 llega diversas correcciones de errores y algunas mejoras

La Apache Software Foundation dio a conocer hace ya varios dias el lanzamiento de la nueva versión del servidor de conferencias web Apache OpenMeetings 6.1, que permite conferencias de audio y video a través de la Web, así como la colaboración y la mensajería entre los participantes.

En esta nueva versión de OpenMeetings 6.1 se han realizado diversas correcciones de errores de las cuales la mayoría de ellas fueron enfocadas en solucionar los problemas que se tenían en relación con la compatibilidad con algunos navegadores web y tambien en la interfaz. 

Para quienes desconocen de OpenMeetings, deben saber que este es un software de conferencias web que admiten tanto los seminarios web con un orador como las conferencias con un número arbitrario de participantes que interactúan entre sí. El código del proyecto está escrito en Java y distribuido bajo la licencia Apache 2.0.

Las características adicionales incluyen: herramientas para integrarse con un programador de calendario, enviar notificaciones e invitaciones individuales o de transmisión, compartir archivos y documentos, mantener la libreta de direcciones de los participantes, mantener un registro del evento, programar tareas de manera conjunta, transmitir el resultado de las aplicaciones en ejecución (demostración de screencast), realización de votaciones y votaciones.

Un servidor puede servir a un número arbitrario de conferencias celebradas en salas de conferencias virtuales separadas e incluyendo su propio conjunto de participantes. El servidor admite herramientas de gestión de permisos flexibles y un potente sistema de moderación de conferencias. La gestión e interacción de los participantes se realiza a través de la interfaz web.

Principales novedades de Apache OpenMeetings 6.1

En esta nueva versión que se presenta los desarrolladores destacan que han realizado pequeñas mejoras en la interfaz web y se ha mejorado la compatibilidad con los navegadores web, además de que se solucionaron diversos errores que afectaban enormemente el funcionamiento, como por ejemplo que la aplicación de prueba de audio/video no funcionaba con Safari, no había sonido y la cuenta regresiva no funcionaba, había fallas en la descarga de archivos, la herramienta no se mostraba correctamente, la grabación de la sala de entrevistas no funcionaba, se finalizaba de manera inesperada la sesión, lista de usuarios vacía en la sala de presentación, entre otras cosas más.

En la parte de las mejoras que se implementaron en esta nueva versión, esta por ejemplo que en la sección «Admin -> Config» ahora se pueden cambiar los temas, se han mejorado los permisos de administrador, se ha agregado un menú adicional configurable por el usuario a las habitaciones, localización fue mejorada del formulario de cambio de fecha y hora, se mejoró la estabilidad de las salas de conferencias y fueron resueltos diversos problemas relacionados con el uso compartido de pantalla.

De los demás cambios que se destacan en esta nueva versión:

  • Solución al error al presionar los botones Recording o Share-desktop
  • Actualización de las nuevas versiones de la biblioteca
  • Se abordaron los problemas informados por Sonar
  • Fusión de las contribuciones de etiquetas
  • Mejorar el ícono de carga del archivo
  • Menú de ayuda para la sala
  • Marcar grupo predeterminado en administración-> grupos
  • Wigets-page: apariencia y apariencia como otras listas

Finalmente si quieres conocer más al respecto sobre la liberación de esta nueva versión, puedes consultar los detalles dentro del anuncio oficial. El enlace es este.

¿Cómo obtener Apache OpenMeetings 6.1?

Finalmente, para quienes estén interesados en poder obtener esta nueva versión, pueden dirigirse al sitio web oficial del proyecto y en su sección de descargas podrán encontrar los paquetes binarios, así como también el código para su compilación o también una imagen de Docker ya preparada.

El enlace es este.

Mientras que para el caso de los que usan Arch Linux y derivados podrán encontrar el paquete ya listo en AUR.

También, pueden seguir las instrucciones que se detallan en este enlace, en donde simplemente tendrán que descargar el ultimo paquete estable de la aplicacion, desempaquetar y ejecutar el binario para que inicie el instalador web.

El enlace es este.

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

SDL 2.0.16 llega con mejoras para Wayland, Pipewire y mas

Hace ya varios dias se dio a conocer la liberación de la nueva versión de la biblioteca SDL 2.0.16 (Simple DirectMedia Layer), destinada a simplificar la escritura de juegos y aplicaciones multimedia. En esta nueva versión se han añadido diversos cambios, entre los cuales se destacan las mejoras de soporte para Wayland, asi como tambien la capacidad de generar y capturar audio usando el servidor multimedia Pipewire y otras cosas más.

Para quienes desconocen de la biblioteca SDL, deben saber que esta, proporciona herramientas como salida de gráficos 2D y 3D acelerada por hardware, procesamiento de entrada, reproducción de audio, salida 3D a través de OpenGL/OpenGL ES y muchas otras operaciones relacionadas.

SDL es oficialmente compatible con Windows, Mac OS X, Linux, iOS y Android, aun que cuenta con el soporte para otras plataformas como QNX, además de otras arquitecturas y sistemas como Sega Dreamcast, GP32, GP2X, etc.

Simple DirectMedia Layer está escrito en C, funciona de forma nativa con C ++ y hay enlaces disponibles para varios otros idiomas, incluidos C # y Python, se distribuye bajo la licencia zlib, esta licencia permite usar SDL libremente en cualquier software.

Pese a estar programado en C, tiene wrappers a otros lenguajes de programación como C++, Ada, C#, BASIC, Erlang, Lua, Java, Python, etc.

Principales novedades de SDL 2.0.16

En esta nueva versión que se presenta de SDL una de las novedades que se destaca es que el soporte para Wayland se ha mejorado enormemente, además de que se ha añadido la capacidad de generar y capturar audio usando el servidor multimedia Pipewire y AAudio (Android) y tambien el soporte para los controladores de juegos Amazon Luna y Xbox Series X.

Otro de los cambios que podremos encontrar es que se agregó soporte para el efecto de vibración adaptativa (retumbar) en los controladores Google Stadia y Nintendo Switch Pro cuando se usa el controlador HIDAPI.

Además de ello la carga del CPU ha sido reducida al procesar las llamadas SDL_WaitEvent() y SDL_WaitEventTimeout() y tambien se ha añadido una definición de extensiones SIMD compatibles con la plataforma Elbrus.

Por la parte de las nuevas características que se han propuesto en esta nueva versión, se mencionan las siguientes:

  • SDL_FlashWindow(): permite captar la atención del usuario.
  • SDL_GetAudioDeviceSpec(): es para obtener información sobre el formato de audio preferido para el dispositivo especificado.
  • SDL_SetWindowAlwaysOnTop(): está orientada a cambiar dinámicamente el indicador SDL_WINDOW_ALWAYS_ON_TOP (anclar sobre otro contenido) para la ventana seleccionada.
  • SDL_SetWindowKeyboardGrab(): para capturar la entrada del teclado independientemente del mouse.
  • SDL_SoftStretchLinear(): para escalado bilineal entre superficies de 32 bits.
  • SDL_UpdateNVTexture(): para actualizar texturas en NV12/21.
  • SDL_GameControllerSendEffect() y SDL_JoystickSendEffect(): para enviar efectos personalizados a los controladores de juego DualSense.
  • SDL_GameControllerGetSensorDataRate():para obtener datos sobre la intensidad de la información recibida de los sensores de los controladores de juegos de PlayStation y Nintendo Switch.
  • SDL_AndroidShowToast(): esta permite mostrar notificaciones ligeras en la plataforma Android.

Finalmente si estás interesado en poder conocer más al respecto de esta nueva versión, puedes consultar los detalles en el siguiente enlace.

¿Como instalar Simple DirectMedia Layer en Linux?

La instalación de esta biblioteca en Linux es bastante sencilla puesto que la mayoría de las distribuciones de Linux cuentan con ella dentro de sus repositorios.

Para el caso de Debian, Ubuntu y distribuciones derivadas de estos, solo tendrán que ejecutar los siguientes comandos en una terminal:

sudo apt-get install libsdl2-2.0
sudo apt-get install libsdl2-dev

Mientras que para el caso de los que son usuarios de Arch Linux solo tenemos que ejecutar lo siguiente:

sudo pacman -S sdl2

Para el caso de los que son usuarios de Fedora, Centos, RHEL o cualquier distribución basada en estas, solo tienen que ejecutar el siguiente comando:

sudo yum install SDL2
sudo yum install SDL2-devel

Para el resto de las distribuciones de Linux, pueden realizar la búsqueda del paquete “sdl” o “libsdl” para su instalación o realizar la descarga y compilación del código fuente.

Esto lo hacen con:

git clone https://hg.libsdl.org/SDL SDL
cd SDL
mkdir build
cd build
./configure
make
sudo make install

from Linux Adictos https://ift.tt/3C8vydC
via IFTTT

Pacstall pretende ser un AUR para Ubuntu. ¿Lo consigue?

Pacstall

En cualquier distribución Linux se puede instalar software por distintos medios. Uno es el de los repositorios oficiales, pero también podemos usar paquetes flatpak, snap y AppImage, entre otros. Además de todo esto, Arch Linux tiene AUR, un repositorio de la comunidad en el que encontramos prácticamente todo el software que existe para Linux y que, si no sabemos compilar, podemos gestionar con yay. Por ejemplo, en AUR encontramos extensiones para GIMP que de otra manera tendríamos que buscar, por lo que es la envidia de otras distribuciones. Para intentar suplir esta carencia en Ubuntu existe Pacstall.

Sobre el papel, Pacstall tiene muy buena pinta. Se supone que es una herramienta para automatizar instalaciones de software alojado en GitHub o GitLab en Ubuntu. Nació hace algo más de un año, por lo que podríamos decir que está dando sus primeros pasos, pero, por lo menos ahora mismo, a los usuarios de un sistema operativo basado en Arch sólo puede hacernos gracia por la enorme diferencia.

Pacstall tiene su propio repositorio y se pueden añadir más

El equipo de Pacstall está subiendo los paquetes al repositorio oficial del proyecto, y esta es la principal diferencia con respecto a AUR. El repositorio de la comunidad de Arch lleva años existiendo, y allí se encuentra de todo. En lo que pretende ser su equivalente para Ubuntu llevan subiendo paquetes muy poco tiempo, por lo que la lista de paquetes disponibles es corta.

La duda que tengo al haberlo probado y leído por encima su documentación es cómo será en el futuro. Esta especie de gestor de paquetes permite añadir repositorios, pero en estos momentos la instalación falla porque falta el archivo pacscript necesario para instalar los paquetes. Si en el futuro corrigen esto (o si estoy haciendo algo mal y alguien sabe lo que es, que me lo diga), quizá no sea AUR, pero sí una herramienta muy interesante.

¿Y cómo funciona?

Lo primero que hay que hacer es instalarlo, algo que conseguiremos abriendo un terminal y escribiendo estos comandos:

sudo apt install curl
sudo bash -c "$(curl -fsSL https://git.io/JsADh || wget -q https://git.io/JsADh -O -)"

A partir de ahí, el resto es como apt, pacman, dnf, etc, pero a su manera:

  • pacstall seguido de:
    • -I: instalará el paquete.
    • -R: eliminará el paquete.
    • -S: buscará en los repositorios.
    • -A: añadirá un repositorio de GitHub o GitLab.
    • -U: actualizará los scripts de pacstall.
    • -Up: actualizará los paquetes.
    • -h: ayuda.

Si queremos desinstalarlo, lo que tenemos que escribir es lo siguiente:

bash -c "$(curl -fsSL https://git.io/JEZbi || wget -q https://git.io/JEZbi -O -)"

Estaría bien que Ubuntu tuviera su propio AUR, y no sé si Pacstall llegará algún día a parecerse aunque sea mínimamente. De momento sí hay paquetes como Android Studio o Google Chrome. Si la comunidad se va apuntando a colaborar, veremos hasta dónde llega este proyecto.

from Linux Adictos https://ift.tt/3yZVJ41
via IFTTT

Microsoft contra el SVR. Por qué el código abierto debería ser la norma

Microsoft contra el SVR

Podría haber sido una novela de Tom Clancy de la serie NetForce, pero es un libro escrito por el presidente de Microsoft Brad Smith en homenaje a si mismo y a su empresa. De todas formas, si uno lee entre líneas (al menos en el extracto al que tuvo acceso un portal) y separa las auto palmadas en la espalda y los palos a los competidores, lo que queda es muy interesante e instructivo. Y, en mi humilde opinión, una muestra de las ventajas del modelo de software libre y de código abierto.

Los personajes

Toda novela de espionaje, necesita un «malo» y, en este caso tenemos nada menos que al SVR, una de las organizaciones que sucedieron al KGB después del colapso de la URSS. El SVR se ocupa de todas las tareas de inteligencia desarrolladas fuera de la frontera de la Federación Rusa. La «víctima inocente» fue SolarWinds, empresa que desarrolla un software para administración de redes utilizado por grandes empresas, administradores de infraestructuras críticas y agencias del gobierno estadounidense. Por supuesto, necesitamos un héroe. En este caso, según ellos mismos, es el Departamento de Inteligencia de Amenazas de Microsoft.

Como no podía ser de otra manera, en una historia de hackers, el «malo» y el «bueno» tienen un alias. El SVR es Yttrium (Itrio). En Microsoft utilizan los elementos menos comunes de la tabla periódica como nombre clave para los posibles orígenes de amenazas. El Departamento de Inteligencia de Amenazas es MSTIC por sus siglas en inglés, aunque internamente lo pronuncian mystic (místico) por la similitud fonética. En adelante, por comodidad voy a usar estos términos.

Microsoft contra SVR. Los hechos

El 30 de noviembre de 2020 FireEye, una de las principales empresas de seguridad informática de EE.UU, descubre que había sufrido una brecha de seguridad en sus propios servidores. Como eran incapaces de solucionarlo por si mismos (Lo siento, pero no puedo dejar de decir lo de «en casa de herrero, cuchillo de palo») decidieron pedir ayuda a los especialistas de Microsoft. Como desde MSTIC venían siguiendo los pasos de Yttrium, enseguida sospecharon de los rusos, diagnóstico posteriormente confirmada por los servicios de inteligencia oficiales de USA.

Con el correr de los días, se comprobó que los ataques estaban dirigidos a redes informáticas sensibles en todo el mundo incluyendo a la propia Microsoft. De acuerdo a trascendidos periodísticos, el gobierno de Estados Unidos era claramente el principal objetivo del ataque, con el Departamento del Tesoro, el Departamento de Estado, el Departamento de Comercio, el Departamento de Energía y partes del Pentágono Por su parte, desde Redmond agregaron a la lista de víctimas docenas de organizaciones afectadas. Entre ellas se cuentan otras empresas tecnológicas, contratistas gubernamentales, grupos de reflexión y una universidad. Los ataques no solo se dirigieron contra Estados Unidos ya que hubo afectados en Canadá, el Reino Unido, Bélgica, España, Israel y los Emiratos Árabes Unidos. En algunos de los casos, las penetraciones en la red se prolongaron durante varios meses.

El origen

Todo comenzó con un software de manejo de redes llamado Orion y desarrollado por una empresa llamada SolarWinds. Con más de 38000 clientes corporativos de alto nivel, los atacantes solo tuvieron que insertar un malware en una actualización.

Una vez instalado, el malware se conectaba a lo que técnicamente se conoce como un servidor de comando y control (C2). El servidor C2 estaba programado para dar al ordenador conectado tareas como la capacidad de transferir archivos, ejecutar comandos, reiniciar una máquina y desactivar los servicios del sistema. En otras palabras los agentes de Yttrium conseguían un acceso total a la red de quienes habían instalado la actualización del programa Orion.

A continuación les voy a citar un párrafo textual del artículo de Smith

No tardamos en darnos cuenta de la importancia del trabajo técnico en equipo en toda la industria y con el gobierno de Estados Unidos. Los ingenieros de SolarWinds, FireEye y Microsoft empezaron a trabajar juntos inmediatamente. Los equipos de FireEye y Microsoft se conocían bien, pero SolarWinds era una empresa más pequeña que se enfrentaba a una gran crisis, y los equipos tenían que crear confianza rápidamente si querían ser eficaces. Los ingenieros de SolarWinds compartieron el código fuente de su actualización con los equipos de seguridad de las otras dos empresas, lo que reveló el código fuente del propio malware. Los equipos técnicos del gobierno estadounidense entraron rápidamente en acción, especialmente en la Agencia de Seguridad Nacional (NSA) y en la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) del Departamento de Seguridad Nacional.

Los resaltados son míos. Eso de trabajo en equipo y compartir el código fuente ¿No les suena de algo?

Después de abrir la puerta trasera, el malware permanecia inactivo durante dos semanas, para evitar crear entradas de registro de red que alertaran a los administradores. Pasado ese lapso, enviaba información sobre la red que había infectado a un servidor de mando y control que los atacantes habían con el proveedor de hosting GoDaddy.

Si el contenido resultaba interesante para Yttrium, los atacantes entraban a través de la puerta trasera e instalaban código adicional en el servidor atacado para conectarse a un segundo servidor de mando y control. Este segundo servidor, único para cada víctima para ayudar a evadir la detección, estaba registrado y alojado en un segundo centro de datos, a menudo en la nube de Amazon Web Services (AWS).

Microsoft contra el SVR. La moraleja

Si están interesados en saber como nuestros héroes dieron su merecido a los villanos, en los primeros párrafos tienen los enlaces a las fuentes. Voy a pasar directamente al motivo por el cuál escribo sobre esto en un blog sobre Linux. El enfrentamiento de Microsoft contra el SVR demuestra la importancia de que el código esté disponible para ser analizado, y que el conocimiento sea colectivo.

Es cierto, como me recordó esta mañana un prestigioso especialista en el tema seguridad informática, que de nada sirve que el código sea abierto si nadie se toma el trabajo de analizarlo. Está el caso Heartbleed para demostrarlo. Pero, recapitulemos. 38000 clientes de alto nivel contrataron un software privativo. Varios de ellos instalaron una actualización con malware que expuso información sensible y dio control a elementos hostiles de infraestructura crítica. La empresa responsable solo puso el código a disposición de los especialistas cuando estaba con el agua al cuello. Si se exigiera a los proveedores de software para infraestructura crítica y clientes sensibles liberar su software con licencias abiertas, y a estos tener un auditor de código residente (o una agencia externa que trabaje para varios) el riesgo de ataques como SolarWinds sería mucho menor.

from Linux Adictos https://ift.tt/3BXBwOe
via IFTTT

Microsoft contra el SVR. Por qué el código abierto debería ser la norma

Microsoft contra el SVR

Podría haber sido una novela de Tom Clancy de la serie NetForce, pero es un libro escrito por el presidente de Microsoft Brad Smith en homenaje a si mismo y a su empresa. De todas formas, si uno lee entre líneas (al menos en el extracto al que tuvo acceso un portal) y separa las auto palmadas en la espalda y los palos a los competidores, lo que queda es muy interesante e instructivo. Y, en mi humilde opinión, una muestra de las ventajas del modelo de software libre y de código abierto.

Los personajes

Toda novela de espionaje, necesita un «malo» y, en este caso tenemos nada menos que al SVR, una de las organizaciones que sucedieron al KGB después del colapso de la URSS. El SVR se ocupa de todas las tareas de inteligencia desarrolladas fuera de la frontera de la Federación Rusa. La «víctima inocente» fue SolarWinds, empresa que desarrolla un software para administración de redes utilizado por grandes empresas, administradores de infraestructuras críticas y agencias del gobierno estadounidense. Por supuesto, necesitamos un héroe. En este caso, según ellos mismos, es el Departamento de Inteligencia de Amenazas de Microsoft.

Como no podía ser de otra manera, en una historia de hackers, el «malo» y el «bueno» tienen un alias. El SVR es Yttrium (Itrio). En Microsoft utilizan los elementos menos comunes de la tabla periódica como nombre clave para los posibles orígenes de amenazas. El Departamento de Inteligencia de Amenazas es MSTIC por sus siglas en inglés, aunque internamente lo pronuncian mystic (místico) por la similitud fonética. En adelante, por comodidad voy a usar estos términos.

Microsoft contra SVR. Los hechos

El 30 de noviembre de 2020 FireEye, una de las principales empresas de seguridad informática de EE.UU, descubre que había sufrido una brecha de seguridad en sus propios servidores. Como eran incapaces de solucionarlo por si mismos (Lo siento, pero no puedo dejar de decir lo de «en casa de herrero, cuchillo de palo») decidieron pedir ayuda a los especialistas de Microsoft. Como desde MSTIC venían siguiendo los pasos de Yttrium, enseguida sospecharon de los rusos, diagnóstico posteriormente confirmada por los servicios de inteligencia oficiales de USA.

Con el correr de los días, se comprobó que los ataques estaban dirigidos a redes informáticas sensibles en todo el mundo incluyendo a la propia Microsoft. De acuerdo a trascendidos periodísticos, el gobierno de Estados Unidos era claramente el principal objetivo del ataque, con el Departamento del Tesoro, el Departamento de Estado, el Departamento de Comercio, el Departamento de Energía y partes del Pentágono Por su parte, desde Redmond agregaron a la lista de víctimas docenas de organizaciones afectadas. Entre ellas se cuentan otras empresas tecnológicas, contratistas gubernamentales, grupos de reflexión y una universidad. Los ataques no solo se dirigieron contra Estados Unidos ya que hubo afectados en Canadá, el Reino Unido, Bélgica, España, Israel y los Emiratos Árabes Unidos. En algunos de los casos, las penetraciones en la red se prolongaron durante varios meses.

El origen

Todo comenzó con un software de manejo de redes llamado Orion y desarrollado por una empresa llamada SolarWinds. Con más de 38000 clientes corporativos de alto nivel, los atacantes solo tuvieron que insertar un malware en una actualización.

Una vez instalado, el malware se conectaba a lo que técnicamente se conoce como un servidor de comando y control (C2). El servidor C2 estaba programado para dar al ordenador conectado tareas como la capacidad de transferir archivos, ejecutar comandos, reiniciar una máquina y desactivar los servicios del sistema. En otras palabras los agentes de Yttrium conseguían un acceso total a la red de quienes habían instalado la actualización del programa Orion.

A continuación les voy a citar un párrafo textual del artículo de Smith

No tardamos en darnos cuenta de la importancia del trabajo técnico en equipo en toda la industria y con el gobierno de Estados Unidos. Los ingenieros de SolarWinds, FireEye y Microsoft empezaron a trabajar juntos inmediatamente. Los equipos de FireEye y Microsoft se conocían bien, pero SolarWinds era una empresa más pequeña que se enfrentaba a una gran crisis, y los equipos tenían que crear confianza rápidamente si querían ser eficaces. Los ingenieros de SolarWinds compartieron el código fuente de su actualización con los equipos de seguridad de las otras dos empresas, lo que reveló el código fuente del propio malware. Los equipos técnicos del gobierno estadounidense entraron rápidamente en acción, especialmente en la Agencia de Seguridad Nacional (NSA) y en la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) del Departamento de Seguridad Nacional.

Los resaltados son míos. Eso de trabajo en equipo y compartir el código fuente ¿No les suena de algo?

Después de abrir la puerta trasera, el malware permanecia inactivo durante dos semanas, para evitar crear entradas de registro de red que alertaran a los administradores. Pasado ese lapso, enviaba información sobre la red que había infectado a un servidor de mando y control que los atacantes habían con el proveedor de hosting GoDaddy.

Si el contenido resultaba interesante para Yttrium, los atacantes entraban a través de la puerta trasera e instalaban código adicional en el servidor atacado para conectarse a un segundo servidor de mando y control. Este segundo servidor, único para cada víctima para ayudar a evadir la detección, estaba registrado y alojado en un segundo centro de datos, a menudo en la nube de Amazon Web Services (AWS).

Microsoft contra el SVR. La moraleja

Si están interesados en saber como nuestros héroes dieron su merecido a los villanos, en los primeros párrafos tienen los enlaces a las fuentes. Voy a pasar directamente al motivo por el cuál escribo sobre esto en un blog sobre Linux. El enfrentamiento de Microsoft contra el SVR demuestra la importancia de que el código esté disponible para ser analizado, y que el conocimiento sea colectivo.

Es cierto, como me recordó esta mañana un prestigioso especialista en el tema seguridad informática, que de nada sirve que el código sea abierto si nadie se toma el trabajo de analizarlo. Está el caso Heartbleed para demostrarlo. Pero, recapitulemos. 38000 clientes de alto nivel contrataron un software privativo. Varios de ellos instalaron una actualización con malware que expuso información sensible y dio control a elementos hostiles de infraestructura crítica. La empresa responsable solo puso el código a disposición de los especialistas cuando estaba con el agua al cuello. Si se exigiera a los proveedores de software para infraestructura crítica y clientes sensibles liberar su software con licencias abiertas, y a estos tener un auditor de código residente (o una agencia externa que trabaje para varios) el riesgo de ataques como SolarWinds sería mucho menor.

from Linux Adictos https://ift.tt/3BXBwOe
via IFTTT

WINE 6.17 vuelve a mejorar el soporte para DPI e introduce casi 400 cambios

WINE 6.17

WineHQ ha vuelto a cumplir puntual con su calendario y, tras la anterior v6.16, hoy ha lanzado WINE 6.17. Se trata de una nueva versión Staging, etiqueta que reciben las versiones de desarrollo en las que van añadiendo novedades cada dos semanas, pero las cosas no están tan pulidas como para que la etiqueta sea Estable. Como casi siempre en esta fase del desarrollo, el equipo del proyecto ha aprovechado para introducir muchos cambios.

En WINE 6.17 se han corregido 12 bugs, pero han realizado 375 cambios en total. Entre ellos, esta semana han vuelto a destacar algo relacionado al DPI junto a otros cuatro puntos, siendo el último el habitual corrección de errores. La lista de novedades que han considerado lo suficientemente importantes como para separarlas del resto es la siguiente.

Novedades más destacadas de WINE 6.17

  • Programa WineCfg convertido a PE.
  • Mejor soporte de alta DPI en las aplicaciones incorporadas.
  • Más trabajo de preparación para la interfaz GDI syscall.
  • Soporte mejorado del depurador en modo Wow64.
  • Varias correcciones de errores.

WINE 6.17, del que tenemos que volver a recordar que es una versión Staging o de desarrollo y no estable, ya se puede descargar desde este o este otro enlace. El proyecto también aporta información para descargar esta y futuras actualizaciones añadiendo el repositorio oficial para Linux aquí, pero también se puede instalar en macOS y Android. Si se añade el repositorio se puede elegir entre las versiones estable, Staging o Dev.

En este punto del desarrollo, ya nos estamos acercando al momento en el que empezarán a llegar las Release Candidates, pero lo más probable es que la próxima versión sea WINE 6.18 y que sea lanzada el próximo 24 de septiembre. En WINE 5.x se lanzaron 22 versiones Staging, momento en el que ya pasaron a lanzar las Release Candidates semanalmente. Si se confirma la nueva versión Staging, volverán a introducir cientos de retoques.

from Linux Adictos https://ift.tt/38UdMOG
via IFTTT

Microsoft libero el código fuente de GCToolkit

Microsoft ha dado a conocer hace pocos dias la noticia de que ha liberado el código fuente de su herramienta «GCToolkit», el cual es un conjunto de bibliotecas para analizar los archivos de registro de Java Garbage Collection, con lo cual todo el código de GCToolkit está disponible en GitHub bajo la licencia MIT.

GCToolkit consta de tres módulos Java que cubren API, analizadores de archivos de registro de GC y una placa posterior de mensajes basada en el kit de herramientas Vert.x para crear aplicaciones receptivas en la JVM. Con esta utilidad, los usuarios pueden crear exploraciones arbitrarias y complejas del estado de la memoria administrada en la JVM.

Como su nombre indica, este es un conjunto de bibliotecas para analizar archivos de registro de recolección de basura (GC) de Java y analizarlos en eventos separados. Expone una API para mejorar la interacción con el kit de herramientas y la agregación de datos, esto permite al usuario crear análisis complejos arbitrarios del estado de la memoria administrada de la JVM.

Según el equipo, este es el punto de entrada del usuario en GCToolkit que oculta los detalles de los módulos internos en unas pocas llamadas a métodos. Además de la API, hay otros dos módulos: el módulo de análisis sintáctico y Vert.x. El Módulo Analizador se basa en una colección de expresiones regulares y código escrito para ser considerado el analizador de registros GC más robusto disponible.

El back-end de mensajería basado en Vert.xutiliza dos buses de mensajes: el primero transmite datos desde una fuente de datos. La implementación actual pasa líneas de registro del archivo de registro de GC. Los consumidores de este bus son los analizadores que convierten los datos de la fuente de datos en eventos que representan un ciclo de GC o un punto seguro. Estos eventos se publican en el segundo bus de mensajes: el bus de eventos. Los suscriptores del bus de eventos pueden entonces ser notificados y procesar los eventos que les interesan.

El analizador emite eventos JVM discretos, lo que le permite escribir código para capturar y analizar datos de estos eventos. Para facilitar la captura de datos y el análisis de los archivos de registro de GC, GCToolkit proporciona un marco de agregación simple. El tipo de datos que los usuarios desean capturar o el tipo de análisis que desean realizar queda a discreción del usuario. Por ejemplo, para capturar eventos de pausa con el fin de analizar la ocupación del montón, el agregador captura el evento, extrae los datos relevantes y pasa los datos a la agregación.

Esto reúne los datos en un análisis significativo, por ejemplo, la ocupación total del montón después de la recolección de basura. Los datos resultantes se pueden presentar en forma de gráfico, tabla u otro formato más fácil de usar. Más importante aún, según el equipo, una configuración subóptima del colector resultará en una aplicación que requerirá más CPU y memoria, mientras degrada la experiencia del usuario final. En otras palabras, un colector mal ajustado a menudo significa un tiempo de ejecución más caro y usuarios insatisfechos.

Con el creciente interés de Microsoft en la plataforma Java, el enfoque en el código abierto también está aumentando los beneficios para la comunidad Java. Después de realizar importantes contribuciones para portar macOS M1 y Windows to Arm, Microsoft reafirmó su compromiso con OpenJDK al presentar su propia versión de OpenJDK y uniéndose al grupo de trabajo Eclipse Adoptium (anteriormente conocido como AdoptOpenJDK).

Al hacer que GCToolkit sea de código abierto, Microsoft está intentando proporcionar una mejor manera de ver los detalles internos de la JVM sobre cómo maneja GC y la asignación de memoria. Una mejor visibilidad permite una mejor configuración, lo que beneficia tanto a los usuarios finales de la aplicación como al personal técnico responsable de su gestión.

La API simple y los mecanismos de salida fáciles de usar prometen mejorar la tarea de leer los registros de GC al proporcionar varios mecanismos para analizar, extraer y visualizar datos.

Fuente: https://devblogs.microsoft.com

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