repo/index-v2.json is a re-serialization, not the bytes that were served
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
Direzione di ricerca
Inizia leggendo btlog.py e verificando come produce repo/index-v2.json con json.dump. Confronta quell'output con l'index-v2.json servito e determina se il log debba conservare i byte serviti o registrare le impostazioni del serializzatore. Il lavoro è completato quando i destinatari possono riprodurre o verificare il file servito invece di fare affidamento su valori predefiniti di CPython dedotti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The JSON in this log isn't the JSON that was served. btlog.py parses it and writes it back with json.dump(..., indent=2), so repo/index-v2.json here is 1,055,505 bytes where the served file is 687,628.
Checked rather than assumed: parsing today's served index-v2.json with object_pairs_hook=OrderedDict and re-dumping at indent=2 reproduces the file in this repo byte-for-byte, sha256 144593b4ea4f2dd5…. So the log does hold today's index — just not the bytes anyone received.
That makes "People can then check that any file that they received from that F-Droid repository was a publicly released file" true only for someone running CPython who guesses the exact call. The separators, the escaping and the number formatting are json.dump defaults, declared nowhere in the log, and no other language reproduces them.
The .jar path is fine. Stripping to META-INF/ keeps the manifest digests, so a received entry.json can be checked against SHA-256-Digest without the payload being stored twice.
Storing the served bytes would close it. Failing that, recording which serializer produced these files would at least make them reproducible on purpose rather than by inference.
- Lingua principale
- Nessun dato sulla lingua
- Stelle
- 9
- Fork
- 3
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
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 guardianproject/binary_transparency_log
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
Tutte le issue di guardianproject/binary_transparency_log
Issue simili
-
security
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
ACK_WAITING HELP_WANTED UPDATE_CS
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
OWASP/CheatSheetSeries#2458 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 88/100
BasedHardware/omi#19702 ·
I maintainer di solito rispondono entro 1 giorno
-
Mend: dependency security vulnerability
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
ManageIQ/manageiq-ui-service#2208 ·
I maintainer di solito rispondono entro 1 giorno
-
comp/gateway P3 platform/telegram sweeper:risk-message-delivery sweeper:risk-session-state type/security
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
NousResearch/hermes-agent#127053 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno