☰

¿Por qué las versiones de los paquetes quedan obsoletas y dejan de estar disponibles?

tag-icon • tag-icon 16.04 package-management
¿Por qué las versiones de los paquetes quedan obsoletas y dejan de estar disponibles?

Estamos creando imágenes de Docker basadas en Ubuntu xenial(lo sé EOL 21/04) y estábamos usando curl=7.47.0-1ubuntu2.14y openssh-server=1:7.2p2-4ubuntu2.8ahora ambos no están disponibles.

El paquete curl ahora es curl=7.47.0-1ubuntu2.15el ssh-server openssh-server=1:7.2p2-4ubuntu2.10. Me pregunto por qué es así y cómo los dos paquetes originales ya no están disponibles.

¿Hay alguna manera de poder recuperar los paquetes antiguos si es necesario? ¿Si es así, donde?

Respuesta1

Usemos la rmadisonconsulta de la base de datos del paquete yhttp://changelogs.ubuntu.compara descubrir por qué esos paquetes fueron reemplazados.

Veamos primero el rizo:

$ rmadison curl | grep xenial
 curl | 7.47.0-1ubuntu2    | xenial           | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
 curl | 7.47.0-1ubuntu2.15 | xenial-security  | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
 curl | 7.47.0-1ubuntu2.15 | xenial-updates   | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x

Ajá: ¿Ves cómo tanto la seguridad como las actualizaciones están impulsando la versión 2.15? Eso significa que probablemente fue un parche de seguridad. Para detalles específicos, echemos un vistazo a https://changelogs.ubuntu.com/changelogs/binary/c/curl/7.47.0-1ubuntu2.15/changelog

curl (7.47.0-1ubuntu2.15) xenial-seguridad; urgencia=media

  • ACTUALIZACIÓN DE SEGURIDAD: curl sobrescribe el archivo local con -J
    • debian/patches/CVE-2020-8177.patch: -i no está bien si -J se usa en src/tool_cb_hdr.c, src/tool_getparam.c.
    • CVE-2020-8177

--Marc Deslauriers[correo electrónico protegido] Miércoles, 17 de junio de 2020 09:21:55 -0400

Ahora veamos el servidor openssh:

$ rmadison openssh-server | grep xenial
 openssh-server | 1:7.2p2-4           | xenial           | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
 openssh-server | 1:7.2p2-4ubuntu2.8  | xenial-security  | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
 openssh-server | 1:7.2p2-4ubuntu2.10 | xenial-updates   | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x

¿Ves cómo -updates tiene una versión superior? Eso significa que es probable que el nuevo paquete sea una corrección de errores en lugar de un parche de seguridad. veamos quehttps://changelogs.ubuntu.com/changelogs/binary/o/openssh-server/1:7.2p2-4ubuntu2.10/changelogtiene que decir:

openssh (1:7.2p2-4ubuntu2.10) xenial; urgencia=media

  • Solucione el punto muerto cuando AuthorizedKeysCommand produce una salida grande. (LP:#1877454)
    • d/p/authkeyscommand-deadlock-01.patch: asegúrese de llamar a fclose(2) y asignar NULL al controlador de archivos utilizado para leer las directivas "Comando{claves,principal}autorizado".
    • d/p/authkeyscommand-deadlock-02.patch: consume toda la salida generada por el comando señalado por "Comando {claves, principal} autorizado" para evitar enviar un SIGPIPE al proceso.

-- Sergio Durigán Junior[correo electrónico protegido] Miércoles 13 de mayo de 2020 10:12:28 -0400

Respuesta2

P: ¿Existe alguna manera de poder recuperar los paquetes antiguos si es necesario? ¿Si es así, donde?
R: Aquí hay una fuente útil.pkgs.orgsin embargo, debe utilizarlo bajo su propio riesgo.

información relacionada