Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
Outils/GitHubGitHub/jepsen-io/duckdb
Analyse des VulnérabilitésArticles et RechercheApprentissage et ÉducationSécurité des Bases de DonnéesDétection d'Anomalies
GitHubjepsen-io/duckdb

duckdb

Framework de test de justesse transactionnelle basé sur Jepsen pour DuckDB, détectant des anomalies d'isolation telles que les violations G2-item et SSI via des charges de travail aléatoires et le vérificateur Elle.

Voir le dépôt
525il y a 5 moisPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

Test Jepsen DuckDB

Tests Jepsen pour la base de données DucKDB. S'exécute localement, plutôt que sur un cluster distant. Le test lance une collection de processus locaux qui ouvrent un fichier DuckDB localement et interagissent avec eux via STDIN/STDOUT.

Il s'agit d'un prototype précoce. Il démarre, exécute des transactions, vérifie leur exactitude et signale des bugs, mais je ne suis pas sûr que ces bugs soient réels.

Installation

Vous aurez besoin d'un JDK (21+), de Git, Gnuplot, Graphviz, plus Leiningen. Contrairement à la plupart des tests Jepsen, celui-ci s'exécute entièrement localement ; vous n'avez pas besoin d'un cluster de machines, de clés SSH, etc.

Debian

root@kitploit:~
sudo apt install openjdk leiningen gnuplot graphviz

OS X

root@kitploit:~
brew install openjdk leiningen gnuplot graphviz

Utilisation

Pour exécuter un test, essayez :

root@kitploit:~
lein run test

DuckDB fournit (je suspecte) une isolation forte de snapshot (Strong SI) par défaut, et c'est ce que le test vérifie. Cela permet cependant les G2-item, ce qui est une violation de la lecture répétable (Repeatable Read). Pour le démontrer, essayez :

root@kitploit:~
lein run test --time-limit 10 --expected-consistency-model serializable --max-writes-per-key 8

Nous demandons à tester pendant dix secondes, pour rechercher des violations de la sérialisabilité, et (pour générer de petits exemples lisibles), écrire seulement 8 éléments par clé. Des exemples de G2-item devraient être disponibles dans store/latest/elle/G2-item.

Plusieurs options de réglage sont disponibles. L'aide pour les différentes options est disponible via lein run test --help.

Les résultats des tests sont écrits dans store/<nom-du-test>/<date>/ et liés symboliquement sous store/latest. Chacun de ces répertoires de test est autonome ; vous pouvez le copier, le tarer, l'analyser plus tard, le supprimer, etc. Vous pouvez également exécuter un serveur web pour parcourir les résultats.

root@kitploit:~
lein run serve

Un REPL est disponible ; voir lein repl.

Structure

Le harnais de test se trouve dans ce répertoire ; son fichier projet est project.clj, son code source se trouve dans src/, etc.

Le harnais de test exécute un programme séparé, le « nœud local », qui intègre la bibliothèque DuckDB et effectue des transactions sur celle-ci. Le harnais de test génère des transactions aléatoires pour une charge de travail donnée, les soumet via HTTP au nœud local, et enregistre les résultats de ces transactions, vérifiant à la fin diverses anomalies transactionnelles. Nous recherchons l'isolation forte de snapshot (Strong Snapshot Isolation), en utilisant le vérificateur Elle (https://github.com/jepsen-io/elle).

Le nœud local dispose d'un petit serveur HTTP qui reçoit des transactions abstraites (par exemple « lire la clé x, puis définir y à 5 ») du harnais de test, et les traduit en transactions exécutées via le pilote JDBC de DuckDB.

Nous pouvons injecter un type de panne : les arrêts de processus.

Charges de travail

Nous avons deux charges de travail.

La première, append, exécute des transactions qui ajoutent des entiers uniques à des listes et lit le contenu de ces listes. Chaque liste se trouve dans une seule ligne, répartie sur plusieurs tables. Les listes sont identifiées par une clé primaire ou une clé secondaire non indexée. Les listes sont encodées soit comme des champs de texte, soit comme des listes DuckDB INTEGER{]. La mutation est effectuée soit avec INSERT ON CONFLICT UPDATE, soit avec MERGE INTO.

La seconde, fkey-register, effectue des lectures et écritures de registres entiers. Dans DuckDB, nous stockons ces registres dans deux tables. Une table logique associe les clés aux identifiants physiques, avec une clé étrangère. Une table physique associe les identifiants physiques aux valeurs. Nous utilisons une simple jointure entre les deux pour la lecture. Les écritures sont effectuées soit en mettant à jour la ligne physique, soit en créant une nouvelle ligne physique et en modifiant le pointeur logique vers celle-ci. Je viens de faire fonctionner cette charge de travail aujourd'hui ; elle s'exécute, mais elle n'est pas encore peaufinée.

Licence

Copyright © 2026 Jepens, LLC

Ce programme et les documents qui l'accompagnent sont mis à disposition sous les termes de la licence Eclipse Public License 2.0 disponible à l'adresse https://www.eclipse.org/legal/epl-2.0.

Ce code source peut également être mis à disposition sous les licences secondaires suivantes lorsque les conditions d'une telle disponibilité énoncées dans la licence Eclipse Public License, v. 2.0 sont remplies : GNU General Public License telle que publiée par la Free Software Foundation, soit la version 2 de la licence, soit (à votre choix) toute version ultérieure, avec l'exception GNU Classpath disponible à l'adresse https://www.gnu.org/software/classpath/license.html.

Télécharger l’outil