8 ms·

The main problem with projects like these is that I don't know (without manually checking myself) whether they are actually tracking the Signal source code effe

The main problem with projects like these is that I don't know (without manually checking myself) whether they are actually tracking the Signal source code effectively. Building Signal isn't exactly straightforward (just due to Android/iOS crud). We need something like build attestation from reproducible builds to be extendable to slightly different source codes. Other than that, love it. Now to add iOS backups and cross platform imports... And strip out gifs (or at least make them disabled for me). And force by default unknown callers to go via a relay... So many wishlist items which are probably wasted effort because they will bit rot without being accepted by Signal.

asddubs 6y ago
does signal not accept pull requests or something? currently there's two signal forks on the frontpage, would be much better to upstream the effort if that's viable
- kuschku 6y ago
  Signal accepts pull requests theoretically, they just usually reject everything.
  - asddubs 6y ago
    i looked at the history and it seems they just close them even when they merge them, and then merge them via their own commits. but you can see them accepting stuff in the comments of the closed pull requests
    - swiley 6y ago
      That's extremely obnoxious, why?
      - lsaferite 6y ago
        Sounds like they don't use github to manage the codebase.
        jwieczorek 6y ago
        But Git is a distributed VCS. They could just as well cleanly merge pull requests into the main branch as hosted on GitHub and then merge GitHub's main branch into their canonical system's main branch.
        eat_veggies 6y ago
        Git is a distributed VCS, so if another tool works better for their workflow, then they can use that instead of GitHub
        deleted 6y ago
        [deleted]
        lsaferite 6y ago
        I just randomly picked a contribution from an external party. The commit that made it into mainline has an author set to the person that contributed the code originally and a committer set to one of the 'signal.org' members. I'm confused why people would have a problem with how they chose to manage their code if the original attribution is not lost in the process. I'm fairly certain the Linux codebase is managed similarly. Edit: adding links I forgot https://github.com/signalapp/Signal-Android/pull/10219 https://github.com/signalapp/Signal-Android/pull/10219 https://github.com/signalapp/Signal-Android/commit/dda51bf36743be165517bb0cb1e45d02c4381221 https://github.com/signalapp/Signal-Android/commit/dda51bf36...
      - asddubs 6y ago
        I don't know but I can speculate a couple reasons why they might: -They might not want people who aren't officially affiliated to get "contributor" badges on github, so people don't get confused thinking they speak for the project when they participate in discussions -github may not be their primary way of managing their source, so pull requests have to be transferred to their internal system first before being released on github -better control over what gets into what version without having to micromanage when to accept pull requests
        _dark_matter_ 6y ago
        Also helps with ownership. They have to maintain the thing, and it's easier to do when the person who committed it is a co-worker you can get a hold of.
      - Benjamin_Dobell 6y ago
        Github still doesn't provide a means to mark a pull request as merged if you've locally rebased and pushed. https://github.com/isaacs/github/issues/2 https://github.com/isaacs/github/issues/2 https://github.com/isaacs/github/issues/548 https://github.com/isaacs/github/issues/548 This is what's happening with Signal's PRs. Here is an example: PR: https://github.com/signalapp/Signal-Android/pull/10266/commits https://github.com/signalapp/Signal-Android/pull/10266/commi... Commit in PR: https://github.com/signalapp/Signal-Android/pull/10266/commits/a2521518e53c186f4989042b21e8589f37cc8664 https://github.com/signalapp/Signal-Android/pull/10266/commi... Rebased and pushed commit: https://github.com/signalapp/Signal-Android/commit/6df839612dd560f685c30ce581c6b2ce559577fc https://github.com/signalapp/Signal-Android/commit/6df839612... Note that they have different commit references. Thus Github does not recognise this as a merge, and there's no way to explicitly tell Github that you did merge it.
        greysonp 6y ago
        Hi, there, Signal Android developer here. This is correct. Our process is that we work in a pre-release branch, and then merge that to master when we make a release. So GitHub doesn't usually recognize it as a merge, but we always keep the original authorship and whatnot.
        scns 6y ago
        Hey there, would be great if you reference these merges in the issues so it would be visible to everyone (and especially the devs who put in the work) that the code is used.
        jakear 6y ago
        Can’t you just change the merge target to the prerelease branch?
        Benjamin_Dobell 6y ago
        Maintainers can't. Only the PR owner can. For that to work the PR owner has to know which branch to target (assuming it's public). Unless the PR creator somehow knows which release their PR is going to be included in, with a guarantee it'll be merged in said release, then it's just not possible for the PR creator to target the correct branch.
- lucideer 6y ago
  As far as I've seen, Signal don't really accept outside contributions. I'm not sure if it's policy, or just a culture thing. They may have accepted some in the past, but I've never seen it, and I've seen a lot of PRs closed unmerged.
  - asddubs 6y ago
    checked the last 10 closed pull requests -1 closed by the author realizing it had already been done -2 closed saying they were going to fix it differently -1 closed saying they took some code from the commit and fixed part of it differently -6 merged seems quite reasonable to me (albeit this is only from the newest 10 closed pr obviously)
    - lucideer 6y ago
      Your 2nd & 3rd examples I've seen a fair bit of, but I've mostly seen them closed due to the feature not lining up with Signal devs' intent. Glad to hear this seems to be changing; 6/10 is pretty good.
- sschueller 6y ago
  They are also not interested in putting signal on f-droid. Quite off putting to me.
Strongylodon 6y ago
>The main problem with projects like these is that I don't know (without manually checking myself) whether they are actually tracking the Signal source code effectively. That's my main complaint with Signal - lots of widgets. More code to audit and keep an eye on. More users is good, but stickers and stuff.. meh. Maybe teach zoomers how to use emoticons ;-)
- asddubs 6y ago
  people really do like those stickers though. You can just not use them, I find them annoying too, but I'd rather signal have them so people who want them don't have a reason not to use Signal
- angry_octet 6y ago
  I understand where Moxie it coming from: user friendlyness (and candy) increases the user base in a demonstrable way. At the same time, adding code like this pretty clearly increases the attack surface unnecessarily. So there is a tradeoff they are making for everyone. I would much rather be able to disable that additional state space, even if I can't strip it out of the build entirely. I also find it a bit crazy that the 'desktop' app is Electron, and they don't hint anywhere what a house of cards Electron is. I wouldn't run it except inside a VM, and even then I would have to accept that all the messages could be extracted remotely. They give no indication of their compliance with best practices (e.g. https://labs.bishopfox.com/tech-blog/reasonably-secure-electron https://labs.bishopfox.com/tech-blog/reasonably-secure-elect...) with is disturbing.
  - Strongylodon 6y ago
    Yeah, that's one reason I prefer verbal convos. Electron aside, how many people even keep their phone on the latest version? There's all sorts of ways to slip up with Signal, though now that I'm not violating COPPA by posting on the boards, I don't see a need to make a literal list of all of them.
antpls 6y ago
Signal has reproducible build for Android : https://github.com/signalapp/Signal-Android/blob/master/reproducible-builds/README.md https://github.com/signalapp/Signal-Android/blob/master/repr... I didn't try, but I don't see how it could be more straightforward than just launching a docker container
- angry_octet 6y ago
  The derived projects need this, but in a way that attests to the currentness of the source code they are derived from, i.e. as a patch against the latest Signal release.

asddubs 6y ago

does signal not accept pull requests or something? currently there's two signal forks on the frontpage, would be much better to upstream the effort if that's viable

