GitHub dio a conocer recientemente algunos cambios en el ecosistema de NPM en relación a los problemas de seguridad que se han estado suscitando y uno de los más recientes fue que unos atacantes lograron hacerse con el control del paquete coa NPM y lanzaron las actualizaciones 2.0.3, 2.0.4, 2.1.1, 2.1.3 y 3.1.3, que incluían cambios maliciosos.

En relación a ello y con la creciente incidencia de la incautación de repositorios de grandes proyectos y la promoción de código malicioso a través del compromiso de las cuentas de los desarrolladores, GitHub está introduciendo una verificación extendida de cuentas.

Por separado, para los mantenedores y administradores de los 500 paquetes NPM más populares, la autenticación obligatoria de dos factores se introducirá a principios del próximo año.

Desde el 7 de diciembre de 2021 hasta el 4 de enero de 2022, todos los mantenedores que tienen derecho a publicar paquetes NPM, pero que no usan la autenticación de dos factores, serán transferidos para usar la verificación de cuenta extendida. La verificación extendida implica la necesidad de ingresar un código único que se envía por correo electrónico al intentar ingresar al sitio npmjs.com o realizar una operación autenticada en la utilidad npm.

La verificación extendida no reemplaza, sino que solo complementa la autenticación de dos factores opcional disponible anteriormente, que requiere la verificación de contraseñas de un solo uso (TOTP). La verificación de correo electrónico ampliada no se aplica cuando la autenticación de dos factores está habilitada. A partir del 1 de febrero de 2022, comenzará el proceso de transferencia a la autenticación obligatoria de dos factores de los 100 paquetes NPM más populares con la mayor cantidad de dependencias.

Hoy presentamos la verificación de inicio de sesión mejorada en el registro de npm, y comenzaremos una implementación escalonada para los mantenedores a partir del 7 de diciembre y concluyendo el 4 de enero. Los mantenedores del registro de npm que tienen acceso para publicar paquetes y no tienen autenticación de dos factores (2FA ) habilitado recibirá un correo electrónico con una contraseña de un solo uso (OTP) cuando se autentique a través del sitio web npmjs.com o la CLI de npm.

Esta OTP enviada por correo electrónico deberá proporcionarse además de la contraseña del usuario antes de autenticarse. Esta capa adicional de autenticación ayuda a prevenir ataques comunes de apropiación de cuentas, como el relleno de credenciales, que utilizan la contraseña comprometida y reutilizada de un usuario. Vale la pena señalar que la verificación de inicio de sesión mejorada está destinada a ser una protección básica adicional para todos los editores. No es un reemplazo para 2FA,NIST 800-63B . Alentamos a los mantenedores a optar por la autenticación 2FA. Al hacerlo, no necesitará realizar una verificación de inicio de sesión mejorada.

Después de completar la migración de los primeros cien, el cambio se propagará a los 500 paquetes NPM más populares en términos de número de dependencias.

Además de los esquemas de autenticación de dos factores disponibles actualmente basados ​​en aplicaciones para generar contraseñas de un solo uso (Authy, Google Authenticator, FreeOTP, etc.), en abril de 2022, planean agregar la capacidad de usar claves de hardware y escáneres biométricos para lo cual existe soporte para el protocolo WebAuthn, y también la capacidad de registrar y administrar varios factores de autenticación adicionales.

Recordemos que según un estudio realizado en 2020, solo el 9.27% ​​de los administradores de paquetes usan autenticación de dos factores para proteger el acceso, y en el 13.37% de los casos, al registrar nuevas cuentas, los desarrolladores intentaron reutilizar contraseñas comprometidas que aparecen en contraseñas conocidas.

Durante el análisis de la solidez de las contraseñas utilizadas, se logró acceder al 12% de las cuentas en NPM (13% de los paquetes) debido al uso de contraseñas predecibles y triviales como «123456». Entre las problemáticas se encontraban 4 cuentas de usuario de los 20 paquetes más populares, 13 cuentas cuyos paquetes se descargaron más de 50 millones de veces al mes, 40 – más de 10 millones de descargas al mes y 282 con más de 1 millón de descargas al mes. Teniendo en cuenta la carga de módulos a lo largo de la cadena de dependencias, comprometer cuentas que no son de confianza podría afectar hasta el 52% de todos los módulos en NPM en total.

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

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

