Эпизоды
-
Autenticación web global y abierta. Descentralizada y privada http://podcast.jcea.es/podcastz/10
Notas:
00:40: Persona es la alternativa Mozilla a "Single Sign On" propietarios.
01:40: Manejar la complejidad de mantener claves diferentes en varios sitios.
02:50: ¿Qué es Persona?: Privacidad, descentralizado, no depender de un proveedor.
07:10: El problema del huevo y la gallina. Ahora mismo Persona es muy centralizado, riesgo de hacking ydependencia de Mozilla.
08:50: ¿Cómo funciona? Se certifica la propiedad del un correo electrónico.
10:30: ¿Qué pinta el correo en todo esto?
13:00: Cuando tu proveedor de correo no es un proveedor de identidad de Persona, entonces la certificaciónse centraliza en Mozilla.
14:30: Persona es un protocolo descentralizado que ahora mismo depende de Mozilla. A medida que el protocolotenga éxito, se irá haciendo más y más descentralizado.
16:10: ¿Cómo gestiona tu identidad tu proveedor de identidad?
19:00: ¿Cómo funciona a nivel técnico?. El workflow.
23:50: Privacidad respecto a tu proveedor de identidad. Tu proveedor de identidad no sabe qué webs visitas.
25:00: ¿Cómo valida tu identidad el verificador?
28:30: Te autentifico sin que ni siquiera tengas una cuenta en mi servicio. Por ejemplo, un blog o un foro.No necesito darme de alta.
32:30: Persona hace posible que no tengas que almacenar claves en el servidor. Podrías no tener, siquiera,una base de datos de usuarios.
33:30: Pegas de Persona: Hay pocos proveedores de identidad, así que el sistema se acaba centralizando en Mozilla.
34:30: Descripción técnica del "fallback" a Mozilla.
36:00: Mientras Persona no triunfe, se depende de Mozilla.
38:00: Mozilla permite autentificarte en Persona con autenticaciones OAuth: por ejemplo, Facebook, Google, Yahoo,Twitter, etc. Esto permite no tener una clave adicional, y te proporciona privacidad respecto a tu proveedor de Identidad.Y mantiene la identidad para el usuario.
42:00: Correlación entre logins y accesos Persona. ¿No se puede identificar a los usuarios?.Se puede evitar cacheando claves públicas de los proveedores de identidad (y con refrescos proactivos), o usando a Mozillade intermediario.
45:00: ¿Podría otro proveedor ser un proveedor de identidad secundario?. No, aunque el protocolopermite delegaciones. Varios dominios pueden delegar su autenticación en otro servidor. Útil para empresas con varios dominios,pero bajo el mismo control administrativo.
48:30: ¡Pero es que no quiero depender de Mozilla!. No se puede. Se siente. La única solución es que Personase popularice, haya más proveedores de identidad y depender menos de Mozilla. A medida que el protocolo se populariza,el peso de Mozilla baja. Al contrario que los demás sistemas SSO (Single Sign On).
51:00: Pero a Google o a Facebook no les interesa ser proveedores de identidad, porque su negocio esprecisamente conocer los hábitos de navegación de sus usuarios, porque se financian vendiendo esa información a lasagencias publicitarias.
52:30: Opinión personal sobre el futuro de Persona.
56:50: ¿Qué tiene que hacer una página web para permitir que los usuarios accedan con Persona?.Es MUY fácil, y no requiere instalar nada en el servidor.
59:00: La idea de Mozilla es que una versión futura de Firefox incluya soporte Persona nativo.Más rápido y más seguro. Para los navegadores que no incluyan la funcionalidad, usarán un javascript externo, como ahora mismo.
01:00:00: Un desarrollador web solo necesita incluir un javascript que proporciona Mozilla. Si no quierecomplicarse la vida, incluso puede delegar la verificación en Mozilla. Una implementación sencilla no requiere instalar NADAen el servidor.
01:03:30: Mozilla se ha preocupado mucho de que el usuario, el proveedor de identidad y el verificadortrabajen lo menos posible. Que tengan que hacer lo mínimo posible. Que la barrera de entrada sea muy baja.
01:05:10: Recapitulación de Pablo: facilidad para el usuario, privacidad para el usuario, descentralización yfacilidad para los verificadores.
01:06:00: Aunque los proveedores grandes no colaboren, podremos hacer login con los botones de logintradicionales (Google, Facebook, etc).
01:07:00: La conversión a proveedor de identidad se realiza dominio a dominio. No hace falta un consenso global.Una organización puede usar el protocolo Persona para ser proveedor de identidad y verificador. No depende de nadie,ni siquiera de Mozilla.
01:08:30: El protocolo sigue evolucionando. Conviene depender de Mozilla, para no sufrir las actualizaciones.
01:10:10: ¡¡¡CORTE!!!
01:10:11: Resumen.
01:13:00: Despedida.
01:13:48: Apéndice: Donación bitcoin y publicación de audios en OPUS.
-
Contraseñas... ¿Podemos vivir sin ellas? http://podcast.jcea.es/podcastz/9
Notas:
00:00: Las claves están por todas partes.
01:20: Definición y políticas.
02:15: Una clave memorizable, es una clave insegura. ¡¡Escríbelas!!. ¿O no?
07:00: ¿Qué problema tiene utilizar claves?
10:00: Estudios sobre la calidad de las claves.
Real-World Passwords
The science of password selection
15:00: Mecanismos de generación segura de claves.
18:20: Gestores de claves.
19:20: Biometría.
20:20: DNI Electrónico.
21:20: Doble autentificación.
25:30: Conclusiones.
-
Пропущенные эпизоды?
-
Últimos flecos del proyecto http://podcast.jcea.es/podcastz/8
Notas:
01:00: No enseño código porque es código propietario y porque por audio es difícilenseñar código. Estoy dispuesto a atender peticiones por correo electrónico para escribirentradas en la página web.
02:00: Usar "sys.excepthook" en vez de rodear todo tu código con un "try...except".
03:00: Uso "sys.excepthook" para que si el programa falla de forma catastrófica, envíe uninforme al servidor, con todos los detalles posibles.
04:30: Ventajas de usar "sys.excepthook" en vez de rodear todo con "try...except".
07:50: Usamos multithreading para ofrecer al disco duro varias peticiones simultaneas, deforma que pueda planificar el movimiento del cabezal de forma óptima. Paralelizar la lectura de disco.
12:10: Lanzar varias peticiones concurrentes tiene consecuencias para el usuario. Laactividad de disco propia del usuario compite con el programa.
14:30: El programa incluye un microservidor web. La interfaz de usuario es el propionavegador. Esto nos independiza del GUI propio de cada sistema operativo. Además, permitiría acceso remotode forma automática, si fuera necesario. Ojo con la seguridad.
18:30: Grabación de "checkpoints" del programa.
21:30: En Windows no se puede hacer como en Unix:grabar con otro nombre+flush+sync+rename. Hay que buscarse la vida para hacer algo que funcione en todaslas plataformas soportadas.
25:00: Como ahora tengo dos ficheros de checkpoint, debo comprobar su integridad. La integridadverifica muchas cosas, tanto que el fichero está completo como datos sobre la versión del programa, etc.
30:00: El programa se autoregistra y se le proporciona un código de registro único. Esopermite muchas cosas interesantes, además de identificar al usuario.Por ejemplo, poder ejecutar código de forma selectiva en determinadosusuarios.
37:50: Los logs se mandan a disco ANTES de mandarlos al servidor. Cuando el programa seejecuta, manda los logs pendientes presentes en disco, si los hay. ¿Por qué?. Escucha el podcast :-)
43:30: El programa descarga componentes externos de forma segura y eficiente.
48:30: Problema: si cambia un componente externo, hay que emitir una versión nueva del códigoprincipal.
50:30: Problema: cuando empieza un mes nuevo, distribuyo 32 Megabytes a 5000 usuarios. Esoson muchos Gigabytes. Y todos a la vez.
55:00: Red CDN (Content Distribution Network) del pobre: Coral Caché - http://www.coralcdn.org/.
55:30: Mi web es http://www.jcea.es/.Para entrar en mi web a través de Coral Caché,usaríamos la URL http://www.jcea.es.nyud.net/.
58:30: No hace falta ningún trámite. Tampoco te garantizan nada, claro.
59:30: En mi código tengo un "fallback": Primero intenta descargar a través de Coral,y si no funciona bien, va directamente a mi servidor. Esto es factible porque tengo control del clientey el usuario no tiene que esperar nada.
01:02:40: Mejoras posibles en la aplicación. Básicamente, usar cifrado en todas partes...o casi. Como controlamos el cliente, no es necesario que el certificado SSL esté firmado por unaentidad de certificación reconocida. Así que no hay excusa.
Una mejora que no se describe en el podcast es que el código descargado lleva una firma digital,pero un atacante podría inyectarnos una versión más antigua con, por ejemplo, problemas de seguridadconocidos. Sería interesante que el descargador no permitiese ejecutar una versión anterior a laúltima que haya descargado. Es decir, que no se pudiese volver nunca para atrás.
01:08:00: Si metemos TODO cifrado, no podemos usar Coral Caché. La solución: las firmas vanpor Coral y se verifica esa descarga a través de un hash que hemos recibido por una conexión cifrada enparalelo.
01:10:30: Mi intención con esta serie de podcasts es dar ideas a los programadores,para sus propios proyectos.
01:12:00: No puedo enseñar código real, pero si hay alguien interesado, puedo dar detalles enmi página web.
-
Estructura para comprobar pertenencia a un conjunto, de forma probabilística. http://podcast.jcea.es/podcastz/7
Notas:
01:00: Filtros Bloom. Tecnología interesante y desconocida.
01:30: El número de huellas ha ido creciendo, y la estructura de datos que usamos, "set()", tiene un costeen memoria proporcional al número de elementos. Estábamos usando 1.5GB en 32 bits, y 3GB en 64 bits.
04:30: Las huellas eran 40 millones de números (y creciendo) de 32 bits. Son 150MB en disco, pero 1.5/3 gigabytes alcargarlos en un "set()".
05:40: Idea simple para reducir los 1.5/3GB a 512MB: como trabajamos con números de 32bits, podemos tener unamatriz de 232 bits y ponerlos a cero o a uno según ese valor esté en la lista o no. Esto son 512MB.
07:15: Como tenemos una matriz de 232 bits, pero solo un 1% estará a UNO, los 512MB resultantesse pueden comprimir muy bien, típicamente al 11% (unos 55MB), aptos para ser transmitidos por Internet.
08:40: La matriz así generada no tiene falsos positivos ni falsos negativos, pero como los datos de entrada sonuna lista de 32 bits, que es una "reducción" de la fuente real original, esa lista ya induce falsos positivos. Es decir,diferentes valores en el origen que generan el mismo número de 32 bits.
10:10: Para el cliente, reducir el consumo de memoria a 512MB sigue siendo insuficiente. Su objetivo es llegara ocupar solo 64-128MB. Lo consigo reducir a 32MB, usando un filtro Bloom.
11:00: Si en vez de introducir falsos positivos en la reducción de 128bits a 32 bits, podemos utilizar los 128bitsoriginales y usar una estructura de datos con falsos positivos, una estructura "probabilística".
13:50: Explicación de cómo funciona un filtro Bloomy su tasa de falsos positivos.
14:55: "Te lo voy a explicar a ti, a ver si explicándotelo me aclaro" :-).
17:10: Explicando el concepto de "colisiones" y por qué son inevitables. Falsos positivos.
23:00: Controlamos la tasa de falsos positivos añadiendo más o menos bits y controlando el número de bits puestosa UNO por cada valor original (y el número de bits que deben ser UNO para tener un "hit").
25:30: Ahora en cada búsqueda tenemos un 2% de falsos positivos en vez del 1% inicial, pero hacemos dos búsquedas,así que la tasa de falsos positivos es del 2% del 2%, o 4 de cada 10.000 (aproximadamente).
30:30: Filtro Bloom. Hay un número óptimo de búsquedas.Las ecuaciones están en la Wikipedia.
35:45: Un filtro Bloom no se puede comprimir, su entropíaes máxima.
37:00: ¿Cómo "desdoblamos" los valores?. Es decir, que a partir de un valor de entrada, podemos poner varios bitsa UNO, de forma no correlada.
40:30: En la bibliografía de la Wikipedia se estudian algoritmos y el impacto de rendimiento que supone que los bitspuestos a UNO no sean completamente no correlados. Por ejemplo:Kirsch, Adam; Mitzenmacher, Michael (2006), "Less Hashing, Same Performance: Building a Better Bloom Filter", in Azar, Yossi;Erlebach, Thomas, Algorithms - ESA 2006, 14th Annual European Symposium, 4168, Springer-Verlag, Lecture Notes inComputer Science 4168, pp. 456-467, doi:10.1007/11841036
43:20: Estamos abusando de las matemáticas del filtro Bloom,así que antes de distribuir el filtro hacemos unasimulación con él en el servidor.
45:30: Un filtro Bloom tiene falsos positivos,pero NO tiene falsos negativos.
-
Usar el DNS como un sistema de cacheo mundial. http://podcast.jcea.es/podcastz/6
Notas:
00:30: El proyecto es confidencial, pero quiero exponer algunas técnicas que puedenser útiles para otros programadores.
02:50: El programa requiere actualizarse constantemente de forma automática.
04:30: El usuario solo instala manualmente un "descargador".
05:50: Descripción del proceso de actualización.
06:30: Firma digital, imprescindible cuando hay actualizaciones constantes a través deredes no confiables.
08:00: En la primera versión del proyecto, el programa se descargaba en cada ejecución (20KBytes).
09:00: Pero esto no escala cuando el número de usuarios crece, o el tamaño del fichero crece.
13:30: Usar el DNS para comprobar las versiones, utilizándolo de caché. A nivel mundialy de forma simple.
15:20: Cuando un ordenador pide a su ISP que haga una petición de DNS, dicho ISP cacheael resultado y está disponible para otros clientes. Y el tiempo de cacheo es configurable en el servidororigen.
17:30: Problema: sin instalar librerías adicionales, Python tiene una capacidad de interaccióncon el DNS muy limitada. Hay que buscarse la vida.
19:30: En vez de decir a través del DNS qué versión es la más moderna, lo que hacemos espermitir que el cliente confirme si su versión es la última o no. Comprobamos si el registro"HASH_MD5.md5.DOMINIO" existe o no.
22:40: Ojo con los ISPs puñeteros que resuelven a sus propias IPs las resoluciones DNS inexistentes.Solución: Comprobamos que la IP resuelta sea la esperada.
25:00: Firma digital por El Gamal.
27:20: El actualizador no hace más descargar la versión actual (con todas las verificaciones)y luego le pasa el control. Actualizar el actualizador es "complicado" :).
-
Intrusión en RSA. http://podcast.jcea.es/podcastz/5
Notas:
00:33: RSA admite que ha habido una intrusión en sus sistemas.
01:31: En el comunicado no se indica qué información ha sido obtenida.
02:05: En qué consiste el sistema SecurID de RSA.
03:31: El token.
04:07: Los detalles del ataque.
07:19: Una vez dentro es cuestión de buscar el camino al objetivo.
09:07: Como Indiana Jones, una vez tienes el "ídolo de oro" hay que escapar adecuadamente.
11:35: Pero, ¿qué se han llevado?. Especulaciones varias.
18:41: El PIN, un elemento de seguridad opcional extra del sistema SecurID.
22:12: Más especulaciones.
23:35: Conclusiones.
33:21: Para un futuro podcast: Cómo debiera funcionar un sistema desde el punto de vista de la seguridad.
35:55: Un par de detalles finales.
Enlaces relevantes:RSA explains how attackers breached its systemsAnatomy of an Attack"RSA/EMC: Anatomy of a compromiseThe RSA Hack: How They Did It"RSA: SecurID Attack Was Phishing Via an Excel SpreadsheetRSA Says SecurID Hack Based On Phishing With Flash 0-DayRSA SecurID data compromisedSecurIDSpearphishing + zero-day: RSA hack not 'extremely sophisticated'RSA won't talk? Assume SecurID is brokenThe RSA/SecurID Compromise: What is my risk?"The RSA SecurID ProblemRSA Breached: SecurID Affected
-
Mejor probar las cosas ANTES de que las necesites de verdad. http://podcast.jcea.es/podcastz/4
Notas:
00:30: Aunque tengamos un backup, si el ordenador no arranca no tendremos acceso a él.
00:50: Hacer un buen backup no es algo fácil, pero será tema de un futuro podcast.
01:30: En este podcast trataremos sobre qué ocurre si, un día, el ordenador no arranca. Hay que estar preparadospara esa eventualidad.
04:00: Necesitas que el sistema y el procedimiento de recuperación esté bien probado y sea autocontenido, ya que nopuedes contar con el ordenador si no puedes ni arrancarlo. En caso de necesidad, tener un smartphone que nos permita utilizar Internetpuede ser de gran utilidad.
04:30: Hablando de entornos Unix o similares (Linux, *bsd), todos ellos tienen sistemas de recuperación de emergencia.
07:20: Pero hay que asegurarse de que el sistema de recuperación funciona correctamente y sabemos utilizarlo,especialmente si nuestro sistema está muy personalizado.
09:30: Hay que probar las cosas con calma y antes de tener problemas, para saber que podemos contar con ellocuando estemos agobiados y en plena crisis.
13:00: No hay que dar nada por supuesto. Las cosas hay que probarlas antes de que las necesitemos.
13:20: Así que, por supuesto, lo pruebas... y no funciona...Utilizo "XTS" y el disco de recuperación de Ubuntuno lo soporta, a pesar de estar soportado por el propio sistema operativo y de ser la configuración recomendada a fecha de hoy.
15:50: Gracias a estar haciendo estas pruebas de recuperación mientras la máquina está funcionando bien, sinproblemas, puedo acceder al módulo kernel para soportar XTS que está en el propio disco duro, para poder continuar conmis pruebas... Pero no funciona.
16:40: Y no funciona porque el kernel y los módulos están versionados, de forma que no puedes mezclar versionesdiferentes de kernel y módulos, para evitar incompatibilidades. Pero, en este caso, tengo un problema.
19:10: Pero resulta que en mis backups tenía el módulo XTS apropiado para el kernel incluído en el disco derecuperación, así que aprovechando que el ordenador funciona sin problemas (estoy probando el procedimiento de recuperaciónantes de que necesite utilizarlo), lo recupero y lo dejo accesible. Pero... ¡Tampoco funciona!.
21:35: Hacer un "insmod ./xts.ko" no funciona, porque "hay símbolos que no es capaz de resolver". El problemaes que ese módulo tiene dependencias de otros. Esos módulos extra están en el disco duro, en el mismo directorio, pero no loscarga automáticamente.
23:15: Cargamos la dependencia primero y luego cargamos el módulo que nos interesa. Es decirinsmod ./gf128mul.koinsmod ./xts.ko
pero... tampoco funciona...
24:05: No funciona porque, a su vez "gf128mul.ko" depende de otro módulo, el módulo AES.AES es el estándar de criptografíasimétrica actual, declarado así en 2001.
24:20: El procedimiento, pues, seráinsmod ./aes_generic.koinsmod ./gf128mul.koinsmod ./xts.ko
24:50: Esos módulos están en mi disco duro, no en el LiveCD. Si hay un problema serio con el disco duro,puedo no tener acceso a ellos. Lo correcto es a) montar la ISO de recuperación, b) Añadir esos tres módulos kernel, que ocupan muypoco y c) grabar un nuevo LiveCD, personalizado, con incluyendo esos módulos.
28:20: Esto es una errata de Ubuntu, que supongo que solucionarán en el futuro.
-
Encender el ordenador y que no funcione es frustrante... http://podcast.jcea.es/podcastz/3
Notas:
00:37: El ordenador no arranca. El GRUB falla.
01:00: ¿Qué es el GRUB?.Un gestor de arranque para cargar y lanzar el sistema operativo.
03:13: Reinstalar es la última opción. O debería serlo.
03:43: Pablo: "Así que eres uno de esos raritos que se ponen a personalizar el ordenadorhasta el último detalle?". Jesús: "Cuando te pasas 15 horas al día usando una herramienta, más te vale que laherramienta se adapte a ti, y no al revés".
04:30: Los problemas con el GRUB son rutinarios para mí. Doy un ejemplo concreto.
05:50: El error está claro. ¿Cómo solucionarlo?. Arrancar con un disco de recuperación yreinstalar el GRUB.
07:25: Pero... no funciona. ¡No se deja instalar!.
08:10: Explico cómo tengo configurado el disco duro. Uso LVM,y la partición de arranque no es una partición en sí, sino un volumen lógico. Las versionesrecientes de GRUB te lo permiten.
10:00: El GRUB no se deja instalar. Descripción de los errores que me salen. Errores un pocoextraños, porque se queja de cosas que deberían funcionar.
11:30: Uno de los errores es una pista: No encuentra el volumen lógico de arranque. Esono tiene sentido, porque el volumen lógico de arranque es perfectamente accesible, lo puedo montar sinproblemas, y funcionaba esta mañana. Ejecuto el proceso de instalación del GRUB bajo"strace", para ver exactamente qué estáhaciendo y dónde falla.
12:30: Con "strace" veo que el sistema de instalación de GRUB accede sin problemas a todoeso que me indica luego, con errores, que no puede acceder. ¡Extraño!.
12:56: Nueva pista: uno de los errores es que el volumen lógico de arranque no es capazde gestionar UUIDs, aunque con "strace" veo que eso no es cierto.
14:05: No cabe duda que se trata de un bug. Pero, ¿qué he hecho yo para provocarlo?.¿Cómo solucionarlo?. Hago diversos experimentos.
15:05: Tengo UUIDs duplicados... ¿Pero no se supone que losUUIDs únicos?.Son los snapshots LVM, que mantienenel UUID del volumen lógico original. ¿Pista?. Me llama la atención...
17:20: Que los Snapshots LVM tengan el UUID duplicado parece algo hecho aposta, pero este hechoy los errores que obtenía al intentar reinstalar el GRUB me recuerdan que sí había hecho algo "raro" ese día:crear un Snapshot LVM de mi "home", es decir, de mis datos personales. No debería afectar al arranque, pero...
18:10: Se me iluminó la bombilla :-)
18:45: Pruebo a borrar ese snapshot, ya que era un experimento prescindible.El sistema operativo arranca. ¡¡Funciona!!.
19:10: ¿Por qué tener un snapshot LVM te impide arrancar el ordenador?. Hago varias pruebasy parece evidente que se trata de un bug del GRUB.
20:00: Estupendo, no podemos usar una de las grandes ventajas de emplear LVM. ¡Si tienes algúnsnapshot, olvídate de reiniciar el ordenador!.
20:49: Las condiciones para desencadenar el fallo son: a) Tener un GRUB reciente quepermita arrancar desde un volumen lógico, b) Tener el arranque en un volumenlógico, y c) Tener algún snapshot en el mismo grupo de volúmenes donde está ese volumen lógico de arranque.
21:18: Una vez que determinamos las condiciones exactas del fallo busco porInternety veo que se trata de un problema conocido de GRUB.Está solucionado en las versiones modernas, pero la mayoría de las distribuciones de linux "estables",en el momento de grabar el podcast, no incorporan esta versión.
21:35: Resumen de todo el proceso mental de diagnóstico y resolución.
-
Monkey Patching, Duck Typing e Inyección de Dependencias. http://podcast.jcea.es/podcastz/2
Notas:
00:50: Se utiliza un caso real para explicar estas técnicas con más facilidad.
01:50: La librería estándar para el envío de correo electrónico en Python, laSMTPlib, se nos queda pequeña (para este proyecto en concreto).
02:01: ¡Sí!, ¡por supuesto que usamos Python!.
02:12: Pero estas técnicas son aplicables también a otros lenguajes dinámicos.
02:48: Los motivos por los que laSMTPlib se me quedaba pequeña: Quiero"timeouts" dinámicos, quiero limitar el número de conexiones simultaneas por servidor de correo,y quiero controlar la IP de origen de la conexión saliente.
05:52: ¿Por qué no modificamos el código directamente o utilizamos los mecanismosde herencia normales?. Por mantenimiento de código y porque lo que queremos modificar no esfácilmente accesible por herencia porque está muy "profundo" en la clase original.
09:04: Por fin entramos en materia. Empezamos conMonkey Patching. Modificaciónde código, clases y objetos en memoria.
12:44: ¿Cuándo es preferible utilizarMonkey Patching en vezde mecanismos más habituales?.
13:30: Otro ejemplo deMonkey Patching: Los"hot fixes"tradicionales de ZOPE.
16:29: Por supuesto, esta técnica es compleja y delicada, y tiene sus riesgos.
18:17: Pasamos a hablar deDuck Typing. Polimorfismo sinherencia. Frase del día: "Es un pato a efectos prácticos". O su corolario posterior:"Si parece un pato, es un pato. Aunque no lo sea" :-).
20:25: En lenguajes estáticos como Java, se utiliza el concepto de"interfaces abstractos",verificados en tiempo de compilación. Con Python no se realiza ninguna comprobación, y la compatibilidadde tipos se decide en tiempo de ejecución, cuando se invocan métodos concretos con parámetros concretos.
22:19: Los interfaces abstractos te permite definir dos objetos como compatibles, aunque nohereden de las mismas clases.
22:28: Un ejemplo de interfaces es la abstracción de ficheros en Python (o, por ejemplo, enla filosofía UNIX de que todo es un fichero).
22:54: El Duck Typingtambién tiene sus problemas.
25:09: Hay dos escuelas de pensamiento en casi todo, dicotomías por doquier.
26:00: Una forma de estar tranquilos es tener una buenabatería de test.
26:45: Hablamos ahora deinyección de dependencias.Recapitulamos y, ahora, todo encaja.
28:41: Desvinculamos la dependencia implícita interna que tiene una librería, yla hacemos explícita y manipulable.
29:00: La inyección de dependencias te facilita mucho la vida a la hora de probar el código.
30:40: Bueno, en realidad el programa de ejemplo que he usado para ilustrar la descripciónde estas técnicas no funciona como se ha descrito :-). Se emplea también Monkey Patching,pero de forma diferente y más estableante actualizaciones python. Lo detallé en mi web en 2007.
31:40: Fé de erratas.
-
Proponemos utilizar HTTPS en todas partes. No hay excusa para no hacerlo. http://podcast.jcea.es/podcastz/1
Notas:
00:25: Navegar por WIFIs abiertas compromete nuestra seguridad.
01:07: La solución es utilizarcifrado. ¿Qué es cifrar?. ¿Cómo funciona el cifrado?.
02:45: Entidades de certificación.
05:00: Las entidades de certificación no son nada especial ni mágico.
06:50: La verificación de identidad de la mayoría de las entidades de certificaciónno es confiable.
09:25: Certificados autofirmados.
13:25: Ataque "Man-in-the-Middle".
16:20: Es preferible cifrar a no cifrar. Al menos estamos protegidos ante ataques pasivos.
18:30: SNI: "Server Name Indication".
22:32: Problemascon SNI y Microsoft Windows XP, a menos que se use un navegador comoMozilla Firefox, que utiliza su propia librería criptográfica. También hay problemas menores con libreríasen algunos lenguajes de programación.
25:15: ¿Problemas de rendimiento?. ¡NO!.Repasamos CPU, latencia, ancho de banda ycaché de navegadores.
32:00: ¿DNSSEC como sistema de certificación alternativo?.
36:39: Fé de erratas.
