This had been sitting on my hdd gathering dust so thought would publish it:
Problem
We have binaries (Desktop and APK’s) that have no distribution channels and therefore have no managed upgrades. Status should be able to independently inform the user that new binaries are available and give the user a means to voluntarily upgrade.
Goals:
- Friends don’t let friends run untrusted binaries.
- Multiple parties sign builds, providing some assurance that
- the binaries and tool chain were not tampered with
- that the same source code was used.
- Checking for updates should be ‘passive’ in terms of requests.
- Updating should be voluntary.
- A user should have ready access to a tool than can (build and) check binaries against the respective hash of binary
Solution
Status should check an on-chain contract that anybody can publish to (by locking, maybe even staking SNT, although slashing conditions sounds hard), to be read by anyone.
The contract contains a data structure that contains something like:
(this is pseudo code, I haven’t written Solidity in years, don’t hurt me!)
struct Signature {
bytes32 r;
bytes32 s;
uint8 v;
bytes32 hash;
address signer;
uint256 stake;
bool upvote; // (optional?) approve or disprove a build
}
struct Build {
// semver.org
uint16 major;
uint16 minor;
uint16 patch;
bytes32 ext;
// Hashes & Urls
string gitremote;
bytes20 sha1git; // git commit hash, TODO: pointer into mango?
bytes32 sha256bin; // binary hash
string[] urls; // ipfs/swarm hash and/or http urls
Signature[] signatures; // Build must have at least 1 signature to exist.
}
struct Platform {
Build[] builds; // prepend only? linked list or mapping more suitable?
}
// oh god I have no idea what I'm doing
mapping(string => Platform); // Android, iOS, macOS, Win, Nix, etc.
mapping(mapping(bytes20 => string) => Build) CommitPlatform; // Lookup Build from Git Commit and Platform
mapping(bytes32 => Build) Binary; // Lookup Build from Binary hash
I imagine the client will be initially distributed with a list of signatories, from there it could populate it’s list from mutual contacts (might not be practical)
The idea is that a client would:
- Query the contract for the current platform.
- Enumerate & Display a list of published builds that is ordered & weighted by:
- semantic version number.
- Most signatures from client’s trusted list.
- Most signatures in relation to all enumerated Builds
- Ignore all builds that have less than N signatures.
- M amount SNT ‘staked’ (again how to slash?)
- favouring user’s preferred choice of binaries ipfs/swarm/http
- filter on git remote.
- Notify user when new candidate is available.
- Allow the user to view the list and optionally choose which version to install or ignore, while offering the top-most entry as most likely candidate.
A tool that checks binaries, should be able to se the same contract to look up a Build by Platform, by Git Commit or by Binary Hash, and offer to publish a signature. It should be used in the e2e build process.
Perhaps signatures can offer an ‘upvote’ or ‘downvote’ to distinguish between expressly malicious builds and apathy toward a build.
wdyt:
@iurimatias @arnetheduck @ricardo3 @rramos @igor @pedro @adam @cammellos @oskarth @petty
