Signal-Server code not public since April 22 2020 (Last commit on codebase) ? #11101
Comments
tlaurion
changed the title
|
There is a lot of discussion going on this topic in both the community forum and Reddit for months now. To name a few:
I think the Signal team should at least tell why the server repo is not being updated at the moment. EDIT 2021-04-06: To be clear: using Signal is safe! Even if a malicious server was used, your messages are safe. This is due to the fact that the client uses end-to-end encryption with minimal metadata leakage. This discussion isn't necessarily about the security/privacy Signal gives, but rather Signal to advertise their server as open-source while it's not. EDIT 2021-04-07: Server source has been updated! signalapp/Signal-Server@365ad3a. An explanation on why it took so long to release the source would be nice tho. |
|
@moxie-signal @moxie0 @acton-signal Can you guys speak up? It's disturbing for all those who contributed through donations to know that you do not even care to give an explanation. |
|
Backlink to another German IT news platform: https://www.golem.de/news/crypto-messenger-signal-server-nicht-mehr-open-source-2104-155376.html |
|
Any explanation? Any? This will definitely backslash in media... |
|
I took this for granted, thought this was what Signal stood for. So please give us an update, why the server sees so few code updates. |
Unless, of course, you are in a region that needs an IME to input text, at which point there's a GLARING HUGE SECURITY HOLE A MILE WIDE that's only "documented" deeply inside the docs in passing. |
I am assuming you're referring to Input Method Editors? I don't see how an IME relates to message leakage if a malicious Signal server was used. |
That's not the point. IME can intercept in any case. See https://cybersecurity.springeropen.com/articles/10.1186/s42400-018-0007-6 |
|
But that's an attack that happens on the client, not on the server (what we're discussing here), and is not Signal-specific (malicious IMEs could affect all apps). That was my point. |
Correct. Still, such a side note doesn't hurt ;) |
Fair enough :) |
Apparently I forgot to quote the sentence that specifically mentions clients. To wit:
Only … it turns out I didn't. At all. It's all in the unedited original comment. In which I commented on a claim that "using Signal is perfectly safe!" A claim that has caused more than one activist in Hong Kong or mainland China to get disappeared, very likely.
Even better than a side note would be a MASSIVE warning about this on the SignalApp front page instead of the marketing-blurbesque:
The server no longer being open source is the least of Signal's problems in terms of getting blood on its hands. |
|
Does anyone know how the communication between the client on the smartphone and the desktop version works ? Is this kind of traffic routed through the servers? |
I would love to see some proof then that Signal is sending lots of metadata or using malicious IMEs |
|
There is no reason to not update the Github-Repo and be transparent about why this has not happend yet, if you do not want to lose the trust of your users. |
|
My guess is:
|
It's not that SIGNAL is being malicious here. It's that Signal, by virtue of hooking into the system inputs (instead of supplying its own like many bank apps do), is letting third party apps get inputs before it does. You understand how IMEs work, right? If the IME gets the data before Signal even sees it, the security is utter vapour. And instead of warning about this being the case, or—better—supplying a secure IME as part of the package, we get market-speak: "Privacy isn’t an optional mode — it’s just the way that Signal works. Every message, every call, every time." And people get disappeared in China and in other domains as a result, thinking they're secured when they're not. |
|
Wouldn't it be better to not bump the thread for multiple times, at least, not multiple times in one day, I subscribed to issue to get notified by progress of the issue but strangely, today there were too many notification replies in the inbox, so let's keep calm a little bit :) |
|
@selimrecep reason could be due to some media which reported about this issue: https://www.golem.de/news/crypto-messenger-signal-server-nicht-mehr-open-source-2104-155376.html |
|
@moxie-signal @moxie0 @acton-signal maybe you cannot comment directly on it. So why not discuss instead the potentials of what security impact a compromised server has (maybe this already exists somewhere) while the clients stay auditable. |
Or simply the usual secret FISA-court order. Did anyone see their warrant canary? |
|
They don't have one… https://www.reddit.com/r/signal/comments/d751e3/warrant_canary/ And it's a strange new argument I've heard there, how they defend their position. I guess it's totally debatable and well… other companies do that, too. |
|
Android Police just published a post as well: |
|
Guys the server code is now available signalapp/Signal-Server@365ad3a |
|
How did this happen? |
Very bad management decision at a very bad time, where opportunities would have been graspable. |
The right step in the right direction, finally. But @jon-signal or @moxie0 might be able to give us an explanation on why the sources were kept closed for so long? And why they keep a secret repo at all? It's what most would expect from an open source project, especially a security driven one like Signal. |
|
@casaper |
|
@UserX404 I can't speak for others, but my annoyance/concern at Signal for being dead silent on license violations/possible security issues far outweighs my annoyance about getting another email notification from someone here asking for a response. |
|
@moxie-signal @moxie0 @TheBlueMatt @geogriff-signal @acton-signal @ehrenkret-signal @noboomu-signal @posix4e @paride @FredericJacobs @mkroman Users and sponsors deserve a word on this topic. |
|
Okay, I wanna suggest to stop pinging the devs. They have been pinged multiple times and have probably seen it by now (because well, they updated the repo and the media refers to this issue). Further bumping the topic has no use (unless you like a crowded mailbox). |
I totally disagree with @activaireadmin 's mass pinging to just anyone at reach though, but that is not what I did. |
|
Hey. Time for justification, Devs. I'm sorry but millions of users are trusting you like gods. |
|
I believe repeating same thing over and over again doesn't help to spread the word, it is just, annoying... If there is a reply that you agree with, just click on "thumbs up" emoji instead of killing inboxes... Half of the replies just repeat same argument, there is a reason emojis exist... :) |
|
Modified OP accordingly. |
|
Modified comment (linked in several media articles) accordingly. |
|
They can't comment, the app is compromised. It would be illegal for them to acknowledge the warrent. |
|
Many of you probably read about the payment feature which was announced recently (see https://www.wired.com/story/signal-mobilecoin-payments-messaging-cryptocurrency/) and the server code became public again. The first commit after the depublication in april 2020 of the source code is signalapp/Signal-Server@95f0ce1 introducing parts of the payment feature. I suspect the cause of the depublication was that they wanted to keep the payment feature secret until publicly announced. It would be better to get some official statement on this issues by the devs, though. And hopefully there will be no further decisions to depublish the server code again in the future. |
|
No they are under a gag order. You can't see it online in the US court
system but if you go in person and search their entity ID they are under a
gag order.
They are not legally allowed to tell you this. So acknowledging why there
were no updates when they were installing malicious code would be against
us sanctions and the punishable by imprisonment.
Signal is compromised.
There are safe versions to use, until of course the cryptography itself
becomes broken. Stay at those versions or find another messaging app that's
not in control by the US government.
On Wed, Apr 7, 2021, 9:18 AM Benedikt Wildenhain ***@***.***> wrote:
Many of you probably read about the payment feature which was announced
recently (see
https://www.wired.com/story/signal-mobilecoin-payments-messaging-cryptocurrency/)
and the server code became public again. The first commit after the
depublication in april 2020 of the source code is signalapp/Signal-Server@
95f0ce1
<signalapp/Signal-Server@95f0ce1>
introducing parts of the payment feature. I suspect the cause of the
depublication was that they wanted to keep the payment feature secret until
publicly announced. It would be better to get some official statement on
this issues by the devs, though. And hopefully there will be no further
decisions to depublish the server code again in the future.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11101 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKEIUFCVLM5ILUODEDC57Y3THSHU7ANCNFSM4ZEGNRCA>
.
As a message to the people pressing the thumbs down button, if you connect signal to a private server and run Wireshark it will send 1.48 KB in the announcement message. If you connect to the signal server it will send 8.96 KB in the announcement message. The reason why it's doing this is because it's sending your private keys. Whether you like or dislike this feature doesn't really matter. We're only concerned with the security aspect of the issue.
|
|
@Motophan I would like to ask you to stop telling Signal is compromised while it's not. The client is open source and again, even with a compromised server, the messages can't be read and no additional metadata is stored. |
I have updated my comments. Please run Wireshark on your instance and compare the difference between the signal server and a private server. Where there should be none. |
Have you compared the data with your private key? |
It's sent over TLS with a certificate authority so decryption is not possible at this time. Now as far as your other comments on how signal is not compromised you understand that the client has to store decryption keys somewhere. Unless of course you enter the decryption keys every time you want to read a message and then they're forced freed from memory. So be it that they store it on disc, or in signals case store it in memory. The way the Android system works is an application has rights and permissions to view its own memory code, which is pretty standard for most computing systems. Those keys are likely being sent in the announcement message when you decrypt by entering the passcode. When I say likely I mean that it's the only reasonable explanation for the differences when there should be none. |
There is something called a local database. The messages come in, get decrypted, and are then stored in plaintext in this local database (the database itself is encrypted). If you reopen Signal, the local database is read and the messages are then displayed. This is exactly the reason why you can't simply recover your messages if you lose your phone. The way you think message decryption is handled is just not how Signal deals with messages.
That's not how the Android system works, it's how basically every OS works. If you try to access memory not belonging to your application, you usually get a segmentation fault. I think you're having a bad understanding of how the protocol works. Explaining how Signal (and the protocol) works here is too much work, so I am going to give you a link to a video: https://www.youtube.com/watch?v=DXv1boalsDI which explains it quite well. Just because your version of Signal sends fewer data than the main one doesn't mean the main version is compromised. Please make sure you have a good understanding of how the app and protocol work and have proof before making such claims as this. |
That's simply not true. There will be a layer that doesn't have TLS ran over it. If you want to prove this I would suggest to fork the App and add / enable logging of the data just before the TLS layer, just before it gets encrypted. Then you can inspect what's actually sent (with Logcat for Android for example). And additionally I don't think it's wise to say bad things about Signal or the company or the people working there unless you prove it. If you don't trust that this will be explained later on you are free to simply switch the messaging platform. I for example like Matrix because it's not bound to any kind of entity and is decentralized like good old PGP, just in a more accessible way. You might end up hurting the reputation of Signal while the allegations could be false at the same time. And that's not good. It's already complicated enough for the common user to pick a proper messenger if companies are running ads for their messengers and claim that they are privacy oriented while they are actually not. And I know that this could be true about Signal, too. But it could also be that you are working for a company that is a competitor to Signal or even a government that doesn't like to see Signal being used by its citizens. What I would like to see are facts, proves, detailed instructions how to reproduce proves and not just speculations and allegations. Kind regards |
|
To all the "commentators" signal is definitely "not" compromised by a government agency and the devs silence is "normal". |
The only fedgov here is you, trying to get the thread locked up by derailing it. You glow in the dark. Here is Mike Kuketz' take on this: |
|
I think lots of people are concerned, that obviously the server repo is not always the current version of the servers, which kind of opposes the open source principle. Surely it's not the task of the devs to explain it. But someone of signal needs to speak up, why the running server is not always open source and how this delay of publishing the code happened and not just sweep it under the carpet, now that it's public again. I don't know how to put pressure on them to explain it, but I guess this issue on the android repo is not the correct spot. I'm out. |
|
Speaking of this issue (in Android repo), I also wonder why they have disabled issues tab in server repo. Aren't non-contributer developers supposed to open issues in repo? |
|
Signal shenanigans are really making me lose trust in them. Not being a good open source actor, building in some shitcoin into their service... Sounds like a CEO needs to be fired... I'm starting to regret donating money to Signal... |
|
It hasn't been said yet, so I'll go ahead and say it... Anyone know of any good Signal alternatives? |
|
First off, sorry the source for one of our services was so far behind. We often don't push source until we release things, and there were a few overlapping releases that happened in that period which made it awkward to push at any moment and put us behind. Additionally, we've seen a large increase in spam, and a reluctance to immediately publish the exact anti-spam measures we were responding with to a place where spammers could immediately see them combined with the above to cause this extreme delay. As folks in this thread have noted, our client source is always published with each release, the builds are reproducible, and everything is designed not to trust the server anyway. To be very clear for the few tinfoil hatters here (the internet just wouldn't be the same without you at this point, thank you for your service), we are not under any "gag order," there is no NSL, and the whole point is that there's no "malware" we could install on the server. Even if it's of no security consequence, we get why server source is useful for people who want to run their own versions of Signal, understand how Signal works, and just generally see how things are built. We'll do a better job of pushing changes in more real time. We try not to use GH issues for discussion, so I'm going to close this now, but hit us up on the forums. |
and others
signalapp/Signal-Server@3432529 is the last public commit.
Is there any public reason why the server is not open source anymore? Sorry to post here, would have loved to open an issue on the Signal-Server project, but that is not possible.
Tagging all past official contributors of Signal-Server to get insight publicly: @moxie0 @moxie-signal @TheBlueMatt @geogriff-signal @acton-signal @ehrenkret-signal @noboomu-signal @posix4e @paride @FredericJacobs @mkroman
Libability in open source projects is a thing, even if forgotten. Transparency is the method. Otherwise, it requires faith. And faith is to be replaced by transparency and liability.
Otherwise, i'm sorry guys/gals, but you are pushing people down this graph for decentralization; this graphic took into consideration your server code was open, which it isn't anymore: https://twitter.com/ArndtNissen/status/1354876066691768325
Edit: signalapp/Signal-Server@365ad3a updated server code to version in April 2021:
Where code is not public anymore. Same stance. Trust is now based on faith, not transparency nor accessible and auditable source code. Please change that; or claim you are now closed source on server side code and that metadata collection is whatever people might believe in without possibility of auditing it by themselves.
The text was updated successfully, but these errors were encountered: