Nice, if only they could be so kind after all this time to provide instructions on how to run it. I don't get why they have been dancing their reputation around Hacker News this way by not releasing sources until there were a bunch of front page posts about it.
Signal Server code on GitHub is up to date again
21–30 of 206 posts
Re: Signal Server code on GitHub is up to date again
#22Is there any mechanism to validate that the code running on Signal's servers is the same as on Github?
Yes, via SGX remote attestation.
Re: Signal Server code on GitHub is up to date again
#23So it just took close to a year to dump thousands of private commits into the public repo! Is there an official response as to why they stopped sharing the code for so long and more importantly, why they started sharing it publicly again? Who gains what with the publication now? And seriously, why is it even relevant anymore?
Re: Signal Server code on GitHub is up to date again
#24Earlier quoted context omitted.
SGX enclaves can attest to the code they are running, so you don't exactly need to take Signal's word on faith.
Except SGX enclaves are horribly broken.
Like, does an SGX enclave attest that meltdown is patched in microcode? That's one way to pull the keys out.
The recentish work to get read write access to some Intel CPU's microcode can probably break SGX too. I wouldn't be surprised if the ME code execution flaws could be used that way too.
Re: Signal Server code on GitHub is up to date again
#25So it just took close to a year to dump thousands of private commits into the public repo! Is there an official response as to why they stopped sharing the code for so long and more importantly, why they started sharing it publicly again? Who gains what with the publication now? And seriously, why is it even relevant anymore?
I think it's proof that security (and privacy) doesn't matter. So it is very relevant. (As if telegram as competitor isn't enough proof.)
The entirety of the signal "stack" depends on the SGX enclave. The fact that no one, in all time, has bothered to notice that the running code is different than the published code, is telling.
There's actually a newer SGX exploit, and related mitigation, that came to light at about the same time when they released their discovery protocol. Those mitigations were never backported to the base signal functionality. That no one audited and complained about this says quite a lot.
I've not looked at this code dump but perhaps the newer fixes finally made their way in. Or have been there all along.
Re: Signal Server code on GitHub is up to date again
#26Is there any mechanism to validate that the code running on Signal's servers is the same as on Github?
[deleted]
Re: Signal Server code on GitHub is up to date again
#27I read some speculation that the delay was to keep this objectionable crypto payment development under wraps until they were ready to launch.
The devious aspect to this is that nobody knew the development was happening so we couldn’t invest even if we wanted to.
It was kept under wraps for a grade A pump.
Re: Signal Server code on GitHub is up to date again
#28If you have a PhD you might be able to verify from the client-side it does not matter. If you are into blockchain there might be another (but very expensive) way to show a system can be trusted.
For normal development, I am advocating an always auditable runtime that runs only public source code by design:- https://observablehq.com/@endpointservices/serverless-cells
Before sending data to a URL, you can look up the source code first, as the URL encodes the source location.
There is always the risk I decided to embed a trojan in the runtime (despite it being open source). However, if I am a service provider for 100k customers built upon the idea of a transparent cloud, then compromising the trust of one customer would cause loss of business across all customers. Thus, from a game-theoretic perspective, our incentives should align.
I think running public source code, which does not preclude injecting secrets and keeping data private, is something that normal development teams can do. No PhDs necessary, just normal development.
Follow me on https://twitter.com/tomlarkworthy if you want to see this different way of approaching privacy: always auditable source available server-side implementations. You can trust services implemented this way are safe, because you can always see how they process data. Even if you cannot be bothered to audit their source, the sheer fact that someone can, inoculates you against bad faith implementations.
I am building a transparent cloud. Everything is encoded in public notebooks and runs open-source https://observablehq.com/collection/@endpointservices/servic... There are other benefits, like being able to fork my implementations and customize, but primarily I am doing this for trust through transparency reasons.
Re: Signal Server code on GitHub is up to date again
#29If you have a PhD you might be able to verify from the client-side it does not matter. If you are into blockchain there might be another (but very expensive) way to show a system can be trusted. For normal development, I am advocating an always auditable runtime that runs only public source code by design:- https://observablehq.com/@endpointservices/serverless-cells Before sending data to a URL, you can look up the s…
How do you prove the endpoint is running the code to which it links?
Re: Signal Server code on GitHub is up to date again
#30"Signal Server code on GitHub is up to date again - now with a freshly added shitcoin!"
The addition of micropayments to Signal is discussed separately at https://news.ycombinator.com/item?id=26724237