syft-job: declared code_hash never matches on a CRLF checkout, and submission_hash order differs on Windows
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
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
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di OpenMined/PySyft
-
Sub-minute job timeouts are reported as zero minutesForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. ApertaType: Bug :bug:
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
OpenMined/PySyft#9527 · 2 commenti ·
I maintainer di solito rispondono entro 5 giorni
Tutte le issue di OpenMined/PySyft
Issue simili
-
Pull-through from gcr.io returns 500 when pulling using podman/buildahForse già presa Una pull request collegata a questa issue è aperta o già unita. ApertaIssue Triage-Needed
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
pulp/pulp_container#2581 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
521xueweihan/HelloGitHub#4040 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
ClanGenOfficial/clangen#6313 ·
I maintainer di solito rispondono entro 2 giorni
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
bug(trainer): CustomTrainer func_args with non literal values fail inside the TrainJobForse già presa @avanishkasar l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
kubeflow/sdk#879 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno