4 ms·

interesting that it's 'veracity and distribution', not just distribution. makes sense that you need to hash the file, but I wonder about various higher-level wa

interesting that it's 'veracity and distribution', not just distribution. makes sense that you need to hash the file, but I wonder about various higher-level ways to decentralize CI while maintaining a cheaply checkable 'affirmation' for example, can you cheaply verify repeatable builds? (on a phone even?). can you do intense linting for privacy violations like phone-home, then publish a 'lint payload' that's cheaply verifiable against the built binary? feels like if f-droid leads here, commercial software will have to adopt their tools to maintain their position of trust (also huge fan of f-droid project, I donate, I think it gets more important every year)

mhitza 5y ago
Somehow related take. When I was still interested in blockchains back in 2018 I was thinking that instead of proof of work, wouldn't it be nice to have a distributed CI where you run your builds & tests on end-user machines, it computes a hash of the resulting artifact. Which is validated by multiple nodes that run the same job for validation (then split the PoW fees among themselves). It's not an easy problem to solve of course, and didn't go too deep into what TPM (Trusted Platform Module) can do, but I think you would need an isolation unit from the kernel/OS to allow running untrusted code, and prevent tampering. There's definitely a fine line between such a functionality and spyware that would need serious safeguards.
- yjftsjthsd-h 5y ago
  Just make it fully isolated with WASM or whatever, and then port the necessary compilers to cross-compile back to whatever native platform you want to use the outputs binaries on. Simple! (Not easy, but conceptually simple and probably doable.) The big problem that I can't see an obvious solution for is proving that a given output corresponds to the work requested. I guess you can just run it on enough machines that you hope they're not collaborating?
  - mhitza 5y ago
    I think isolation itself is the harder problem, as you don't want to have the untrusted code interface with your primary OS, nor the computer owner tamper with the isolated environment. > I guess you can just run it on enough machines that you hope they're not collaborating? Right validation through numbers. Still susceptible to a 51% attack, if I recall correctly what Sybil attacks are about. This type of proof of work gives you a way to find collusion post fact. For example if your last commit on a PR (which triggers a decentralized CI), is the same commit on which you base you distribution build (assuming reproducible builds, same output), that's run on your fully trusted system, you would find out if jobs were faked.
yjftsjthsd-h 5y ago
I'm not sure if this is exactly what you want, but https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/ is a thing
- awinter-py 5y ago
  ah, thanks for link. From this it seems like verification builds require the same amount of work as the original -- you can't save work by delegating to untrusted CI.
  - eighthave 5y ago

mhitza 5y ago

Somehow related take. When I was still interested in blockchains back in 2018 I was thinking that instead of proof of work, wouldn't it be nice to have a distributed CI where you run your builds & tests on end-user machines, it computes a hash of the resulting artifact. Which is validated by multiple nodes that run the same job for validation (then split the PoW fees among themselves). It's not an easy problem to solve of course, and didn't go too deep into what TPM (Trusted Platform Module) can do, but I think you would need an isolation unit from the kernel/OS to allow running untrusted code, and prevent tampering. There's definitely a fine line between such a functionality and spyware that would need serious safeguards.

yjftsjthsd-h 5y ago
Just make it fully isolated with WASM or whatever, and then port the necessary compilers to cross-compile back to whatever native platform you want to use the outputs binaries on. Simple! (Not easy, but conceptually simple and probably doable.) The big problem that I can't see an obvious solution for is proving that a given output corresponds to the work requested. I guess you can just run it on enough machines that you hope they're not collaborating?
- mhitza 5y ago
  I think isolation itself is the harder problem, as you don't want to have the untrusted code interface with your primary OS, nor the computer owner tamper with the isolated environment. > I guess you can just run it on enough machines that you hope they're not collaborating? Right validation through numbers. Still susceptible to a 51% attack, if I recall correctly what Sybil attacks are about. This type of proof of work gives you a way to find collusion post fact. For example if your last commit on a PR (which triggers a decentralized CI), is the same commit on which you base you distribution build (assuming reproducible builds, same output), that's run on your fully trusted system, you would find out if jobs were faked.

yjftsjthsd-h 5y ago

I'm not sure if this is exactly what you want, but https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/ is a thing

awinter-py 5y ago
ah, thanks for link. From this it seems like verification builds require the same amount of work as the original -- you can't save work by delegating to untrusted CI.
- eighthave 5y ago