Tutoriales y Manuales
Entradas Mensuales
-
►
2024
(Total:
1015
)
- ► septiembre (Total: 50 )
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
►
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
►
2020
(Total:
212
)
- ► septiembre (Total: 21 )
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
▼
2018
(Total:
150
)
-
▼
noviembre
(Total:
21
)
- Incidente de Seguridad en tienda Dell.com
- Servicio de Correos Americano (USPS) expone datos ...
- Alemania quiere regular los routers que usan los u...
- Congreso Español aprueba el cierre de páginas web ...
- 0-day en PHP: borran 6.500 sitios de la Dark Web e...
- Ministro Ciberseguridad Japonés nunca ha usado un ...
- Herramientas y recursos de seguridad en Amazon Web...
- Seguridad informática con Raspberry Pi
- Crean huellas dactilares maestras capaces de engañ...
- Firefox avisa cuando entras a una web que haya sid...
- ISP Nigeriano redirecciona por error tráfico de Go...
- Actualización de seguridad para Plugin WordPress p...
- Bot crea parches en GitHub bajo pseudónimo humano ...
- CAINE 10 - Computer Aided Investigative Environmen...
- Valve recompensa con 20 mil dólares descubridor bu...
- Copia de Seguridad de WhatsApp en Google Drive
- PHP 5 y 7.0 dejarán de tener soporte a finales de año
- Manual JavaScript quiere que aprendas el 80% de to...
- Samsung anuncia su primer smartphone con pantalla ...
- Vulnerabilidades críticas en el cifrado nativo de SSD
- Hackers vinculados a Corea del Norte roban millone...
-
▼
noviembre
(Total:
21
)
-
►
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
►
2016
(Total:
266
)
- ► septiembre (Total: 38 )
-
►
2015
(Total:
445
)
- ► septiembre (Total: 47 )
-
►
2014
(Total:
185
)
- ► septiembre (Total: 18 )
-
►
2013
(Total:
100
)
- ► septiembre (Total: 3 )
-
►
2011
(Total:
7
)
- ► septiembre (Total: 1 )
Blogroll
Etiquetas
seguridad
(
395
)
privacidad
(
363
)
google
(
353
)
ransomware
(
337
)
vulnerabilidad
(
299
)
Malware
(
263
)
Windows
(
243
)
android
(
242
)
tutorial
(
235
)
cve
(
233
)
manual
(
220
)
software
(
201
)
hardware
(
193
)
linux
(
124
)
twitter
(
115
)
ddos
(
94
)
WhatsApp
(
90
)
Wifi
(
85
)
cifrado
(
77
)
herramientas
(
75
)
hacking
(
73
)
sysadmin
(
67
)
app
(
65
)
Networking
(
56
)
nvidia
(
52
)
ssd
(
51
)
youtube
(
50
)
adobe
(
43
)
firmware
(
42
)
office
(
41
)
hack
(
40
)
firefox
(
35
)
contraseñas
(
32
)
eventos
(
32
)
antivirus
(
31
)
juegos
(
31
)
cms
(
30
)
flash
(
28
)
anonymous
(
27
)
MAC
(
25
)
apache
(
25
)
programación
(
25
)
exploit
(
23
)
javascript
(
22
)
multimedia
(
22
)
Kernel
(
20
)
ssl
(
19
)
SeguridadWireless
(
17
)
documental
(
16
)
Forense
(
15
)
conferencia
(
15
)
Debugger
(
14
)
lizard squad
(
14
)
técnicas hacking
(
13
)
auditoría
(
12
)
delitos
(
11
)
metasploit
(
11
)
Virtualización
(
10
)
adamo
(
9
)
reversing
(
9
)
Rootkit
(
8
)
Ehn-Dev
(
7
)
MAC Adress
(
6
)
antimalware
(
6
)
oclHashcat
(
5
)
Entradas populares
-
Después de ver qué es una vCPU y la diferencia entre núcleos (cores) e hilos en los procesadores, pasamos a explicar toda la nomenclatura d...
-
En el panorama en constante evolución de la seguridad de redes, OpnSense se ha convertido en una formidable solución de firewall. Nacido de...
-
Pese a que Gemini ofrece multitudes de opciones, recientemente, se ha dado a conocer una situación fuera de lo común. Hace unos días, un es...
Bot crea parches en GitHub bajo pseudónimo humano para que confíen en él
jueves, 15 de noviembre de 2018
|
Publicado por
el-brujo
|
Editar entrada
Luc Esape es un ingeniero de software del equipo de investigación
Spirals en la Universidad de Lille en Francia. Trabaja con el equipo de
investigación desde enero de 2017 y su misión es encontrar bugs en
software de código abierto publicado en GitHub. Es de los mejores
detectando errores y proponiendo parches, pero juega con algo de ventaja, es una
máquina.
En realidad su nombre real, el que le pusieron sus creadores, es Repairnator. Repairnator fue creado con la capacidad de corregir errores mucho mejor que los humanos, para ello analiza en tiempo real el código que se compila y sube a repositorios mediante integración continua. El bot funciona en Java, utilizando la cadena de herramientas Maven, en proyectos de código abierto alojados en GitHub que usan Travis CI. Básicamente analiza los proyectos enviados a GitHub, encuentra errores, los arregla con sus conocimientos y envía la corrección a los propietarios de los proyectos.
Que sea un bot le permite estar continuamente trabajando y ser más veloz que nadie. Por ejemplo, a principios de este año encontró un error en una compilación del proyecto GeoWebCache que se había publicado en GitHub diez minutos antes. Diez minutos después de encontrarlo, ya había enviado una propuesta de corrección a los responsables del proyecto. A pesar de que Luc Esape sabe corregir errores, no puede apreciar si le dan las gracias por corregirlos.
¿La máquina no sabe código tan bien como un desarrollador? No exactamente, al parecer el problema está en que toleramos más fallos de un humano que de una máquina. Por lo tanto, estamos más predispuestos a aceptar un código de un humano porque "si luego está mal no pasa nada porque todos nos equivocamos" que de un bot porque "es una máquina y debe hacerlo perfecto pero no hay forma de comprobar que no se ha equivocado".
Sus creadores indican que para demostrar que es capaz de estar a la altura de sus colegas humanos, Repairnator no solamente debe crear parches de calidad, sino que debe crearlos antes que cualquier humano. Es más, tampoco puede crear un código correcto pero incomprensible para los desarrolladores, sino que debe limitarse en estilo y calidad a lo que un desarrollador humano puede hacer. En otras palabras, debe asemejarse al máximo posible con los humanos pero ser más veloz que ellos.
Con tal de que las contribuciones hechas por Repairnator fuesen juzgadas por su mérito, los investigadores le dieron una identidad secreta: Luc Esape. Ahora que los investigadores ya han comprobado este perjuicio, revelan la naturaleza del Luc Esape con cada contribución que hace. Los desarrolladores tienen también las instrucciones para bloquear a Luc Esape si no quieren recibir más correcciones de él.
Un bot no puede firmar un acuerdo de licencia porque la ley no lo permite. ¿Quién es el responsable si ocurre algo y es culpa del código desarrollado por el bot? ¿Es culpa del creador del bot, del que lo implementó o del que aceptó su solicitud? De momento Repairnator se está ganando la confianza en la comunidad GitHub, pero aún le queda mucho para ser considerado uno más.
Fuente:
https://www.xataka.com/robotica-e-ia/este-bot-crea-parches-para-software-codigo-abierto-pseudonimo-humano-confien
- RoBot crea parches para software de código abierto bajo el pseudónimo de un humano para que confíen en él
En realidad su nombre real, el que le pusieron sus creadores, es Repairnator. Repairnator fue creado con la capacidad de corregir errores mucho mejor que los humanos, para ello analiza en tiempo real el código que se compila y sube a repositorios mediante integración continua. El bot funciona en Java, utilizando la cadena de herramientas Maven, en proyectos de código abierto alojados en GitHub que usan Travis CI. Básicamente analiza los proyectos enviados a GitHub, encuentra errores, los arregla con sus conocimientos y envía la corrección a los propietarios de los proyectos.
Que sea un bot le permite estar continuamente trabajando y ser más veloz que nadie. Por ejemplo, a principios de este año encontró un error en una compilación del proyecto GeoWebCache que se había publicado en GitHub diez minutos antes. Diez minutos después de encontrarlo, ya había enviado una propuesta de corrección a los responsables del proyecto. A pesar de que Luc Esape sabe corregir errores, no puede apreciar si le dan las gracias por corregirlos.
Los perjuicios por ser un bot
Por muy bueno que sea Repairnator corrigiendo errores y proponiendo parches a la comunidad de desarrolladores, no es del todo aceptado por los de su entorno. Los investigadores detrás del bot se dieron cuenta de esto comprobando las reacciones de los desarrolladores al recibir las propuestas de corrección. Según indican, los desarrolladores no aceptan las contribuciones de los robots tan fácilmente como las contribuciones de otros humanos, incluso si son estrictamente idénticas.¿La máquina no sabe código tan bien como un desarrollador? No exactamente, al parecer el problema está en que toleramos más fallos de un humano que de una máquina. Por lo tanto, estamos más predispuestos a aceptar un código de un humano porque "si luego está mal no pasa nada porque todos nos equivocamos" que de un bot porque "es una máquina y debe hacerlo perfecto pero no hay forma de comprobar que no se ha equivocado".
Sus creadores indican que para demostrar que es capaz de estar a la altura de sus colegas humanos, Repairnator no solamente debe crear parches de calidad, sino que debe crearlos antes que cualquier humano. Es más, tampoco puede crear un código correcto pero incomprensible para los desarrolladores, sino que debe limitarse en estilo y calidad a lo que un desarrollador humano puede hacer. En otras palabras, debe asemejarse al máximo posible con los humanos pero ser más veloz que ellos.
Con tal de que las contribuciones hechas por Repairnator fuesen juzgadas por su mérito, los investigadores le dieron una identidad secreta: Luc Esape. Ahora que los investigadores ya han comprobado este perjuicio, revelan la naturaleza del Luc Esape con cada contribución que hace. Los desarrolladores tienen también las instrucciones para bloquear a Luc Esape si no quieren recibir más correcciones de él.
El bot no tiene responsabilidades
Se dejen de lado o no los perjuicios antes las correcciones recibidas de un bot, Repairnator tiene un problema aún mayor. Puede que la comunidad de desarrolladores lo acepte, pero ante los ojos de la ley, no es igual que los demás. Repairnator ya ha experimentado esto con un parche que envió para el proyecto Ditto de Eclipse Foundation. El parche corregía un error de software correctamente, pero los desarolladores no quisieron aceptarlo porque el bot no había firmado el Acuerdo de licencia de colaborador de Eclipse Foundation.Un bot no puede firmar un acuerdo de licencia porque la ley no lo permite. ¿Quién es el responsable si ocurre algo y es culpa del código desarrollado por el bot? ¿Es culpa del creador del bot, del que lo implementó o del que aceptó su solicitud? De momento Repairnator se está ganando la confianza en la comunidad GitHub, pero aún le queda mucho para ser considerado uno más.
Fuente:
https://www.xataka.com/robotica-e-ia/este-bot-crea-parches-para-software-codigo-abierto-pseudonimo-humano-confien
Enviar por correo electrónico
Escribe un blog
Compartir en X
Compartir con Facebook
Compartir en Pinterest
0 comentarios :
Publicar un comentario
Los comentarios pueden ser revisados en cualquier momento por los moderadores.
Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.
Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.