Content
@
https://warpcast.com/~/channel/walletbeat
0 reply
0 recast
0 reaction
polymutex
@polymutex.eth
Very cool work from @niard. The software supply chain rabbit hole can go further! Stage 0๏ธโฃ: Open source [most wallets are here today] Stage 1๏ธโฃ: Reproducible builds [what /walletbeat will look for] Stage 2๏ธโฃ: Onchain build hashes Stage 3๏ธโฃ: Onchain TUF-like update availability warrant canaries
1 reply
1 recast
4 reactions
polymutex
@polymutex.eth
Stage 0๏ธโฃ solves for the bare minimum: Can users know what software they are entrusting their private keys to? Absolute must.
1 reply
0 recast
1 reaction
polymutex
@polymutex.eth
Stage 1๏ธโฃ (reproducible builds) ensure that you are actually running the code that you see on the wallet's open-source repository. Not some backdoored version. Otherwise, how do you even check? You'd need to build it from source, which most users don't (and shouldn't have to) know how.
2 replies
0 recast
2 reactions
polymutex
@polymutex.eth
Stage 2๏ธโฃ (onchain build hashes) ensures that the wallet software you are running matches the software that everyone ๐๐ก๐จ๐ is also running. Putting that onchain ensures all users see the same set of valid build hashes. Otherwise, you could be running some version that you've been tricked into thinking is an official build, but actually isn't.
2 replies
0 recast
1 reaction
polymutex
@polymutex.eth
Stage 3๏ธโฃ is about putting software ๐๐ฝ๐ฑ๐ฎ๐๐ฒ ๐ฎ๐๐ฎ๐ถ๐น๐ฎ๐ฏ๐ถ๐น๐ถ๐๐ information onchain. Otherwise, you could be running an official-but-ancient version that still has an unpatched vulnerability. Blockchains' censorship resistance properties means that by putting that update information onchain, it makes it impossible for patched releases to be censored away from you. TUF (The Update Framework) tries to get close to this and is used in other security-critical software packages like Tor Browser Bundle.
0 reply
0 recast
1 reaction
