Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

syft-job: declared code_hash never matches on a CRLF checkout, and submission_hash order differs on Windows

Abierto
  • ¿Algo no está bien?
#9,551 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 5 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
security

Línea de trabajo

Start in submission.py by tracing code_hash(as_sent=True), _as_sent, and _digest, then reproduce the CRLF and mixed-case filename examples from the issue. Done means the owner and submitter compute identical hashes across CRLF/LF, Windows/Linux ordering, and the stated encoding cases, with the relevant behavior covered by tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Since #9536, a job counts as received only when code_hash(as_sent=False) on the data owner's files equals the code_hash(as_sent=True) the submitter declared. I hit two cases where the two sides compute different digests over the same job.

1. CRLF bytes on the owner's disk. _as_sent reads each file in text mode, which turns \r\n into \n. The owner side then hashes the raw disk bytes. If the owner's copy keeps CRLF, the hashes never match and the job never counts as received. I first saw this in a two-role run sharing one folder on a Windows git checkout with core.autocrlf=true. Minimal repro with submission.py from main:

run.sh = b"#!/bin/sh\r\npython code/main.py\r\n"
code/main.py = b"print('hi')\r\n"

code_hash(d, as_sent=True)  -> 9e3488aafc502eb4...
code_hash(d)                -> c414493b5e759660...   (never matches)
same files with LF          -> 9e3488aafc502eb4...

The two-machine sync path may never produce CRLF on the owner side. I have not run it on a Windows owner, so I can't say whether this case reaches users through sync or only through local and shared-folder setups.

2. File order on Windows. _digest sorts Path objects. WindowsPath compares case-insensitively and PosixPath does not. For code/B.py and code/a.py, Windows hashes a.py first and Linux hashes B.py first. A submitter on Windows and an owner on Linux then disagree whenever a job has mixed-case names. Sorting on relative.as_posix() would make the order the same everywhere.

3. A smaller related point. _as_sent opens files with the locale encoding. That is cp1252 on many Windows machines, so non-ASCII source text may encode differently from the owner's UTF-8 copy. Passing encoding="utf-8" (with the existing fallback to raw bytes) would pin it. I found this by reading the code, not in a run.

Possible fix for all three: hash relative.as_posix() in sorted string order, and normalize newlines and encoding identically on both sides, or on neither.

Context: I built an independent result receipt on top of the approved hash from #9536. It lets anyone check that a published score came from the exact approved job, with no access to the model or the data. The receipt restates your hash format with the standard library, which is how these edges surfaced. The code and docs are at https://github.com/HarperZ9/flywheel/blob/main/docs/features/pysyft-result-receipt.md. I'm happy to open a PR for the sort fix if that helps.

Lenguaje dominante
Python
Estrellas
10k
Forks
2k
Merge medio
4 d 3 h
PR fusionados (30 d)
26

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenMined/PySyft

Todos los issues de OpenMined/PySyft

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.