starred/healthchecks

Fork 0

mirror of https://github.com/healthchecks/healthchecks.git synced 2026-04-25 15:05:49 +03:00

[GH-ISSUE #564] Signal integration failure due to new identity #409

New issue

Closed

opened 2026-02-25 23:42:21 +03:00 by kerem · 5 comments

kerem commented

2026-02-25 23:42:21 +03:00

Owner

Originally created by @piramiday on GitHub (Sep 27, 2021).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/564

up until now, I loved the Signal integration you implemented following #428.

unfortunately, recently Healthchecks stopped sending me messages after I reinstalled Signal.
even the button "Test!" from your website fails consistently.

I fear this might be due to the fact that my cryptographic identity got reset during the reinstall and that the Signal protocol requires messages to be received, as well as sent, in order to properly function.
if I am not mistaken, Healthchecks never "receives" messages.
by never invoking the receive command, Healthchecks might be skipping on all those "new key" publishing messages that keep the instances in agreement with the central servers.

any suggestion on how to proceed?
I have tried to "reset the secure session" in my conversation with Healthchecks without any luck, possibly due to the fact that Healthcheck is not receiving messages anyway.

Originally created by @piramiday on GitHub (Sep 27, 2021). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/564 up until now, I loved the Signal integration you implemented following #428. unfortunately, recently Healthchecks stopped sending me messages after I reinstalled Signal. even the button "Test!" from your website fails consistently. I fear this might be due to the fact that my cryptographic identity got reset during the reinstall and that the Signal protocol requires messages to be received, as well as sent, in order to properly function. if I am not mistaken, Healthchecks never "receives" messages. by never invoking the receive command, Healthchecks might be skipping on all those "new key" publishing messages that keep the instances in agreement with the central servers. any suggestion on how to proceed? I have tried to "reset the secure session" in my conversation with Healthchecks without any luck, possibly due to the fact that Healthcheck is not receiving messages anyway.

kerem closed this issue

2026-02-25 23:42:21 +03:00

kerem commented

2026-02-25 23:42:22 +03:00

Author

Owner

@cuu508 commented on GitHub (Sep 27, 2021):

Thanks for letting me know.

Healthchecks is using signal-cli to send and receive messages (it doesn't do anything with the received messages, but it does receive them). When a contact's identity changes, signal-cli does not automatically trust the new identity. There is a CLI "trust" command, but it's not really feasible to use in the Healthchecks case.

Starting from v0.9.0 signal-cli has a new --trust-new-identities flag (changelog). I haven't updated Healthchecks to use signal-cli 0.9.0 yet, but plan to do that soon. I'll report here when that's done and tested.

@cuu508 commented on GitHub (Sep 27, 2021): Thanks for letting me know. Healthchecks is using signal-cli to send and receive messages (it doesn't do anything with the received messages, but it does receive them). When a contact's identity changes, signal-cli does not automatically trust the new identity. There is a CLI "trust" command, but it's [not really feasible to use](https://github.com/AsamK/signal-cli/issues/382#issuecomment-903558069) in the Healthchecks case. Starting from v0.9.0 signal-cli has a new `--trust-new-identities` flag ([changelog](https://github.com/AsamK/signal-cli/blob/master/CHANGELOG.md)). I haven't updated Healthchecks to use signal-cli 0.9.0 yet, but plan to do that soon. I'll report here when that's done and tested.

kerem commented

2026-02-25 23:42:22 +03:00

Author

Owner

@piramiday commented on GitHub (Sep 27, 2021):

thanks for the reply.

regarding receiving messages: it's weird, I do run my own signal-cli daemon and I have seen the "single check mark" icon in my own Signal mobile app only when my daemon had not received messages yet, that is, when my daemon was in between cron jobs to fetch messages (classic, non-dbus mode).
if I send a test message to Healthchecks, it never displays the two check marks, therefore I conclude that it does not receive messages.

of course, receiving messages and piping to /dev/null is perfectly fine!
but then the Signal server should know that a specific phone number fetched recent messages and should display the "two check marks" icon.
(note: the "white two check marks" icon, instead, is after read receipts are sent, which is doable but uncommon for a bot, and quite useless. I am referring to the "gray two check marks" icon.)
am I missing something?

with respect to the missing features in the signal-cli dbus mode, you might or might not know that there has been a recent development of a tidier experience using JSON-RPC:
https://github.com/AsamK/signal-cli/discussions/679
maybe that will be better supported in the upcoming releases.

anyway, it might very well be that the "trust everything without bothering me" mode is a solution, but not the solution, to this problem -- I mean, you should be able to send messages to untrusted identities, as well!
anyway, a working Signal notification system is still better than nothing. 😄

PS: what version of signal-cli are you on?

@piramiday commented on GitHub (Sep 27, 2021): thanks for the reply. regarding receiving messages: it's weird, I do run my own signal-cli daemon and I have seen the "single check mark" icon in my own Signal mobile app only when my daemon had not received messages yet, that is, when my daemon was in between cron jobs to fetch messages (classic, non-dbus mode). if I send a test message to Healthchecks, it never displays the two check marks, therefore I conclude that it does not receive messages. ![image](https://user-images.githubusercontent.com/48775554/134885966-6c01ed3e-8ab4-45b2-8c1d-a5466096f5c1.png) of course, receiving messages and piping to `/dev/null` is perfectly fine! but then the Signal server should know that a specific phone number fetched recent messages and should display the "two check marks" icon. (note: the "white two check marks" icon, instead, is after read receipts are sent, which is doable but uncommon for a bot, and quite useless. I am referring to the "gray two check marks" icon.) am I missing something? with respect to the missing features in the signal-cli dbus mode, you might or might not know that there has been a recent development of a tidier experience using JSON-RPC: https://github.com/AsamK/signal-cli/discussions/679 maybe that will be better supported in the upcoming releases. anyway, it might very well be that the "trust everything without bothering me" mode is _a_ solution, but not _the_ solution, to this problem -- I mean, you should be able to send messages to untrusted identities, as well! anyway, a working Signal notification system is still better than nothing. :smile: PS: what version of signal-cli are you on?

kerem commented

2026-02-25 23:42:22 +03:00

Author

Owner

@cuu508 commented on GitHub (Sep 27, 2021):

I'm currently on v0.7.4

Thanks for the pointer about JSON-RPC – didn't know about that!

One nice thing about the DBUS method is I can run signal-cli as a separate system user. If there's a vulnerability in signal-cli, the damage it can do is limited. To use JSON-RPC, I'd be tempted to add a tiny HTTP shim on top of it, so it can still run as a separate user and listen on 127.0.0.1:<some port>

@cuu508 commented on GitHub (Sep 27, 2021): I'm currently on v0.7.4 Thanks for the pointer about JSON-RPC – didn't know about that! One nice thing about the DBUS method is I can run signal-cli as a separate system user. If there's a vulnerability in signal-cli, the damage it can do is limited. To use JSON-RPC, I'd be tempted to add a tiny HTTP shim on top of it, so it can still run as a separate user and listen on 127.0.0.1:\<some port\>

kerem commented

2026-02-25 23:42:22 +03:00

Author

Owner

@cuu508 commented on GitHub (Sep 27, 2021):

Just upgraded to 0.9.0 and added the --trust-new-identities always parameter.

@piramiday can you please check if the "Test!" button in the Integrations page now delivers a test message?

@cuu508 commented on GitHub (Sep 27, 2021): Just upgraded to 0.9.0 and added the `--trust-new-identities always` parameter. @piramiday can you please check if the "Test!" button in the Integrations page now delivers a test message?

kerem commented

2026-02-25 23:42:22 +03:00

Author

Owner

@piramiday commented on GitHub (Sep 27, 2021):

works like a charm, thanks for the prompt intervention! 🚀

@piramiday commented on GitHub (Sep 27, 2021): works like a charm, thanks for the prompt intervention! :rocket:

kerem referenced this issue

2026-02-25 23:44:17 +03:00

[PR #409] [MERGED] Fix logic bug in test_signup (#408) #958