logo de ntpsec

NTPsec es un proyecto de código abierto que se centra en el desarrollo de una implementación segura y mejorada del Protocolo de Tiempo de Red (NTP), el cual es ampliamente utilizado para sincronizar los relojes de los sistemas informáticos en una red, asegurando una medición precisa y consistente del tiempo.

Este tipo de componentes, suelen ser los que la mayoría de los usuarios ignoramos (y me incluyo porque hasta hace algunos meses no había comprendido la importancia de este pequeño protocolo), ya que al ser algo que está detrás de nuestro día a día, es algo que pasa desapercibido.

En mi caso descubrí la importancia de NTP al querer realizar una «simple actualización» de mi sistema (Arco Linux) que deje durante varios meses sin abrir. Para no hacer el cuento largo, después de que se descargaron todas las actualizaciones y en teoría se debían instalar, simplemente no se instalaron, pues me aparecían un problema con las claves OpenPGP de los paquetes y por obvias razones de haber dejado el sistema durante meses, esto hiba a generar un grave problema.

Después de haber hecho 101 y una cosas e intentar de todo e incluso exorcizar a mi equipo, simplemente no podía resolver mi problema y la solución más próxima era volver a instalar el sistema desde cero, algo que no era de mi agrado.

Algo que note durante todo el proceso de intentar solucionar el problema, es que la hora de mi sistema era diferente a la de mi localidad e investigando un poco ese pequeño cambio horario generaba un problema al intentar importar las claves nuevas (tal y como lo menciona la bendita wiki de arch). Al leer esto, una palmada en mi frente fue lo primero que genero y procedí a intentar cambiar la hora e inmediatamente procedí a reiniciar para verificar si la fecha y hora del BIOS eran correctos, lo cual asi era. Posterior a ello volví a iniciar el sistema a disponerme a realizar el cambio como si de un proceso común en Windows o Android se tratara, y lo cual fue grave error de tener las costumbres antes de analizar.

Por más que intente resolver el problema de una forma u otra, lo que generaba el problema en mi sistema era el paquete ntp de mi instalación, por alguna razón que nunca pude resolver el paquete simplemente me estaba causando problemas. Aquí es donde encontré NTPsec la cual fue mi solución después de varias ahora de intentar solucionar mi problemática.

NTPsec es una implementación mejorada de NTP que cuenta con muchas mejoras de seguridad, pues cuenta con la implementación del estándar Network Time Security de IETF para una autenticación criptográfica sólida del servicio horario. En total, más del 74% del código base de NTP Classic se ha eliminado por completo, y se ha agregado menos del 5% de código nuevo al núcleo crítico para la seguridad y también hay un uso más consistente de la precisión de nanosegundos.

Entre las mejoras de seguridad, se eliminaron modos y funciones obsoletas, se adoptó el estándar RFC de Minimización de datos del cliente NTP y se incorporó la seguridad de tiempo de red. Además, se realizaron cambios en la sincronización horaria y mejoras en las herramientas del cliente, con nuevas utilidades como ntpmon y ntpviz para monitoreo en tiempo real y visualización de datos, respectivamente.

Explicando un poco esto, podemos entender un poco más la importancia de este «pequeño» componente que, para un usuario normal le dio varios dolores de cabeza y en entornos críticos no quiero imaginar el desastre que puede generar.

Dada una «no tan extensa» explicación de la importancia de NTP, la razón de contar mi pequeña “aventura” es porque hace poco fue lanzada la nueva versión de NTPsec 1.2.3 :

Entre las mejoras en la nueva versión se incluyen:

• Alineación modificada de los paquetes del protocolo de control Mode 6, lo que podría afectar la compatibilidad con NTP clásico. El Mode 6 se utiliza para transmitir información sobre el estado del servidor y cambiar el comportamiento en tiempo real.
• Se ha implementado el algoritmo de cifrado AES de forma predeterminada en ntpq.
• Utilización del mecanismo Seccomp para bloquear nombres de llamadas al sistema incorrectas.
• Se ha habilitado la recopilación de estadísticas con reinicio cada hora, con registros adicionales para NTS, NTS-KE y ms-sntp.
• Inclusión de la opción «update» en buildprep.
• Mejoras en la presentación de datos de retardo de paquetes en la salida JSON de ntpdig.
• Se añadio soporte para la lista ecdhcurves.
• Se corrigió la compilación en plataformas que -fstack-protector dependen de libssp, como musl.
• Se corrigió el fallo de ntpdig al utilizar 2.ntp.pool.org con un host sin soporte IPv6.

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/YZzurAt
via IFTTT

Aunque mi compañero Diego los defiende, le gustan y recomienda, por lo menos algunos de ellos y como mínimo no ataca al tipo de paquete, creo que no me equivoco si afirmo que está muy poco acompañado en su postura. Canonical hizo oficial la disponibilidad de los paquetes snap en 2016 con Ubuntu 16.04 Xenial Xerus, nos prometió el cielo y yo sólo leo comentarios negativos de la comunidad Linux. En mi caso concreto, y me consta que no soy el único, he llegado a deshacerme de ellos completamente.

