Este movimiento por parte de Twitter, podría perjudicar a la red social.

Se dio a conocer la noticia de que Twitter, dejará de admitir el acceso gratuito a su API  y en su lugar, ofrecerá un «nivel básico de pago».

El 9 de febrero, muchas herramientas para Twitter, incluyendo aplicaciones para analizar datos y herramientas para la administración y actualizaciones automáticas, dejarán de funcionar. La decisión de Twitter ha sido criticada porque afectará una amplia gama de aplicaciones y funciones importantes para el ecosistema en tiempo real de la plataforma.

La API de Twitter permite a terceros acceder y analizar datos públicos de la plataforma, lo que se utiliza para crear bots y aplicaciones. Actualmente, Twitter ofrece un acceso limitado gratuito a su API, así como opciones premium para desarrolladores que necesitan más acceso y funciones empresariales. Sin embargo, Twitter ha anunciado que este acceso gratuito no estará disponible a partir del 9 de febrero.

En una serie de tuits, la cuenta oficial de Twitter Dev indicó que la empresa dejaría de dar soporte a la nueva v2 de sus APIs de Twitter.

Starting February 9, we will no longer support free access to the Twitter API, both v2 and v1.1. A paid basic tier will be available instead 🧵

— Twitter Dev (@TwitterDev) February 2, 2023

https://platform.twitter.com/widgets.js

La compañía no ha revelado cuánto cobrará por el uso de sus API. Este cambio sigue a la modificación de los términos de servicio de la API de Twitter, que afectó a muchos clientes externos populares como Tweetbot y Twitterrific. Twitter prohibió los clientes de terceros y ahora es posible que desaparezcan algunas herramientas que mejoran la experiencia de los usuarios.

“Los datos de Twitter se encuentran entre los conjuntos de datos más poderosos del mundo. Estamos comprometidos a permitir un acceso oportuno y completo para que pueda continuar construyendo con nosotros. A lo largo de los años, cientos de millones de personas han enviado más de un billón de tuits y miles de millones más cada semana”, dijo la cuenta de Twitter Dev. El objetivo es obtener la mayor cantidad de ingresos posible, por cualquier medio posible. Las aplicaciones comerciales más populares en la plataforma, incluidas Hootsuite y Sprout Social, ya pagan por el acceso completo a la API y es poco probable que se vean afectadas.

Twitter no revela públicamente el precio de sus niveles profesionales de la API, aunque en febrero del año pasado se informó que las tarifas comienzan en $99 por mes y aumentan según el nivel de acceso requerido.

Este anuncio ya ha generado controversia, ya que en las dos caras de la moneda, por un lado, hay proyectos para personas que podrían no estar dispuestas a pagar una tarifa por algo que no están monetizando ellos mismos. Por lo tanto, es probable que muchos bots y herramientas que utilizan el acceso gratuito a la API de Twitter se cobren o se vean obligados a cerrarse.

Finalmente, también existe otra base de usuarios específica de la API de Twitter: estudiantes y científicos (investigadores). El nuevo anuncio de Twitter podría tener un gran impacto en la investigación en diferentes áreas, incluido el discurso de odio y la promoción del terrorismo en línea.

Las universidades a menudo usan Twitter para estudiar el comportamiento humano en diferentes regiones. Limitar el uso gratuito de la API también podría evitar que las empresas detecten la difusión de información falsa en Twitter.

Por otro lado, algunos lo verán como otro elemento de la represión de Twitter contra los bots. Elon Musk se propuso erradicar los bots de Twitter después de comprar la plataforma por la friolera de 44.000 millones de dólares a finales de octubre de 2022.

Desde entonces, Musk ha tomado medidas drásticas para eliminar los bots, algunas de las cuales están teniendo un impacto, pero el propio Musk también ha admitido que estos esfuerzos están reduciendo el compromiso general de la plataforma.

Lo que está claro, es que desde la llegada de Musk, la compañía ha logrado enfadar, molestar y perder a una gran cantidad de usuarios y socios. Musk ha estado trabajando para aumentar los ingresos e impulsar la monetización de Twitter desde la adquisición, para pagar préstamos y liquidar una montaña de deudas.

En particular, despidió a casi dos tercios del personal, bloqueó la verificación del usuario detrás de una suscripción mensual de $ 8 a Twitter Blue e incluso vendió activos de la compañía después de que Twitter cerró sus oficinas, supuestamente después de no pagar.

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

Después del lanzamiento de una nueva versión estable mayor, WineHQ no ha respirado y ya se ha puesto a preparar la siguiente. El pasado día 24 de enero nos entregaron la v8.0 de Wine Is Not an Emulator, y hoy, diez días después, han lanzado WINE 8.1. Y antes de seguir, tenemos que explicar qué es lo que tenemos entre manos. Es una versión de desarrollo de las que llegarán cada dos semanas, o dicho de otro modo, la primera actualización no estable de las que se irán lanzando para preparar el lanzamiento del WINE 9.0 que llegará a principios de 2024.

