La versión 115 de Thunderbird se lanzará en julio, será una actualización completa con cambios en la interfaz y el código.

En artículos anteriores compartimos la noticia sobre el plan de desarrollo que han propuesto los desarrolladores de Thunderbird, el plan tiene como objetivo en un tiempo de 3 años, mejorar diferentes puntos del popular cliente de correo electrónico.

Uno de los puntos de interés en el plan de desarrollo es el desarrollo de una interfaz de usuario de Thunderbird desde cero y los primeros resultados llegarán a Thunderbird 115 «Supernova» este julio, pero, ya se han dado a conocer algunos de los detalles de la nueva interfaz de usuario.

Explicamos por qué es necesario comenzar a eliminar algunas deudas técnicas y de interfaz, y modernizar las cosas para sostener el proyecto en las próximas décadas. Esa publicación puede haber causado que te preocupes de que la interfaz de Thunderbird 115 sea radicalmente diferente y se envíe con menos opciones de personalización. Tal vez tenga miedo de volver a aprender a usar la aplicación.

Y es que mediante una publicación de blog, los desarrolladores de Thunderbird presentaron los resultados del rediseño de la barra lateral en la nueva interfaz del cliente de correo electrónico Thunderbird, que está previsto que se ofrezca en julio con la versión 115.

En la publicación de blog nos muestran algunos de los cambios que han preparado para el desarrollo de la nueva interfaz del cliente de correo electrónico.

Uno de los cambios que se menciona es que se agregó un nuevo modo de diseño unificado para el panel con carpetas de correo, que es más comprensible para los principiantes.

¿Ves lo espacioso y transpirable que es? ¿Ves todos los espacios en blanco que ayudan a prevenir la sobrecarga cognitiva? Esto les resultará familiar a los usuarios que solo han usado webmail en el pasado.

Otro de los cambios que se tiene previsto, es que los usuarios antiguos podrán desactivar este modo y volver a la vista familiar. En lugar de una barra de herramientas, se ha propuesto un nuevo encabezado de barra lateral, que combina botones para recibir mensajes, crear un mensaje y llamar a un menú para personalizar el contenido del panel y volver al modo clásico.

Algunos usuarios confían en la barra de herramientas, que se muestra justo debajo, para sus botones de acción. Esa área cerca de la parte superior de Thunderbird siempre ha sido la ubicación predeterminada para las acciones principales en su pestaña actual.La barra de herramientas en Thunderbird 102
Pero otros prefieren eliminar por completo todos los botones de la barra de herramientas y confiar exclusivamente en la barra de menú para acceder a las opciones y funciones. Un conjunto diferente de usuarios podría ocultar por completo tanto la barra de menú como la barra de herramientas e interactuar exclusivamente con accesos directos.

Ademas de ello, podremos notar que en el nuevo diseño propuesto parecieron secciones separadas con carpetas y etiquetas locales en la barra lateral, que se pueden ocultar si se desea.

Para los usuarios que no consideran que la interfaz actual de Thunderbird sea cómoda, estamos seguros de que estas nuevas características los harán sentir como en casa, con los beneficios adicionales que brinda Thunderbird en comparación con el correo web tradicional: privacidad, personalización, sin anuncios y absolutamente sin ventas. de tus datos

Finalmente, cabe mencionar que otro de los puntos a abordar en el plan de desarrollo son:

• Aumentar la confiabilidad y la compacidad del código base, reescribir el código obsoleto y deshacerse de los problemas acumulados (deshacerse de la deuda técnica ).
• Transición a la formación mensual de nuevos lanzamientos.

Por último y no menos importante se espera que la nueva interfaz sea comprensible para los recién llegados, sin dejar de ser familiar y conveniente para usuarios antiguos.

Si estás interesado en poder conocer más al respecto, te invito a que consultes la publicación original en el siguiente enlace.

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

Go es un lenguaje de programación concurrente y compilado con tipado estático inspirado en la sintaxis de C, pero con seguridad de memoria y recolección de basura.

Russ Cox, un ingeniero de software de Google que lidera el desarrollo del lenguaje de programación de código abierto Go, presentó un posible plan para implementar la telemetría en la cadena de herramientas de Go. Sin embargo, muchos miembros de la comunidad de Go se oponen porque el plan llama a la telemetría de manera predeterminada.

Estos desarrolladores alarmados preferirían un régimen de participación en lugar de un régimen de exclusión, una posición que el equipo de Go rechaza porque garantizaría una baja adopción y reduciría la cantidad de datos de telemetría recibidos hasta el punto en que sería de poco valor.

Para quienes desconocen de Go, deben saber que este es un lenguaje de programación desarrollado en Google. Aunque es similar al lenguaje C, trae una serie de adiciones importantes y modernas. Russ Cox es el ingeniero de Google que actualmente lidera el desarrollo de Go, y ha presentado una propuesta controvertida, que implicaría habilitar la telemetría en Go de forma predeterminada.

La telemetría cubrirá las utilidades de línea de comandos desarrolladas por el equipo de desarrollo del lenguaje Go, como la utilidad «go», el compilador, las aplicaciones gopls y govulncheck. La recopilación de información se limitará solo a la acumulación de información sobre las características de los servicios públicos, es decir la telemetría no se agregará a las aplicaciones creadas.

La telemetría, como la describe Cox, implica que el software envíe datos desde el software Go a un servidor para proporcionar información sobre las funciones que se utilizan y cómo se está desempeñando el software. Argumenta que es beneficioso para los proyectos de código abierto tener esta información para guiar el desarrollo.

Creo que los proyectos de software de código abierto deben explorar nuevos diseños de telemetría que ayuden a los desarrolladores a obtener la información que necesitan para trabajar de manera eficaz y eficiente, sin recopilar rastros invasivos de la actividad detallada del usuario.

He escrito una breve serie de publicaciones de blog sobre un diseño de este tipo, al que llamo telemetría transparente, porque recopila la menor cantidad posible (kilobytes por año de cada instalación) y luego publica cada elemento que recopila, para inspección pública y análisis.

Me gustaría explorar el uso de la telemetría transparente, o un sistema similar, en la cadena de herramientas de Go, que espero ayude a los desarrolladores y usuarios de proyectos de Go. Para ser claros, solo sugiero que se agregue instrumentación a las herramientas de línea de comandos de Go escritas y distribuidas por el equipo de Go, como el comando go, el compilador Go, gopls y govulncheck. No estoy sugiriendo que el compilador Go agregue instrumentación a todos los programas Go del mundo: eso es claramente inapropiado.
La telemetría transparente tiene las siguientes propiedades clave*:

Aunque la idea detrás de la propuesta puede no ser mala, la idea planeada actualmente puede asustar a los desarrolladores actuales o potenciales del lenguaje de programación Go en cualquier proyecto futuro. Debe recordarse que la mayoría de los desarrolladores y usuarios de código abierto se oponen notoriamente a la mayoría de las formas de telemetría.

El motivo para recopilar telemetría, es el deseo de obtener la información faltante sobre las necesidades y características del trabajo de los desarrolladores que no se puede detectar mediante mensajes de error y encuestas como método de retroalimentación.

Russ tiene como objetivo introducir un concepto de «telemetría transparente» para ayudar a los proyectos de código abierto a comprender mejor el software, teniendo en cuenta la privacidad. En las publicaciones de su blog (una serie de 3 artículos), menciona que las encuestas y los informes de errores son insuficientes. Por lo tanto, es necesario introducir la forma más fácil de recopilar datos sobre el uso de una aplicación (es decir, la telemetría) manteniendo las cosas abiertas para todos.

Esto significa que todo el proceso de recopilación de datos, cómo se procesan y qué resulta de ellos, está abierto a todos.

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

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco se dio a conocer la publicación de diversas versiones correctivas del sistema de control de código fuente distribuido Git que abarcan desde la versión 2.38.4 a la versión 2.30.8, en los que se encuentran dos correcciones que eliminan las vulnerabilidades detectadas que afecta las optimizaciones de clones locales y el comando «git apply».

Como tal, se menciona que estas versiones de mantenimiento son para abordar dos problemas de seguridad identificados bajoCVE-2023-22490 y CVE-2023-23946. Ambas vulnerabilidades afectan gamas de versiones existentes y se recomienda encarecidamente a los usuarios que realicen la actualización correspondiente.

Un atacante puede explotar de forma remota una vulnerabilidad para detectar información. Además, un atacante puede
explotar una vulnerabilidad localmente para manipular archivos.

Se requieren privilegios normales para explotar las vulnerabilidades. Ambas vulnerabilidades requieren la interacción del usuario.

La primer vulnerabilidad identificada es CVE-2023-22490, la cual permite que un atacante que controla el contenido de un repositorio clonado obtenga acceso a datos confidenciales en el sistema de un usuario. Dos defectos contribuyen a la aparición de la vulnerabilidad:

• La primera falla permite, cuando se trabaja con un repositorio especialmente diseñado, lograr el uso de optimizaciones de clonación local incluso cuando se usa un transporte que interactúa con sistemas externos.
• La segunda falla permite colocar un enlace simbólico en lugar del directorio $GIT_DIR/objects, similar a la vulnerabilidad CVE-2022-39253, en la que se bloqueó la ubicación de enlaces simbólicos en el directorio $GIT_DIR/objects, pero el hecho que el directorio $GIT_DIR/objects en sí mismo no se verificó puede ser un enlace simbólico.

En el modo de clonación local, git mueve $GIT_DIR/objects al directorio de destino eliminando las referencias de los enlaces simbólicos, lo que hace que los archivos a los que se hace referencia se copien directamente en el directorio de destino. Cambiar al uso de optimizaciones de clones locales para el transporte no local permite explotar una vulnerabilidad cuando se trabaja con repositorios externos (por ejemplo, la inclusión recursiva de submódulos con el comando «git clone –recurse-submodules» puede conducir a la clonación de un repositorio malicioso empaquetado como un submódulo en otro repositorio).

Usando un repositorio especialmente diseñado, se puede engañar a Git para que use su optimización de clones locales incluso cuando se utiliza un transporte no local.
Aunque Git cancelará los clones locales cuya fuente $GIT_DIR/objects directorio contiene enlaces simbólicos (cf, CVE-2022-39253), los objetos del directorio en sí puede seguir siendo un enlace simbólico.

Estos dos pueden combinarse para incluir archivos arbitrarios basados ​​en rutas en el sistema de archivos de la víctima dentro del repositorio malicioso y la copia de trabajo, lo que permite la exfiltración de datos de manera similar a
CVE-2022-39253.

La segunda vulnerabilidad detectada es CVE-2023-23946 y esta permite sobrescribir el contenido de los archivos fuera del directorio de trabajo al pasar una entrada con formato especial al comando «git apply».

Por ejemplo, se puede realizar un ataque cuando los parches preparados por un atacante se procesan en «git apply». Para evitar que los parches creen archivos fuera de la copia de trabajo, «git apply» bloquea el procesamiento de parches que intentan escribir un archivo usando enlaces simbólicos. Pero esta protección resultó ser eludida al crear un enlace simbólico en primer lugar.

Fedora 36 y 37 tienen actualizaciones de seguridad en estado ‘testing’ que actualizan ‘git’ a la versión 2.39.2.

Las vulnerabilidades también se abordan con GitLab 15.8.2, 15.7.7 y 15.6.8 en Community Edition (CE) y Enterprise Edition (EE).

GitLab clasifica las vulnerabilidades como críticas porque CVE-2023-23946 permite la ejecución de código de programa arbitrario en el entorno Gitaly (servicio Git RPC) .
Al mismo tiempo, Python incorporado se actualiza a la versión 3.9.16 para corregir más vulnerabilidades.

Finalmente para los interesados en conocer más al respecto, pueden seguir el lanzamiento de actualizaciones de paquetes en distribuciones en las páginas de Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch y FreeBSD.

Si no es posible instalar una actualización, se recomienda como solución evitar ejecutar «git clone» con la opción «–recurse-submodules» en repositorios que no son de confianza, y no usar «git apply» y «git am «comandos con código no verificado.

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