s2c2f icon indicating copy to clipboard operation
s2c2f copied to clipboard

Ensuring that binary patches, when reconstituted, are the same as the original

Open david-a-wheeler opened this issue 1 year ago • 4 comments

Per discussion 2023-02-28, S2C2F should ensure that expansion of binary patches is equivalent to what would be downloaded from scratch.

david-a-wheeler avatar Feb 28 '23 21:02 david-a-wheeler

These are really "binary diffs" to recreate a full update.

david-a-wheeler avatar Mar 14 '23 19:03 david-a-wheeler

Basically, the results should be the same if:

  1. You don't have package version 1.0 installed, and you download & install version 1.1
  2. You have package version 1.0 installed, you uninstall it, and download & install version 1.1
  3. You have package version 1.0 installed, and you install a "binary patch" on version 1.0 to produce version 1.1

If the "binary patch" (option 3) produces a different result, it can be hard to figure out what happened. It can be a security vulnerability, since it's likely only the new version was reviewed (not the binary patch).

david-a-wheeler avatar Mar 14 '23 19:03 david-a-wheeler

One solution: the receiving client could download a diff (patch file), combine that with the "old" version to create the "full new version", and then verify that the result is the same as the full install (e.g., with a cryptographic hash). Not every client would need to do this, it could be just a test client as part of a test case, and would eliminate the concern about storage space used up in most clients. That approach would ensure that all are getting the same thing.

david-a-wheeler avatar Jun 06 '23 19:06 david-a-wheeler

There may be other solutions, but having one solution is good :-).

david-a-wheeler avatar Jun 06 '23 19:06 david-a-wheeler