Y explicado lo anterior, ahora hemos vuelto a lo que se podría considerar normal por ser lo más habitual. Estas notas incluyen todas las novedades que se han introducido desde el lanzamiento de la anterior versión, en esta ocasión 299 cambios. Lo que tenéis a continuación es la lista con los 27 bugs arreglados que han añadido en la lista de correcciones.

En estas versiones también facilitan una lista con algunas de las novedades más dignas de mención, y de este WINE 8.1, WineHQ ha destacado que la versión de Windows se ha puesto en Windows 10 para nuevas configuraciones por defecto y que se han realizado muchas limpiezas de código en diferido que no pudieron hacer antes porque estaban en la congelación de código. La lista de lo más destacado la cierra el punto que menciona varias correcciones de errores.

Bugs corregidos en WINE 8.1

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

Los cambios realizados en Github no fueron como esperaban

Hace poco se ha informado que GitHub ha cambiado el método de generar archivos «.tar.gz» y «.tgz» generados automáticamente en las páginas de lanzamiento.

Este cambio provocó cambios en sumas de verificación y fallas masivas en los sistemas de compilación automatizados, que verifican la integridad de los archivos descargados de GitHub contra las sumas de verificación previamente almacenadas, como las que se colocan en los metadatos del paquete o en los scripts de compilación.

A partir de la versión 2.38, de Git, se incluía de forma predeterminada una implementación integrada de gzip, lo que permitía unificar la compatibilidad con este método de compresión en todos los sistemas operativos y mejorar el rendimiento de la creación de archivos. GitHub recogió el cambio después de actualizar la versión de git en su infraestructura.

La compresión predeterminada para los archivos de Git ha cambiado recientemente . Como resultado, los archivos descargados de GitHub pueden tener diferentes sumas de verificación aunque el contenido no haya cambiado por completo.<

GitHub no garantiza la estabilidad de las sumas de verificación para archivos generados automáticamente. Estos están marcados con las palabras «Código fuente (zip)» y «Código fuente (tar.gz)» en la pestaña Versiones. Si necesita confiar en una suma de verificación consistente, puede cargar archivos directamente a GitHub Releases.
Estos están garantizados para no cambiar.

El problema era que los archivos comprimidos generados por la implementación gzip incorporada de zlib son binarios diferentes de los archivos generados por la utilidad gzip, lo que da como resultado diferentes sumas de verificación para los archivos creados por diferentes versiones de git cuando se ejecuta el comando «git archive».

En consecuencia, después de actualizar git en GitHub, comenzaron a aparecer archivos ligeramente diferentes en las páginas de lanzamiento que no pasaron la verificación con las sumas de verificación anteriores.

El problema se manifestó en varios sistemas de compilación, sistemas de integración continua y conjuntos de herramientas para compilar paquetes desde el origen. Por ejemplo, se rompieron alrededor de 5800 puertos de FreeBSD, cuyas fuentes se descargaron de GitHub.

En respuesta a las primeras quejas sobre fallas, los representantes de GitHub inicialmente señalaron que nunca se garantizaron sumas de verificación constantes para los archivos.

Después de que se demostró que hacer que los sistemas de compilación se vieran afectados por el cambio requeriría una gran cantidad de trabajo para actualizar los metadatos en los diversos ecosistemas, GitHub cambió de opinión, revirtió el cambio y revirtió el antiguo método de generación de archivos.

Como era de esperar, la gente comenzó a quejarse. La respuesta inicial del empleado de GitHub (y principal colaborador de Git) brian m. carlson fue menos que completamente comprensivo:

Estoy diciendo que la política nunca ha sido correcta y nunca hemos garantizado sumas de verificación estables para los archivos, al igual que Git nunca lo ha garantizado. Pido disculpas por las cosas que no funcionan aquí y que no ha habido una comunicación más clara sobre esto en el pasado, pero nuestra política no ha cambiado en más de 4 años.

Los desarrolladores de Git aún no han tomado una decisión y solo están discutiendo posibles acciones. Las opciones consideradas incluyen recurrir al uso de la utilidad gzip predeterminada; agregando el indicador «–stable» para preservar la compatibilidad con archivos antiguos; vincular la implementación incorporada a un formato de archivo separado; usando la utilidad gzip para confirmaciones antiguas y la implementación integrada para confirmaciones a partir de una fecha determinada; garantizando la estabilidad del formato solo para archivos sin comprimir.

La complejidad de la decisión se explica por el hecho de que la reversión a la llamada de la utilidad externa no resuelve completamente el problema de la invariancia de las sumas de verificación, ya que un cambio en el programa gzip externo también puede provocar un cambio en el archivo.

Actualmente, hay un conjunto de parches para revisión que vuelve al comportamiento predeterminado (invocando una utilidad gzip externa) y usa la implementación integrada cuando la utilidad gzip no está presente en el sistema. Los parches también agregan una nota a la documentación de que no se garantiza que la salida de «git archive» sea estable y que el formato está sujeto a cambios en el futuro.

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

OpenSSH es un conjunto de aplicaciones que permiten realizar comunicaciones cifradas a través de una red, usando el protocolo SSH

Se dio a conocer el lanzamiento de la nueva versión de la implementación abierta de cliente y servidor para trabajar con los protocolos SSH 2.0 y SFTP, «OpenSSH 9.2».

La nueva versión corrige una vulnerabilidad, que conduce a la doble liberación de un área de memoria en la etapa anterior a la autenticación. La vulnerabilidad afecta únicamente al lanzamiento de OpenSSH 9.1, en versiones anteriores no aparece el problema.

Para crear condiciones para la manifestación de una vulnerabilidad, basta cambiar el banner del cliente SSH a «SSH-2.0-FuTTYSH_9.1p1» para lograr la configuración de los flags «SSH_BUG_CURVE25519PAD» y «SSH_OLD_DHGEX», según la versión del cliente SSH.

Después de configurar estos indicadores, la memoria para el búfer «options.kex_algorithms» se libera dos veces: al ejecutar la función do_ssh2_kex(), que llama a compat_kex_proposal(), y al ejecutar la función do_authentication2(), que llama a input_userauth_request(), mm_getpwnamallow( ), copy_set_server_options() a lo largo de la cadena, ensemble_algorithms() y kex_assemble_names().

Se considera improbable crear un exploit funcional para la vulnerabilidad, ya que el proceso de explotación es demasiado complicado: las bibliotecas de asignación de memoria modernas brindan protección contra la liberación doble de memoria, y el proceso de autenticación previa, en el que hay un error, se ejecuta con privilegios reducidos en un sandbox.

Además de la vulnerabilidad mencionada, la nueva versión también corrige dos problemas de seguridad más:

• Ocurrió un error al procesar la configuración » PermitRemoteOpen «, lo que provocó que se ignorara el primer argumento si es diferente de los valores «cualquiera» y «ninguno». El problema aparece en versiones posteriores a OpenSSH 8.7 y hace que se omita la verificación cuando solo se especifica un permiso.
• Un atacante que controla el servidor DNS utilizado para resolver nombres puede lograr la sustitución de caracteres especiales (por ejemplo, «*») en archivos de hosts conocidos si las opciones CanonicalizeHostname y CanonicalizePermittedCNAMEs están habilitadas en la configuración y el sistema de resolución no verifica la corrección de respuestas del servidor DNS. Se considera poco probable que se lleve a cabo el ataque, ya que los nombres devueltos deben coincidir con las condiciones especificadas a través de CanonicalizePermittedCNAME.

Novedades de OpenSSH 9.2

De los cambios que se realizaron en OpenSSH 9.2 se destaca que se agregó una configuración EnableEscapeCommandline a ssh_config para controlar si el procesamiento del lado del cliente de la secuencia de escape «~C» siempre que la línea de comando esté habilitada. De forma predeterminada, el procesamiento «~C» ahora está deshabilitado para permitir un sandboxing más estricto, lo que podría romper los sistemas que usan «~C» para el reenvío de puertos en tiempo de ejecución

Se ha agregado la directiva ChannelTimeout a sshd_config para que sshd establezca el tiempo de espera de inactividad del canal (los canales en los que no se haya detectado tráfico durante el tiempo especificado en la directiva se cerrarán automáticamente). El tráfico de sesión, X11, agente y redireccionamiento puede tener diferentes tiempos de espera.

De los demas cambios:

• Se agregó una directiva UnusedConnectionTimeout a sshd_config para sshd, que le permite establecer un tiempo de espera para finalizar las conexiones de clientes que han estado sin canales activos durante un tiempo determinado.
• Se agregó la opción «-V» a sshd para mostrar una versión similar a la opción de cliente ssh.
• Se agregó la cadena «Host» a la salida de «ssh -G» para reflejar el valor del argumento del nombre de host.
• Se agregó la opción «-X» a scp y sftp para controlar los parámetros de SFTP, como el tamaño del búfer de copia y la cantidad de solicitudes pendientes.
• ssh-keyscan permite escanear rangos completos de direcciones CIDR, por ejemplo, «ssh-keyscan 192.168.0.0/24».

Finalmente si estás interesado en conocer más al respecto sobre esta nueva versión, puedes consultar los detalles dirigiéndote al siguiente enlace.

¿Como instalar OpenSSH 9.2 en Linux?

Para quienes estén interesados en poder instalar esta nueva versión de OpenSSH en sus sistemas, de momento podrán hacerlo descargando el código fuente de este y realizando la compilación en sus equipos.

Esto es debido a que la nueva versión aún no se ha incluido dentro de los repositorios de las principales distribuciones de Linux. Para obtener el código fuente, puedes hacer desde el siguiente enlace.

Hecha la descarga, ahora vamos a descomprimir el paquete con el siguiente comando:

tar -xvf openssh-9.2.tar.gz

Entramos al directorio creado:

cd openssh-9.2

Y podremos realizar la compilación con los siguientes comandos:

./configure --prefix=/opt --sysconfdir=/etc/ssh
make
make install

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