Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#9,551 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
10k
Fork
2k
Merge trung bình
4 ngày 15 giờ
Pull request đã merge (30 ngày)
29

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của OpenMined/PySyft

Tất cả issue của OpenMined/PySyft

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.