Luego de haber corrido un experiment más o menos grande, 200 dbs de NoSQL, y obetener nuevamente 0 true positives, hay que arrancar a revisar el código. Revisando el step de data generation, encontré que en su momento diego había realizado el siguiente commit, que desacopla la generación de los known source, sinks y sanitizers, del a generación del propgraph. De esta forma se puede: Con worse libs generar los known * Con la última versión de las libs, construir el propagation graph
Descubri que la versión de la CLI no determina que dbs correr, ni que versión de las librerias. Son backwards compatible. Esto quiere decir que tomando la última versión de la CLI (2.13.1), puedo correr: - [x] Entrenamiento, usando bejamin button como libs (agregandolas en el search path), y usando dbs compiladas con 2.5.2 [x] Evaluacion v0, usando v0 como libs (agregandolas en el search path), y usando dbs compiladas con 2.5.2 [ ] Evaluacion worse boosted, usando benjamin button como libs (agregandolas en el search path), agregando los boosteos como external predicates, y usando dbs compiladas con 2.5.2
El largo del cannonical rep (la representacion usada para los sinks descubiertos) es muy importante, ya que la misma indica que tan especifico o generalizado puede estar un descubrimiento. En el pipeline esto es controlado por el siguiente parametro:
Para validar cuan bien anda el pipeline, podemos enmarcarlo como un problema de clasificacion binario, dados los resultados.
Este post contiene un compilado de librerias con las cuales el pipeline da timeout: - ASCOT/dashboardjs
Retomando la tesis post viaje(s). El ultimo release de la CLI de CodeQL a la fecha es v2.12.16, no creo estar tan atrasado ya que la que estaba usando como V0 es v2.10.5.
Por alguna razon tanto para SQL como para NoSQL se generaba un modelo vacío. Debuggeando: nohup ./scripts/docker_run.sh \ /tesis/repos/tsm-pipeline/experiments/tesis/test_nosql_5.txt \ /tesis/tmp/results/test_nosql_5/ \ "test_nosql_5" NoSql NosqlInjectionWorse &> /tesis/test_nosql_5.log & `
La idea de hoy es dejar el training de SQL corriendo. Se me ocurrió la idea de armar los experimentos en forma de librería, de forma de poder dejar escrito como un archivo de python (o un notebook), los experimentos que corro. Habría que ver qué tal fácil es dejar corriendo un server de jupyterlab, y ver si puede conectarse con el docker daemon.
La corrida de entrenamiento de tainted_path 100 termino. Fallaron algunas db, así que habría que revisar el log /tesis/tainted_path_top_100.log.
Quizas debería aumentar el tamaño del volument principal de la instancia. Está quedandose medio corto. Cree una lista de repos de 4 ejemplos para probar correr todo con los últimos cambios (principlamente o11y).
According to this, this is how you run processes in the bg. https://gist.github.com/bluenex/2db92944c51378cbc79012febd31bf9d nohup ./scripts/docker_run.sh /tesis/repos/tsm-pipeline/experiments/tesis/tainted_path/tainted_path_100_split_train.txt /tesis/tmp/results/tainted_path_top_100/ 2> /tesis/tainted_path_top_100.log & `