Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#9,551 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 5 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
security

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
10k
Fork
2k
Merge medio
4g 15h
PR unite (30g)
29

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenMined/PySyft

Tutte le issue di OpenMined/PySyft

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.