La compañía MariaDB, que supervisa el desarrollo del servidor de base de datos MariaDB junto con la organización sin fines de lucro del mismo nombre, dio a conocer hace poco mediante un anunció el cambio significativo en el cronograma para la formación de las compilaciones de MariaDB Community Server y el esquema de su soporte.

Hasta ahora, MariaDB ha estado entregando una versión importante una vez al año y la cual a su vez cuenta con el soporte de aproximadamente 5 años. Ahora, con el cambio anunciado y según el nuevo esquema, las versiones importantes que contienen cambios funcionales se publicarán trimestralmente y recibirán soporte solo durante un año.

El anuncio oficial hace referencia al «deseo de acelerar la entrega de innovaciones a la comunidad», que, de hecho, no es más que marketing, ya que el equipo de MariaDB ha practicado previamente traer nuevas funcionalidades en lanzamientos provisionales, lo que está seriamente en desacuerdo con declaraciones de adherencia a las reglas de versionado semántico y también más de una vez se convirtió en la causa de cambios regresivos, que incluso llevaron a un retiro completo de versiones.

Hoy, anunciamos un nuevo modelo de lanzamiento para MariaDB Community Server que aumenta el ritmo de las nuevas funciones que podemos ofrecer a los millones de usuarios de MariaDB en todo el mundo. Estamos emocionados de comenzar a implementar este nuevo modelo de inmediato, comenzando con MariaDB Community Server 10.7 , que alcanzó el estado RC hace un mes e incluye varias características nuevas importantes. Para la próxima semana, los miembros de la comunidad también tendrán un adelanto de las características de MariaDB Community Server 10.8, y se espera un lanzamiento de RC en el nuevo año. Nuestra esperanza es que el ritmo más rápido de entrega de funciones permita a la comunidad aprovechar las últimas tendencias de bases de datos de vanguardia de inmediato sin tener que esperar años entre una nueva serie de lanzamientos.

Aparentemente, con este nuevo esquema de lanzamientos, la organización pretende aprovechar de ello como un medio para promover la construcción del servidor empresarial, lanzado por MariaDB Corporation exclusivamente para sus suscriptores.

Ademas de que al cambiar el ciclo de desarrollo y reducir el tiempo de mantenimiento de la versión comunitaria hará que sea menos atractivo para su uso en entornos de producción, lo que se percibe como un intento de atraer nuevos suscriptores a la edición de pago.

Aún no está claro cómo afectará el nuevo programa de desarrollo a las distribuciones de Linux, pero como tal el comunicado de prensa dice, sin especificar detalles, que existe un «trabajo conjunto con las distribuciones» para brindar soporte por un período más largo y preparar una versión especial que se adapte mejor al modelo de mantenimiento de cada distribución.

Teniendo todo esto en cuenta, que incluso ahora los envíos del servidor MariaDB por distribuciones líderes como RHEL, están notablemente rezagados con respecto a las versiones actuales, se puede esperar que el cambio en el modelo de desarrollo solo agravará la situación.

Con el nuevo modelo, seguimos un estricto «modelo de desarrollo basado en trenes» sin excepciones. Los conjuntos de funciones para cada serie de lanzamientos son más pequeños, lo que permite que el control de calidad sea exhaustivo y creemos que esto también aumentará la estabilidad de cada serie de lanzamientos. Para cada serie de lanzamientos, tenemos una fecha límite en la cual la función debe ser aprobada por QA para poder ser incluida en el lanzamiento. Si eso no sucede, la función se moverá a la próxima serie de lanzamientos que ocurre tres meses después. La función tendrá tres meses más para alcanzar el nivel de estabilidad requerido. Con esto, el nuevo modelo de lanzamiento nos permite obtener funciones a un ritmo mucho más rápido sin tener que comprometer la calidad. ¡Creemos que esto es beneficioso para todos!

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

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