6 ms·

Ask HN: Why doesn't Moxie sign Signal's releases?

24 points by rahrahrah 10y ago

It's good practice and obviously the guy is smart and knows this...

comboy 10y ago
If it's distributed using Google play store aren't apks signed by the developer anyway?
- diggan 10y ago
  Yeah, that is true. But Play is the middle man, not sure the end user could even verify the apks in any way...
  - cpeterso 10y ago
    On Amazon's Android app store, they repack the developer-provided APKs. Any developer APK signatures would be lost.
adricnet 10y ago
On Android or iOS or did you mean sign a source release ...? My guess is because of potential friction with reproducible building (for Android) and this for iOS: https://github.com/WhisperSystems/Signal-iOS/issues/1063 https://github.com/WhisperSystems/Signal-iOS/issues/1063 hth, adric
- rahrahrah 10y ago
  I meant both.
cjbprime 10y ago
Crypto experts don't follow "good practice" for the sake of it; they do things that would meaningfully improve security.
- rahrahrah 10y ago
  Are you suggesting that signing doesn't meaningfully improve security?
  - dogma1138 10y ago
    In many cases it doesn't.
    - rahrahrah 10y ago
      What about the case where I want to know if a piece of software being pushed into my phone has been approved by a specific person?
      - dogma1138 10y ago
        Packages from the google/Apple App Stores are signed
        rahrahrah 10y ago
        Interesting. But what's the set of public keys that it uses to decide whether or not an APK can be executed?
        dogma1138 10y ago
        By the ones they were issued by Apple/Google when they signed up for the dev accounts? If Apple/Google want to backdoor Signal they can do so, they can also backdoor your device in this case the signature check is irrelevant if you consider them an adversary. If you build your own using the source code then signing sourcecode effectively is near impossible since any change to it would require it to be resigned and even copy paste will likely to break the signature since now you are dependant on the encoding (ASCII/ANSI/UTF8/UTF6) and how your text editor handles spaces and tabs... If you sign source code files you also somewhat defy the purpose of open source which is having the code be inspectable and if you do build from open source repos you either trust the repo (github in this case) and the repo is your adversary you should either not take any code from it at all or inspect every line of it manually. Signing anything can be irrelevant or it can be critical it all depends on what are your threats and who are your adversaries. In this case if you trust Apple/Google not to backdoor applications or your device; signature beyond what is offered by their platform is irrelevant; in any case since the signature verification is on the device if they are your adversaries there is little you can do about it since they can backdoor the verification procedure or your device in it's entirety meaning that you can't trust it. If you trust Github and OWS you can trust the source code; you know that the source code hasn't been tampered with in transit because you pull it via HTTPS and you can review the source code and any pull and merge requests, if you don't trust Github or OWS you have to resort to manual code inspection or not use Signal at all; again signing the code offers little to no security and in effect can lead to back practices such as blind trust rather than manual verification.
hkt 10y ago
I don't know, but am I right in saying that he is generally in favour of ephemerality over verifiability? It'd seem odd to do this with definitely attributable works like software releases, but it is what would make most sense to me.
- rahrahrah 10y ago
  > he is generally in favour of ephemerality over verifiability That's not an absolute law in a vacuum. What does "ephemerality" even mean in the context of the question "how can I verify that the software that's being pushed to my phone comes from where it says it comes?"

24 points by rahrahrah 10y ago

It's good practice and obviously the guy is smart and knows this...

comboy 10y ago

If it's distributed using Google play store aren't apks signed by the developer anyway?

diggan 10y ago
Yeah, that is true. But Play is the middle man, not sure the end user could even verify the apks in any way...
- cpeterso 10y ago
  On Amazon's Android app store, they repack the developer-provided APKs. Any developer APK signatures would be lost.

adricnet 10y ago

On Android or iOS or did you mean sign a source release ...? My guess is because of potential friction with reproducible building (for Android) and this for iOS: https://github.com/WhisperSystems/Signal-iOS/issues/1063 https://github.com/WhisperSystems/Signal-iOS/issues/1063 hth, adric

rahrahrah 10y ago
I meant both.

cjbprime 10y ago

Crypto experts don't follow "good practice" for the sake of it; they do things that would meaningfully improve security.

rahrahrah 10y ago
Are you suggesting that signing doesn't meaningfully improve security?
- dogma1138 10y ago
  In many cases it doesn't.
  - rahrahrah 10y ago
    What about the case where I want to know if a piece of software being pushed into my phone has been approved by a specific person?
    - dogma1138 10y ago
      Packages from the google/Apple App Stores are signed
      - rahrahrah 10y ago
        Interesting. But what's the set of public keys that it uses to decide whether or not an APK can be executed?
        dogma1138 10y ago
        By the ones they were issued by Apple/Google when they signed up for the dev accounts? If Apple/Google want to backdoor Signal they can do so, they can also backdoor your device in this case the signature check is irrelevant if you consider them an adversary. If you build your own using the source code then signing sourcecode effectively is near impossible since any change to it would require it to be resigned and even copy paste will likely to break the signature since now you are dependant on the encoding (ASCII/ANSI/UTF8/UTF6) and how your text editor handles spaces and tabs... If you sign source code files you also somewhat defy the purpose of open source which is having the code be inspectable and if you do build from open source repos you either trust the repo (github in this case) and the repo is your adversary you should either not take any code from it at all or inspect every line of it manually. Signing anything can be irrelevant or it can be critical it all depends on what are your threats and who are your adversaries. In this case if you trust Apple/Google not to backdoor applications or your device; signature beyond what is offered by their platform is irrelevant; in any case since the signature verification is on the device if they are your adversaries there is little you can do about it since they can backdoor the verification procedure or your device in it's entirety meaning that you can't trust it. If you trust Github and OWS you can trust the source code; you know that the source code hasn't been tampered with in transit because you pull it via HTTPS and you can review the source code and any pull and merge requests, if you don't trust Github or OWS you have to resort to manual code inspection or not use Signal at all; again signing the code offers little to no security and in effect can lead to back practices such as blind trust rather than manual verification.

hkt 10y ago

I don't know, but am I right in saying that he is generally in favour of ephemerality over verifiability? It'd seem odd to do this with definitely attributable works like software releases, but it is what would make most sense to me.

rahrahrah 10y ago
> he is generally in favour of ephemerality over verifiability That's not an absolute law in a vacuum. What does "ephemerality" even mean in the context of the question "how can I verify that the software that's being pushed to my phone comes from where it says it comes?"