Distinct repositories reuse clone and embedding state through name collisions
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
Línea de trabajo
Start with Repo._extract_repo_name and trace how its returned name is used to build databases/{repo.name}.pkl under repo.root_path. Reproduce the collision with the GitHub and GitLab URLs given in the issue, then verify that distinct canonical repository URLs produce distinct storage keys and no existing clone or index state is reused.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Affected versions: confirmed on main at commit d92819a9 (the project publishes no tagged release).
Summary
Repo._extract_repo_name derives the clone/embedding storage key only from the last two URL path segments (owner_repo). This drops the host and any subgroup path segments beyond the last two, so two different repositories (different host, or a GitLab subgroup path sharing its last two segments with a different repo) can derive the same storage key and reuse each other's clone/index state.
Details
owner = url_parts[-2]
repo = url_parts[-1].replace(".git", "")
repo_name = f"{owner}_{repo}"
save_db_file = os.path.join(repo.root_path, "databases", f"{repo.name}.pkl")
https://github.com/acme/widget and https://gitlab.com/acme/widget derive the identical key acme_widget, as do https://gitlab.com/acme/widget and https://gitlab.com/some/other/group/acme/widget.
POC
(available upon request)
Impact
A caller who primes a colliding storage key (indexing a repository they control whose derived name matches a target's) causes a later request for the real target to reuse that state: cross-repository source disclosure and integrity confusion in the served wiki/chat content.
Suggested fix: key storage with a digest of the canonical scheme, host, full repository path, and type. A fix is included in the linked PR.
Fix: #594
- Lenguaje dominante
- Python
- Estrellas
- 18.1k
- Forks
- 2k
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de AsyncFuncAI/deepwiki-open
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
AsyncFuncAI/deepwiki-open#608 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
AsyncFuncAI/deepwiki-open#602 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
AsyncFuncAI/deepwiki-open#589 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
AsyncFuncAI/deepwiki-open#539 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
AsyncFuncAI/deepwiki-open#610 ·
Todos los issues de AsyncFuncAI/deepwiki-open
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
MystenLabs/MemWal#1163 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
infertopics leaves new nodes without a topic when untopiced neighbours outnumber topiced onesPosiblemente ocupada @moneebullah25 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
ClanGenOfficial/clangen#6254 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
FinanceFlash/unvibecode#218 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día