Lo que sí triunfa son los flatpak, y en Flathub, el repositorio más popular, encontramos prácticamente todo. Por poner algunos ejemplos, el navegador Vivaldi, Bottles o casi la totalidad de las aplicaciones del círculo de GNOME. Gustan más, y también parece ser que presentan menos problemas. En muchas ocasiones son los desarrolladores de los diferentes programas los que los suben, a diferencia de lo que pasa en Snapcraft que mucho lo reempaqueta Canonical. Esto mismo pasa con el paquete snap de Steam, y Valve desaconseja su uso tras los muchos reportes de bugs que está recibiendo.

Valve desaconseja el uso de los paquetes snap, por lo menos el de Steam

Hace mucho tiempo, para ser honesto no recuerdo cuándo ni dónde leí cierta información, pudo ser incluso aquí en LXA pero no lo encuentro en el archivo, se hablaba del buen trabajo que estaba haciendo Canonical con el paquete snap de Steam, hasta el punto de que se echaban ciertas pullitas a otras opciones. Ahora, algunos meses o años después, Valve está recibiendo cada vez más quejas de usuarios que reportan bugs con este paquete, por lo que recomiendan usar la versión .deb que ellos mismos empaquetan o por lo menos usar el paquete flatpak.

Ha sido Timothee Besset quien lo ha publicado en Mastodon (vía GamingOnLinux):

«Valve está recibiendo un número creciente de informes de errores por problemas causados por el reempaquetado de Canonical del cliente de Steam a través de snap.

La mejor manera de instalar Steam en Debian y sistemas operativos derivados es seguir las instrucciones en http://repo.steampowered.com/steam y utilizar el .deb oficial.

No estamos involucrados en el reempaquetado snap. Tiene muchos problemas.

Si no quieres el .deb, por favor considera al menos la versión flatpak».

La versión flatpak no está verificada, pero eso no significa que un proyecto no esté involucrado. Tampoco lo está Vivaldi Browser, y quien lo sube forma parte del equipo oficial. Lo que sí es seguro es que no tienen nada que ver con el reempaquetado del snap, y que éste está presentando muchos problemas que escapan a su control.

No es un ataque, pero…

Lo comentado por Timothee Besset no es un ataque directo y gratuito a los paquetes snap. Es sencillamente contar un hecho que está ocurriendo. Si los usuarios de Steam se quejan del mal funcionamiento del programa y el programa lo están editando de alguna manera terceros desarrolladores, poco o nada pueden hacer para identificar el problema y encontrar una solución.

Lo mejor para los usuarios de Debian/Ubuntu es usar el paquete .deb, que es lo nativo y sale directamente del horno de Valve. Después, el paquete flatpak. Para el resto de distribuciones, pues dependerá. Si no tienen problemas con el paquete snap, no deja de ser una opción, pero debería tomarse en consideración después del flatpak.

Y para los que no quieran ni lo uno ni lo otro, la opción que les que da es ver si su distribución Linux lo ofrece en sus repositorios oficiales. Yo desde aquí lo único que puedo hacer es recomendar lo mismo que Valve, y el paquete snap debería ser lo último por probar.

Los usuarios de una distribución basada en Debain/Ubuntu pueden descargar la última versión de Steam en formato .deb desde la página web oficial de Steam. En este otro enlace hay información para hacerlo manualmente. Los usuarios de otras distribuciones Linux pueden encontrar el tarball aquí.

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

Ya lo dijimos el viernes pasado, que la versión estable podría llegar en cualquier momento. Pero, por lo menos yo, no me esperaba que fuera tan pronto. WineHQ ha lanzado WINE 9.0, y lo ha hecho tras sólo 5 Release Candidates. Si hubiera tenido que apostar, y tras un periodo navideño en el que se saltaron una, yo habría puesto mi dinero en la casilla de principios de febrero, pero habría perdido.

Entre las novedades hay una que yo creo que destaca, aunque quizá ya os lo hayáis imaginado e incluso puede que estéis cansados del tema. WINE 9.0 incluye soporte inicial para Wayland, aunque en estos momentos es una función que está marcada como experimental. Y es que gran parte de los usuarios que usamos WINE lo hacemos en Linux, y es en los sistemas basados en el kernel en donde hay muchos proyectos que se dirigen a Wayland seriamente.

Novedades más destacadas de WINE 9.0

• WoW64:
  • Todas las transiciones de código Windows a Unix pasan por la interfaz syscall de NT. Se trata de un hito importante que marca la finalización del el trabajo de rearquitectura de varios años para convertir los módulos al formato PE e introducir una frontera adecuada entre los mundos Windows y Unix.
  • Todos los módulos que llaman a una biblioteca Unix contienen thunks WoW64 para permitir la llamada a la biblioteca Unix de 64 bits desde 32 bits. biblioteca Unix de 64 bits desde código PE de 32 bits. Esto significa que es posible ejecutar aplicaciones Windows de 32 bits en una instalación Unix de 64 bits. Esto se denomina llamado el nuevo modo WoW64, opuesto al viejo modo WoW64 donde las aplicaciones de 32 bits se ejecutan dentro de un Unix de 32 bits.
  • El nuevo modo WoW64 aún no está habilitado por defecto. Puede activarse pasando la opción –enable-archs=i386,x86_64 a configurar. Se espera que esto funcione para la mayoría de las aplicaciones, pero todavía hay algunas limitaciones.
  • El nuevo modo WoW64 permite por fin ejecutar aplicaciones de 32 bits en versiones recientes de macOS que eliminaron el soporte para procesos Unix de 32 bits.
