Re: Parches de seguridad Jessie 8.11
El jue, 19 de may. de 2022 12:43, Héctor Ariel Rotela escribió: Camaleón, Muchas gracias por la pronta respuesta. Yo saque un listado de todos los paquetes te los adjunto, para que los mires y me des una idea, de como puedo saber si cada uno de esos paquetes están con la última versión disponible. Todo sin tener la posibilidad de conectarme a internet y que no pueda armar el repositorio local. Lo que quiero tener es un comparativo como por ejemplo: APT el paquete que se actualizo con el 8.11 es : 1.0.9.8.1 Si verificas en lo que te envié APT tiene la 1.0.9.8.6 (o sea que esta actualizado después de la 8.11 pero no se si es la última ) No se si se entendio lo que necesito. Aguardo tus comentarios Saludos Puedes sacar las versiones de los paquetes en texto mediante la página https://qa.debian.org/madison.php?package=$PAQUETE&text=on. Por ejemplo, para APT desde la página web https://qa.debian.org/madison.php?package=apt se puede ver que la versión en jessie-security es 1.0.9.8.6.
Re: Parches de seguridad Jessie 8.11
Disculpen soy novato y quiero poder entender. Camaleón, si puedes enviarme la lista te lo voy a agradecer. Es de 32 bits Saludos El vie, 20 may 2022 a las 3:44, Camaleón () escribió: > El 2022-05-19 a las 20:33 -0300, Héctor Ariel Rotela escribió: > > > Estimados > > > > Pudieron ver mi caso? > > > > Esta en el mail anterior. > > Pues no lo vi porque no me llegó el mensaje de abajo. > Y tampoco me aperece tu correo en la carpeta de /spam de Gmail :-? > ¿Lo enviaste a mi cuenta? > > > El jue, 19 de may. de 2022 12:43, Héctor Ariel Rotela < > ariel3...@gmail.com> > > escribió: > > > > > Camaleón, > > > > > > Muchas gracias por la pronta respuesta. Yo saque un listado de todos > los > > > paquetes te los adjunto, para que los mires y me des una idea, de como > > > puedo saber si cada uno de esos paquetes están con la última versión > > > disponible. > > > > > > Todo sin tener la posibilidad de conectarme a internet y que no pueda > > > armar el repositorio local. > > > > > > Lo que quiero tener es un comparativo como por ejemplo: > > > > > > APT el paquete que se actualizo con el 8.11 es : 1.0.9.8.1 > > > > > > Si verificas en lo que te envié > > > > > > APT tiene la 1.0.9.8.6 (o sea que esta actualizado después de la 8.11 > pero > > > no se si es la última ) > > > > > > No se si se entendio lo que necesito. > > (...) > > Hombre, a ver... sí te he entendido, pero ¿no sería mejor que revisaras > tú mismo la diferencia? >:-) > > Dime si tu instalación es de 32 o 64 bits y te mando la lista de los > paquetes (main/contrib/non-free) con su última versión para Jessie (el > archivo ocupa unos 9 MiB). > > http://ftp.de.debian.org/debian/dists/jessie/ > > Saludos, > > -- > Camaleón > >
Re: [OT] OAuth y 2FA (Era: Servidor imap.gmail.com y mutt falla.)
El 19 de mayo de 2022 20:38:26 CEST, "Camaleón" escribió: >El 2022-05-18 a las 09:20 +0200, alfon escribió: > >> > 2. Configurar OAuth2 en Mutt y Fetchmail, si lo permiten, o buscar >> > alguna aplicación alternativa que sí tenga soporte. >> > >> > Seguramente, y para curarme en salud, haga las dos cosas (1 y 2) :-) >> > >> > > Las opciones son usar OAuth (no tengo claro que mutt lo soporte) o una >> > > contraseña de aplicación (pero Google no te las ofrece a menos que >> > > tengas activado el 2FA) >> > >> > Para Mutt he visto esto (no lo he probado): >> > >> > mutt integration with Gmail using OAuth >> > https://luxing.im/mutt-integration-with-gmail-using-oauth/ >> >> Yo tengo configurado mutt con Oauth2 y funciona perfectamente. Existe >> un script proporcionado por Google que automatiza en parte el proceso. >> >> Si tenéis problemas concretos configurándolo lo podemos resolver en >> este u otro hilo de la lista. > >Me parece especialmente interesante este tema, y creo que nos puede ser >de utilidad a todos, por un motivo u otro. > >He estado leyendo sobre OAuth en la página de la Wikipedia para empezar >a entender de qué va :-) > >Si no lo he entendido mal, se trata de un sistema/mecanismo/protocolo >por el que un servicio/servidor permite a un cliente generar un token >para permitir el acceso de terceros (o a él mismo) a sus datos/ >servicidos/credenciales. > >Es decir, en lugar de decirle a Gmail, «soy fulanito y este es mi >usuario y contraseña», habría que primero generar un token para >permitir el acceso a fulanito, y dado que ese token no contiene los >datos en sí de las credenciales, resulta más seguro contra ataques. > >Hum... sería algo así como decirle al cortafuegos que en vez de >permitir todo y después ir cerrando puertos, que primero cierre todo y >después ir permitiendo cosas concretas. > >Entiendo las ventajas que supone para la parte servidora usar ese >sistema, pero no para el cliente, y menos aún cuando se trata de correo >electrónico. El correo convencional (no el webmail) no es una API, no >es un servicio, y hacia eso lo quieren arrastrar (desnaturalizar la >esencia del coreo electrónico) pero preferiría que el servidor de correo >me pidiera en certificado digital para autentificarme que usar ese >sistema farragoso de OAuth; auguro problemas de todo tipo y máxima >incomodidad para los clientes. > >Ahora bien, lo que ya me pierde es la mezcla de OAuth con la >doble, triple o multi autentificación (2FA). Estos sistemas de doble >seguridad los entendería razonables para validar ciertas operaciones >críticas o autentificaciones ante servicios delicados, pero no para >iniciar sesión en un buzón de correo convencional (POP/IMAP, no >webmail), espero que no sean tan vacaburros de forzar también su uso o >derivarnos al webmail :-/ > >Saludos, > Pues imagina la que se va a montar con los sistemas de los vehículos que usan, por ejemplo, Android Auto, para conectar el teléfono con el coche y poder usar el navegador, las llamadas,... Miedo me está dando... Sistemas inservibles por los que se paga una pasta cuando compras el coche... Saludos
Re: Parches de seguridad Jessie 8.11
El 2022-05-20 a las 09:26 -0300, Héctor Ariel Rotela escribió: > El vie, 20 may 2022 a las 3:44, Camaleón () escribió: > > > El 2022-05-19 a las 20:33 -0300, Héctor Ariel Rotela escribió: > > > > > Estimados > > > > > > Pudieron ver mi caso? > > > > > > Esta en el mail anterior. > > > > Pues no lo vi porque no me llegó el mensaje de abajo. > > Y tampoco me aperece tu correo en la carpeta de /spam de Gmail :-? > > ¿Lo enviaste a mi cuenta? > > > > > El jue, 19 de may. de 2022 12:43, Héctor Ariel Rotela < > > ariel3...@gmail.com> > > > escribió: > > > > > > > Camaleón, > > > > > > > > Muchas gracias por la pronta respuesta. Yo saque un listado de todos > > los > > > > paquetes te los adjunto, para que los mires y me des una idea, de como > > > > puedo saber si cada uno de esos paquetes están con la última versión > > > > disponible. > > > > > > > > Todo sin tener la posibilidad de conectarme a internet y que no pueda > > > > armar el repositorio local. > > > > > > > > Lo que quiero tener es un comparativo como por ejemplo: > > > > > > > > APT el paquete que se actualizo con el 8.11 es : 1.0.9.8.1 > > > > > > > > Si verificas en lo que te envié > > > > > > > > APT tiene la 1.0.9.8.6 (o sea que esta actualizado después de la 8.11 > > pero > > > > no se si es la última ) > > > > > > > > No se si se entendio lo que necesito. > > > > (...) > > > > Hombre, a ver... sí te he entendido, pero ¿no sería mejor que revisaras > > tú mismo la diferencia? >:-) > > > > Dime si tu instalación es de 32 o 64 bits y te mando la lista de los > > paquetes (main/contrib/non-free) con su última versión para Jessie (el > > archivo ocupa unos 9 MiB). > > > > http://ftp.de.debian.org/debian/dists/jessie/ > Disculpen soy novato y quiero poder entender. > > Camaleón, si puedes enviarme la lista te lo voy a agradecer. Es de 32 bits Te lo anvio a tu cuenta personal. En total son 6 archivos comprimidos que enumeran las versiones 32 bits de los paquetes para Jessie. main contrib non-free (.GZ) security-main security-contrib security-nonfree (.BZ2) Para buscar, por ejemplo, la última versión de «apt» en Jessie: sm01@stt008:~/Escritorio$ zgrep -A 1 "^Package: apt$" *.gz; bzgrep -A 1 "^Package: apt$" *.bz2 main_Packages.gz:Package: apt main_Packages.gz:Version: 1.0.9.8.4 security_main_Packages.bz2:Package: apt security_main_Packages.bz2:Version: 1.0.9.8.6 Saludos, -- Camaleón
Re: [OT] OAuth y 2FA (Era: Servidor imap.gmail.com y mutt falla.)
El día 19/05/2022, a las 20:38, Camaleón escribió: > El 2022-05-18 a las 09:20 +0200, alfon escribió: > > > > 2. Configurar OAuth2 en Mutt y Fetchmail, si lo permiten, o buscar > > > alguna aplicación alternativa que sí tenga soporte. > > > > > > Seguramente, y para curarme en salud, haga las dos cosas (1 y 2) :-) > > > > > > > Las opciones son usar OAuth (no tengo claro que mutt lo soporte) o una > > > > contraseña de aplicación (pero Google no te las ofrece a menos que > > > > tengas activado el 2FA) > > > > > > Para Mutt he visto esto (no lo he probado): > > > > > > mutt integration with Gmail using OAuth > > > https://luxing.im/mutt-integration-with-gmail-using-oauth/ > > > > Yo tengo configurado mutt con Oauth2 y funciona perfectamente. Existe > > un script proporcionado por Google que automatiza en parte el proceso. > > > > Si tenéis problemas concretos configurándolo lo podemos resolver en > > este u otro hilo de la lista. > > Me parece especialmente interesante este tema, y creo que nos puede ser > de utilidad a todos, por un motivo u otro. > > He estado leyendo sobre OAuth en la página de la Wikipedia para empezar > a entender de qué va :-) > > Si no lo he entendido mal, se trata de un sistema/mecanismo/protocolo > por el que un servicio/servidor permite a un cliente generar un token > para permitir el acceso de terceros (o a él mismo) a sus datos/ > servicidos/credenciales. Por lo que yo he entendido es parecido a Kerberos: Es decir, hay un sistema mediador entre el cliente y el servidor, que proporciona el acceso a este último mediante tokens (vamos... códigos) Sería como si compro un abono transportes que me permite acceder al metro hasta que caduque. > Entiendo las ventajas que supone para la parte servidora usar ese > sistema, pero no para el cliente, y menos aún cuando se trata de correo > electrónico. El correo convencional (no el webmail) no es una API, no > es un servicio, y hacia eso lo quieren arrastrar (desnaturalizar la Yo creo que el correo electrónico es un servicio, ¿no? > esencia del coreo electrónico) pero preferiría que el servidor de correo > me pidiera en certificado digital para autentificarme que usar ese > sistema farragoso de OAuth; auguro problemas de todo tipo y máxima > incomodidad para los clientes. Un poco incómodo sí que es, pero también es más seguro que la contraseña tradicional. Mi problema es que tengo que actualizar el código de refresco cada x días. Se supone que este no caduca, pero en mi caso sí que lo hace. Esto es incómodo, porque tienes que obtenerlo ejecutando el script que proporciona gúgol (oauth2.py) y obtener un código de autorización mediante el navegador web. Para los terminalitas como yo esto es un atraso. Seguro que se puede automatizar usando curl o algo por el estilo, pero esto complica más la cosa. > > Ahora bien, lo que ya me pierde es la mezcla de OAuth con la > doble, triple o multi autentificación (2FA). Estos sistemas de doble > seguridad los entendería razonables para validar ciertas operaciones > críticas o autentificaciones ante servicios delicados, pero no para > iniciar sesión en un buzón de correo convencional (POP/IMAP, no > webmail), espero que no sean tan vacaburros de forzar también su uso o > derivarnos al webmail :-/ Si eso sucede nos hacemos un servidor de correo para nosotros, que no?!!! jeje... Yo estoy deseando hacerlo y dejar de usar gúgol.