IJHack / QtPass / 35616083387

93%

Build Type

push

github

Committed by web-flow

Commit Message

GpgIdGeneration: detect conflicting equal generations (#1878)

* GpgIdGeneration: the same generation is the same list only if the bytes are

The record remembered the generation alone, so an incoming signed list of
the remembered generation was accepted whatever its bytes. Two devices both
writing 19 from 18 is Git's conflict; the device that wrote or accepted one
of the two then met the other as generation 19 and took it for its own, and
so it would a swap between two authentic lists of one generation.

The record keeps a SHA-256 of the exact bytes next to the generation.
accept() at the remembered generation compares: other bytes are
Verdict::Conflict, with a message that names both readings (racing saves,
a swap) and the way through, checking the recipients and saving; a record
without a digest (a reservation whose write was not recorded) takes the
bytes it sees. reserveNext() clears the digest with the new number, and the
writers record their bytes right after the QSaveFile commit
(recordWritten(), not fatal when it fails: the generation is recorded, and
the first read digests it). Generation 0 is not pinned: pass writes a
headerless list for every change, also through QtPass's pass backend, so
other bytes there are the normal course of a store kept with pass.
recipientsForEditing() treats Conflict as Rejected: nothing preselected.

The record itself is a JSON file of QtPass's own now
(QtPass-gpgid-generations.json, where QSettings would put an ini of the
organisation, so the tests' redirection applies), read afresh under a lock
file for every transaction and written whole with QSaveFile. QSettings
cached the file per process and re-read it on size or mtime alone, which a
digest swap or a same-width generation bump does not change, so a second
process's write could be read stale even under the lock; on Windows the
default format is the registry, whose "file name" the lock would have taken
for a folder. The format-error stickiness and the failed-s... (continued)

Coverage Stats

144 of 162 new or added lines in 3 files covered. (88.89%)

18 existing lines in 3 files now uncovered.

7376 of 9333 relevant lines covered (79.03%)

80.39 hits per line