• Driver Wayland:
  • Existe un controlador gráfico Wayland experimental. Todavía es un trabajo en curso, pero ya implementa muchas características, como la gestión básica de ventanas, múltiples monitores, escalado de alta DPI, eventos de movimiento relativo y soporte Vulkan.
  • El controlador Wayland aún no está activado por defecto. Puede habilitarse a través de la clave de registro «KCU\Software\Wine\Drivers» ejecutando
    wine reg.exe add HKCU\\Software\Wine\Drivers /v Graphics /d x11,wayland y asegurándose de que la variable de entorno DISPLAY está desactivada.
• ARM64:
  • La finalización de la separación PE/Unix significa que es posible ejecutar binarios Windows existentes en ARM64.
  • El cargador soporta la carga de módulos ARM64X y ARM64EC.
  • Se ha implementado la interfaz de emulación x86 de 32 bits. No se proporciona ninguna biblioteca de emulación con Wine en este momento, pero se puede utilizar una biblioteca externa que exporte la interfaz, especificando su nombre en el directorio
    «HKLM\Software\Microsoft\Wow64\x86». El emulador FEX implementa esta interfaz cuando se construye como PE.
  • Existe soporte inicial para construir Wine para la arquitectura ARM64EC, utilizando una cadena de herramientas LLVM experimental. Una vez que la cadena de herramientas esté lista, se utilizará para realizar una compilación ARM64X adecuada y habilitar la emulación x86 de 64 bits.
• Gráficos:
  • El controlador PostScript se ha reimplementado para trabajar a partir de archivos spool con formato Windows y evitar cualquier llamada directa desde el lado Unix.
  • La tematización de WinRT admite una opción de tema oscuro, con la correspondiente conmutación en WineCfg.
  • El controlador Vulkan soporta hasta la versión 1.3.272 de la especificación Vulkan.
  • Varias funciones de GdiPlus se han optimizado para mejorar el rendimiento gráfico.
• Direct3D:
  • El flujo de comandos multihilo duerme en lugar de girar cuando no está procesando comandos de renderizado. Esto reduce el consumo de energía en programas que no ocupan todo el ancho de banda disponible del flujo de comandos. El consumo de energía debería ser comparable a cuando el flujo de comandos multihilo está desactivado.
    deshabilitado.
  • Los efectos de Direct3D 10 admiten muchas más instrucciones.
  • Se han realizado varias optimizaciones en el núcleo de WineD3D y en el backend de Vulkan.
  • El renderizador Vulkan valida correctamente que las características requeridas son soportadas por el dispositivo subyacente, e informa a la aplicación del nivel de característica Direct3D correspondiente.
  • Se han implementado D3DXFillTextureTX y D3DXFillCubeTextureTX.
  • El shader ARB de OpenGL admite el muestreo de sombras mediante ARB_fragment_program_shadow.
  • El compilador HLSL admite los indicadores de compilación de mayoría de matrices.
  • D3DXLoadMeshHierarchyFromX y las funciones relacionadas admiten la carga de datos de usuario a través de ID3DXLoadUserData.
• Audio y vídeo:
  • Se implementa la base de varios de los módulos de DirectMusic. Se añaden muchas pruebas para validar el comportamiento del secuenciador dmime y del sintetizador MIDI dmsynth.
  • Se implementa la carga de fuentes de sonido DLS1 y DLS2, así como el formato SF2 para compatibilidad con las fuentes de sonido MIDI estándar de Linux.
  • La reproducción MIDI está implementada en dmsynth, con la integración del sintetizador software de la librería FluidSynth, y utilizando DirectSound para la salida de audio.
  • El desplazamiento Doppler está soportado en DirectSound.
  • Se ha implementado el decodificador de vídeo Indeo IV50 para Windows.
• Otras mejoras en DirectShow, dispositivos de entradas, integración con el escritorio e Internet y redes, disponibles en la nota de lanzamiento.

WINE 9.0 es la nueva versión estable del software y se puede descargar desde el siguiente botón. A partir de ahora lanzarán alguna estable correctiva (9.0.1, 9.0.2…) y empezarán con las de desarrollo (9.1, 9.2), éstas ya para preparar el WINE 10 de 2025.

.boton {color: white; background-color: grey; padding: 20px; font-size: 2rem; text-decoration: none; border-radius: 10px; position: relative; top: 15px; border: 4px solid #555;}.boton:hover {box-shadow:1px 1px 2.5px black !important;}

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