kuschku 6y ago
Signal accepts pull requests theoretically, they just usually reject everything.
- asddubs 6y ago
  i looked at the history and it seems they just close them even when they merge them, and then merge them via their own commits. but you can see them accepting stuff in the comments of the closed pull requests
  - swiley 6y ago
    That's extremely obnoxious, why?
    - lsaferite 6y ago
      Sounds like they don't use github to manage the codebase.
      - jwieczorek 6y ago
        But Git is a distributed VCS. They could just as well cleanly merge pull requests into the main branch as hosted on GitHub and then merge GitHub's main branch into their canonical system's main branch.
        eat_veggies 6y ago
        Git is a distributed VCS, so if another tool works better for their workflow, then they can use that instead of GitHub
        deleted 6y ago
        [deleted]
        lsaferite 6y ago
        I just randomly picked a contribution from an external party. The commit that made it into mainline has an author set to the person that contributed the code originally and a committer set to one of the 'signal.org' members. I'm confused why people would have a problem with how they chose to manage their code if the original attribution is not lost in the process. I'm fairly certain the Linux codebase is managed similarly. Edit: adding links I forgot https://github.com/signalapp/Signal-Android/pull/10219 https://github.com/signalapp/Signal-Android/pull/10219 https://github.com/signalapp/Signal-Android/commit/dda51bf36743be165517bb0cb1e45d02c4381221 https://github.com/signalapp/Signal-Android/commit/dda51bf36...
    - asddubs 6y ago
      I don't know but I can speculate a couple reasons why they might: -They might not want people who aren't officially affiliated to get "contributor" badges on github, so people don't get confused thinking they speak for the project when they participate in discussions -github may not be their primary way of managing their source, so pull requests have to be transferred to their internal system first before being released on github -better control over what gets into what version without having to micromanage when to accept pull requests
      - _dark_matter_ 6y ago
        Also helps with ownership. They have to maintain the thing, and it's easier to do when the person who committed it is a co-worker you can get a hold of.
    - Benjamin_Dobell 6y ago
      Github still doesn't provide a means to mark a pull request as merged if you've locally rebased and pushed. https://github.com/isaacs/github/issues/2 https://github.com/isaacs/github/issues/2 https://github.com/isaacs/github/issues/548 https://github.com/isaacs/github/issues/548 This is what's happening with Signal's PRs. Here is an example: PR: https://github.com/signalapp/Signal-Android/pull/10266/commits https://github.com/signalapp/Signal-Android/pull/10266/commi... Commit in PR: https://github.com/signalapp/Signal-Android/pull/10266/commits/a2521518e53c186f4989042b21e8589f37cc8664 https://github.com/signalapp/Signal-Android/pull/10266/commi... Rebased and pushed commit: https://github.com/signalapp/Signal-Android/commit/6df839612dd560f685c30ce581c6b2ce559577fc https://github.com/signalapp/Signal-Android/commit/6df839612... Note that they have different commit references. Thus Github does not recognise this as a merge, and there's no way to explicitly tell Github that you did merge it.
      - greysonp 6y ago
        Hi, there, Signal Android developer here. This is correct. Our process is that we work in a pre-release branch, and then merge that to master when we make a release. So GitHub doesn't usually recognize it as a merge, but we always keep the original authorship and whatnot.
        scns 6y ago
        Hey there, would be great if you reference these merges in the issues so it would be visible to everyone (and especially the devs who put in the work) that the code is used.
        jakear 6y ago
        Can’t you just change the merge target to the prerelease branch?
        Benjamin_Dobell 6y ago
        Maintainers can't. Only the PR owner can. For that to work the PR owner has to know which branch to target (assuming it's public). Unless the PR creator somehow knows which release their PR is going to be included in, with a guarantee it'll be merged in said release, then it's just not possible for the PR creator to target the correct branch.
lucideer 6y ago
As far as I've seen, Signal don't really accept outside contributions. I'm not sure if it's policy, or just a culture thing. They may have accepted some in the past, but I've never seen it, and I've seen a lot of PRs closed unmerged.
- asddubs 6y ago
  checked the last 10 closed pull requests -1 closed by the author realizing it had already been done -2 closed saying they were going to fix it differently -1 closed saying they took some code from the commit and fixed part of it differently -6 merged seems quite reasonable to me (albeit this is only from the newest 10 closed pr obviously)
  - lucideer 6y ago
    Your 2nd & 3rd examples I've seen a fair bit of, but I've mostly seen them closed due to the feature not lining up with Signal devs' intent. Glad to hear this seems to be changing; 6/10 is pretty good.
sschueller 6y ago
They are also not interested in putting signal on f-droid. Quite off putting to me.

Strongylodon 6y ago

>The main problem with projects like these is that I don't know (without manually checking myself) whether they are actually tracking the Signal source code effectively. That's my main complaint with Signal - lots of widgets. More code to audit and keep an eye on. More users is good, but stickers and stuff.. meh. Maybe teach zoomers how to use emoticons ;-)

asddubs 6y ago
people really do like those stickers though. You can just not use them, I find them annoying too, but I'd rather signal have them so people who want them don't have a reason not to use Signal
angry_octet 6y ago
I understand where Moxie it coming from: user friendlyness (and candy) increases the user base in a demonstrable way. At the same time, adding code like this pretty clearly increases the attack surface unnecessarily. So there is a tradeoff they are making for everyone. I would much rather be able to disable that additional state space, even if I can't strip it out of the build entirely. I also find it a bit crazy that the 'desktop' app is Electron, and they don't hint anywhere what a house of cards Electron is. I wouldn't run it except inside a VM, and even then I would have to accept that all the messages could be extracted remotely. They give no indication of their compliance with best practices (e.g. https://labs.bishopfox.com/tech-blog/reasonably-secure-electron https://labs.bishopfox.com/tech-blog/reasonably-secure-elect...) with is disturbing.
- Strongylodon 6y ago
  Yeah, that's one reason I prefer verbal convos. Electron aside, how many people even keep their phone on the latest version? There's all sorts of ways to slip up with Signal, though now that I'm not violating COPPA by posting on the boards, I don't see a need to make a literal list of all of them.

antpls 6y ago

Signal has reproducible build for Android : https://github.com/signalapp/Signal-Android/blob/master/reproducible-builds/README.md https://github.com/signalapp/Signal-Android/blob/master/repr... I didn't try, but I don't see how it could be more straightforward than just launching a docker container

angry_octet 6y ago
The derived projects need this, but in a way that attests to the currentness of the source code they are derived from, i.e. as a patch against the latest Signal release.