Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#9,551 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
security

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Python
スター
10k
フォーク
2k
平均マージ
4日 3時間
マージ済み PR（30日）
26

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

OpenMined/PySyft のほかの issue

OpenMined/PySyft の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。