Hace pocos día se dio a conocer mediante una publicación en el blog de Knative, que Google planea ceder el control directo sobre su proyecto Knative de código abierto a un comité directivo de cinco puestos que tendrá reglas para evitar que una sola organización tenga más de dos puestos.

El plan está diseñado para obstaculizar las críticas de que Google planea en secreto mantener el control sobre los proyectos clave de código abierto que ha desarrollado.

Para quienes desconocen de Knative, deben saber que este es un proyecto de código abierto desarrollado por primera vez por Google que proporciona componentes para implementar, ejecutar y administrar aplicaciones nativas de la nube sin servidor sobre Kubernetes, una plataforma de administración de contenedores que también fue desarrollada por Google y de código abierto en 2015.

Las aplicaciones sin servidor se escalan automáticamente hacia arriba y hacia abajo en respuesta a eventos sin la necesidad de activar recursos informáticos adicionales manualmente, lo que genera una mayor productividad del desarrollador y reduce los costos operativos. Knative se creó para brindar a las empresas una forma de aprovechar el modelo sin servidor con aplicaciones de contenedor que pueden ejecutarse en cualquier tipo de plataforma informática.

Google deja el mando de Knative

Google planea realizar algunos cambios importantes en la estructura de gobierno de Knative, según el informe. Los puestos en el comité ahora serán ocupados por individuos en lugar de empresas específicas, y las elecciones se llevarán a cabo a finales de este año para seleccionar dos nuevos miembros. Además, según el informe, Google está considerando eventualmente expandir el comité a siete miembros como una forma de incluir representantes de la comunidad de usuarios de Knative.

El plan se produce solo unos meses después de que Google enfureció a algunos miembros de la comunidad de software de código abierto cuando incumplió la promesa de entregar el control de otro proyecto, Istio a la Cloud Native Computing Foundation, un proyecto de la Fundación Linux que se fundó en 2015 para ayudar al avance de la tecnología de contenedores.

En julio, Google dijo que en lugar de transferir Istio al CNCF, crearía una organización neutral llamada Open Usage Commons para administrar sus políticas de marcas registradas, mientras que el control lo mantendría el comité directivo del proyecto.

Durante las discusiones sobre la nueva gobernanza, se hizo evidente que había una clara separación de preocupaciones entre las necesidades específicas de los proveedores en torno a la marca comercial, el alcance «central» (a falta de un término mejor) y la conformidad, y las necesidades de la comunidad en general en torno a todo lo demás. hace. Si bien podríamos haber creado una estructura híbrida para Steering, decidimos que era más sencillo tener un comité de proveedores que se enfocara solo en el alcance y el cumplimiento, con el comité de Steering enfocándose en los otros aspectos del crecimiento de la comunidad y la gobernanza del proyecto.

Esa decisión molestó a muchos de los socios de Google, sobre todo IBM Corp, que también ha contribuido en gran medida al desarrollo de Istio.

Algunos dijeron que la medida podría incluso ser una forma secreta para que Google retenga el control sobre la dirección futura de Istio.

El problema, dijeron los críticos, era que Google controlaba una mayoría de votos de los escaños en el comité directivo de Istio, algo que desconcierta a los defensores del código abierto que creen que la neutralidad de proyectos como Kubernetes es una de las principales razones de su éxito.

La KTC incluirá inicialmente a representantes de Google, Red Hat / IBM y VMware. Tendrán que averiguar cómo los nuevos componentes y características se “conectan” al ecosistema Knative en un sentido no técnico. También ayudarán a Steering a resolver preguntas sobre marcas comerciales y logotipos derivados, «extensiones» de Knative y otras preguntas sobre cómo ser parte de nuestro proyecto más amplio.

Google finalmente se movió para calmar a esos críticos en agosto, anunciando que cambiaría la estructura de gobierno de Istio para evitar que cualquier compañía tomara el control.

Fuente: https://knative.dev/

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

El Grupo de trabajo de ingeniería de Internet (IETF), que es responsable del desarrollo de protocolos y arquitectura de Internet, ha completado la formación de un RFC para el protocolo Network Time Security (NTS) y ha publicado la especificación asociada con el identificador RFC 8915.

La RFC recibió el estatus de «Propuesta de Estándar», luego de lo cual se comenzará a trabajar para darle a la RFC el estatus de Borrador de Estándar, lo que en realidad significa una completa estabilización del protocolo y teniendo en cuenta todos los comentarios realizados.

La estandarización de NTS es un paso importante para mejorar la seguridad de los servicios de sincronización horaria y proteger a los usuarios de ataques que imitan al servidor NTP al que se conecta el cliente.

La manipulación de los atacantes para establecer la hora incorrecta se puede utilizar para comprometer la seguridad de otros protocolos sensibles al tiempo, como TLS. Por ejemplo, cambiar la hora puede dar lugar a una mala interpretación de los datos de validez de los certificados TLS.

Hasta ahora, el NTP y el cifrado simétrico de los canales de comunicación no permitían garantizar que el cliente interactúe con el objetivo y no con un servidor NTP falsificado, y la autenticación de claves no se ha generalizado, ya que es demasiado complicado de configurar.

Durante los últimos meses, hemos visto a muchos usuarios de nuestro servicio horario, pero muy pocos utilizan Network Time Security. Esto deja a las computadoras vulnerables a ataques que imitan al servidor que utilizan para obtener NTP. Parte del problema fue la falta de demonios NTP disponibles que admitieran NTS. Ese problema ya está resuelto: chrony y ntpsec ambos NTS de apoyo.

NTS utiliza elementos de infraestructura de clave pública (PKI) y permite el uso de TLS y cifrado autenticado con datos asociados (AEAD) para proteger criptográficamente las comunicaciones cliente-servidor a través del protocolo de tiempo de red (NTP).

NTS incluye dos protocolos separados: NTS-KE (Establecimiento de claves NTS para manejar la autenticación inicial y negociación de claves sobre TLS) y NTS-EF (Campos de extensión NTS, responsables de cifrar y autenticar una sesión de sincronización horaria).

NTS agrega varios campos extendidos a los paquetes NTP y almacena toda la información de estado solo en el lado del cliente mediante un mecanismo de transmisión de cookies. El puerto de red 4460 está dedicado a manejar conexiones NTS.

El tiempo es la base de la seguridad de muchos de los protocolos, como TLS, en los que confiamos para proteger nuestras vidas en línea. Sin una hora exacta, no hay forma de determinar si las credenciales han caducado o no. La ausencia de un protocolo de tiempo seguro de fácil implementación ha sido un problema para la seguridad de Internet.

Las primeras implementaciones del NTS estandarizado se propusieron en las versiones recientemente publicadas de NTPsec 1.2.0 y Chrony 4.0.

Chrony proporciona una implementación independiente de cliente y servidor NTP que se utiliza para sincronizar la hora exacta en varias distribuciones de Linux, incluidas Fedora, Ubuntu, SUSE / openSUSE y RHEL/CentOS.

NTPsec se desarrolla bajo el liderazgo de Eric S. Raymond y es una bifurcación de la implementación de referencia del protocolo NTPv4 (NTP Classic 4.3.34), enfocado en rediseñar la base de código para mejorar la seguridad (limpieza de código obsoleto, métodos de prevención de intrusiones y funciones protegidas) trabajar con memoria y cadenas).

Sin NTS o autenticación de clave simétrica, no hay garantía de que su computadora esté realmente hablando NTP con la computadora que usted cree que es. La autenticación de clave simétrica es difícil y dolorosa de configurar, pero hasta hace poco era el único mecanismo seguro y estandarizado para autenticar NTP. NTS utiliza el trabajo que entra en la infraestructura de clave pública web para autenticar los servidores NTP y asegurarse de que cuando configura su computadora para hablar con time.cloudflare.com, ese es el servidor del que su computadora obtiene la hora.

Si quieres conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.

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