Either we document this necessity, or we change the method to be clear about this.

I'm not sure if this is already known/intended, but I couldn't get a device link URL without switching to the Production servers. I get the following error on Staging:

Service error: Websocket error: error while connecting to websocket: IO error: invalid certificate: UnknownIssuer

I see you have SIGNAL_ROOT_CA hard-coded in the lib, so I thought something might have changed upstream. Do you do most of your development against the production servers? Have you tried to use something like dosco/signal-dev?

Edit: I've attached the certificate I downloaded manually from https://chat.staging.signal.org/ and it is indeed different than the one for https://chat.signal.org/ which is the same as the hard-coded one.

signal-cert.zip

Currently, the attachment cipher about to be merged in #9 does not check the digest that's supplied in the AttachmentPointer. This should be implemented and tested too.

Things like bd7f9ee slip through reviews often.

1. I think we might want to have get_preferred_protocol_address() as a method on either Address (as constructor), on StorageContext (as provided method) or as method on ServiceAddress (as conversion method into an Address).
2. I think we may want StoreContext::get_sub_device_sessions to accept a ServiceAddress instead of an Address, or make a provided method on the trait.

Both these items correspond to an XXX in the above commit.

Right now, we have many pub mod and some types might not need to be public as previously thought.

I'd like to review those before we start improving the public documentation & examples.

Currently we have

pub struct ProfileKey(pub Vec<u8>);

zkgroup also exposes a ProfileKey, which we can use instead. We need it for GroupV2 too.

Attachments come in two versions, and I am implementing V2. V3 is there, but is slightly more involved, and will only become interesting for me in Whisperfish 1.0. Leaving this as a note.

When an EndSession is received, the receiver needs to forget all session state. In the Java library, the delete_all_sessions method is called by the implementor (i.e., the Android app). Currently, this is implemented exactly like that, but it might be useful to consider implementing this here already.

Follow-up issue following a comment from @rubdos - details to come.

get/put/post/delete share a whole lot of code, but they differ ever so slightly in their implementation. Should probably be rewired through a macro.

A naive ProtocolStore implementation can just read and write files from disk. This makes disk a bottleneck if there is a lot messages to be caught up to. Let's introduce a CachedProtocolStore<T: ProtocolStore>, with a configurable semi-smart cache.

TODO (more or less):

• Implement an equivalent of the PushService for the new groups v2 endpoints (called GroupsV2Api in the Java source code)
• Import new Protobuf models
• Only fetch group participants for now

Use https://github.com/signalapp/zkgroup/ for encrypt/decrypt operations.

In Signal Desktop, after linking with a main device, contacts are requested, then downloaded from the CDN and stored.

This is necessary for UIs to show the name / avatar of people when you start receiving messages.

#5 includes some group flags, but this should maybe get encoded as a fallible (future-compatible) enum. There are nice crates for this too.

EDIT: group flags are exposed through prost/protobuf, so we just need to expose the correct ones.

When all messages that were currently queued are received, this PUT request is sent. Currently, libsignal-service-rs ignores this signal, but it could be useful to expose this. Example use case: it can be used to flush pending notifications, such that notifications may be deleted if the corresponding messages were already read on a secondary device.

There's a common pattern in EnvelopeCipher, AttachmentCipher and ProvisioningCipher: CBC+PKCS7<u8>+AES256+HMAC<Sha256>.

We might want to refactor some bits there.

Provisioning seems to take in a bit of additional data for the HMAC, but that should still be doable.

This should also yield a cleaner error handling. Currently, decrypt_vec has an expect, but this can panic on maliciously crafted input!

Hi!

I have chronic problems downloading attachments with the Whisperfish dev version.

There are both network-style timeout errors and 403 return codes.

My MO for rescue is to always run Whisperfish with logging on, hoping real hard all the
relevant information is being logged (that has not always been the case).

The steps to create a rescue script are here https://gitlab.com/rubdos/whisperfish/-/blob/rescue-operations/doc/rescue-instructions.rst

Once I've mangled the log file into a bash script, fingers crossed, attachments are downloaded.

The only file, now that the CdnId and the CdnKey are introduced is the single CdnId one,
no CdnKey is downloaded, it only returns 403.

My hypothesis would be that these are not interchangeable. It would make sense that 403 is
returned instead of 404, to not leak whether or not files exist in the endpoint.

Is there something to my hypothesis? How would I go about decoding the string keys into
integer identifiers?

Thanks!

Apparently, the crypto-mac crate version 0.7 is now missing from crates.io and it prevents from compiling any project depending on libsignal-service.

I also created an issue on the zkgroup crate repository but I don't know if anyone is able to handle this issue, since the real dependency error comes from poksho which doesn't seem maintained nor secure (as said in their readme).

Do you have any idea on what to do?

Link to the issue opened in zkgroup : signalapp/zkgroup#16

Here is my cargo command output :

user@linux [~/signal/test] $ cargo build
    Blocking waiting for file lock on package cache
    Updating crates.io index
    Updating git repository `https://github.com/whisperfish/libsignal-service-rs`
    Updating git repository `https://github.com/signalapp/libsignal-client`
    Updating git repository `https://github.com/signalapp/zkgroup`
    Updating git repository `https://github.com/signalapp/curve25519-dalek.git`
    Updating git repository `https://github.com/signalapp/curve25519-dalek.git`
    Updating git repository `https://github.com/signalapp/poksho.git`
error: failed to select a version for the requirement `crypto-mac = "^0.7"`
candidate versions found which didn't match: 0.11.1, 0.11.0, 0.10.1, ...
location searched: crates.io index
required by package `hmac v0.7.1`
    ... which is depended on by `poksho v0.7.0 (https://github.com/signalapp/poksho.git?tag=v0.7.0#8bb8c61c)`
    ... which is depended on by `zkgroup v0.7.3 (https://github.com/signalapp/zkgroup?tag=v0.7.3#197c382e)`
    ... which is depended on by `libsignal-service v0.1.0 (https://github.com/whisperfish/libsignal-service-rs#7d6fce5f)`
    ... which is depended on by `libsignal-service-hyper v0.1.0 (https://github.com/whisperfish/libsignal-service-rs#7d6fce5f)`
    ... which is depended on by `presage v0.1.0 (/home/user/signal/presage)`
    ... which is depended on by `test v0.1.0 (/home/user/signal/test)`

head java/src/main/java/org/whispersystems/signalservice/internal/contacts/entities/RemoteAttestationRequest.java

/*
 * Copyright (C) 2017 Open Whisper Systems
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Affero General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.

$ rg AGPL
README.md
120:Licensed under the AGPLv3: https://www.gnu.org/licenses/agpl-3.0.html

Given that I'm building very much parallel to that library, and I'm using the .proto files (those could be argued under regular GPLv3+), I think this repo might have to be AGPLv3+ too. I'd have to look into the implications to the project that I am building (I'm rewriting an application by @aebruno that's under GPLv3), but I better get this conversation going, I suppose.

I got this after just adding presage to a new test project. I didn't even start trying to use the code and compilation fails:

error[e0277]: `s` cannot be shared between threads safely
   --> /home/hackel/dev/presage-test/_build/cargo-home/git/checkouts/libsignal-service-rs-e91a0c40cab55da9/91d7d09/libsignal-service/src/sender.rs:486:30
    |
486 | ...                   .delete_service_addr_device_session(
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `s` cannot be shared between threads safely
    |
note: required by a bound in `sessionstoreext::delete_service_addr_device_session`
   --> /home/hackel/dev/presage-test/_build/cargo-home/git/checkouts/libsignal-service-rs-e91a0c40cab55da9/91d7d09/libsignal-service/src/session_store.rs:33:14
    |
33  |     async fn delete_service_addr_device_session(
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `sessionstoreext::delete_service_addr_device_session`
help: consider further restricting this bound
    |
130 |     s: sessionstore + sessionstoreext + clone + std::marker::sync,
    |                                               +++++++++++++++++++

error[e0277]: `s` cannot be shared between threads safely
   --> /home/hackel/dev/presage-test/_build/cargo-home/git/checkouts/libsignal-service-rs-e91a0c40cab55da9/91d7d09/libsignal-service/src/sender.rs:532:30
    |
532 | ...                   .delete_service_addr_device_session(
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `s` cannot be shared between threads safely
    |
note: required by a bound in `sessionstoreext::delete_service_addr_device_session`
   --> /home/hackel/dev/presage-test/_build/cargo-home/git/checkouts/libsignal-service-rs-e91a0c40cab55da9/91d7d09/libsignal-service/src/session_store.rs:33:14
    |
33  |     async fn delete_service_addr_device_session(
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `sessionstoreext::delete_service_addr_device_session`
help: consider further restricting this bound
    |
130 |     s: sessionstore + sessionstoreext + clone + std::marker::sync,
    |                                               +++++++++++++++++++

rustc 1.58.1 (db9d1b20b 2022-01-20)

Should get some extra fields from SignalServiceDataMessage.java.

Envelopes with r#type() == UnidentifiedSender currently panic: "UnidentifiedSender requires SealedSessionCipher, please report a bug against libsignal-service-rs."

This needs to be handled, such as in Java's SignalServiceCipher

I currently have this outstanding Whisperfish patch:

diff --git a/src/worker/client.rs b/src/worker/client.rs
index dfb599b..6394f1e 100644
--- a/src/worker/client.rs
+++ b/src/worker/client.rs
@@ -552,7 +552,7 @@ impl Handler<SendMessage> for ClientActor {
                     }
                     // Clone + async closure means we can use an immutable borrow.
                     match sender
-                        .send_message(recipient, content.clone(), timestamp, online)
+                        .send_message(recipient, None, content.clone(), timestamp, online)
                         .await
                     {
                         Ok(s) => {
@@ -571,7 +571,7 @@ impl Handler<SendMessage> for ClientActor {
                 };

                 match sender
-                    .send_message(recipient, content.clone(), timestamp, online)
+                    .send_message(recipient, None, content.clone(), timestamp, online)
                     .await
                 {
                     Ok(s) => {
@@ -605,7 +605,7 @@ impl Handler<SendMessage> for ClientActor {
                 log::trace!("Transmitting {:?}", container);

                 match sender
-                    .send_message(local_addr, container, timestamp, online)
+                    .send_message(local_addr, None, container, timestamp, online)
                     .await
                 {
                     Ok(s) => {

... which made me wonder, why haven't we put the Option<UnidentifiedSender> as a MessageSender property? We might even consider making it a strong type, MessageSender<UnidentifiedSender> and MessageSender<IdentifiedSender> and MessageSender<Option<UnidentifiedSender>> (for cases where it really has to be a runtime-dispatch).

Cc @gferon

Right now, we both handle phone numbers (e164) and uuid as strings.

Replace this by using: Uuid and a PhoneNumber (containing a String) that can validate input with a crate like phonenumber.

I recently opened an issue/request for libsignal-client to re-export curve25519-dalek features

Assuming this request is successful I hope that libsignal-service-rs/Cargo.toml might also re-export curve25519-dalek features?

nightly = [libsignal-client/nightly]
default = [libsignal-client/default]
std = [libsignal-client/std]
alloc = [libsignal-client/alloc]
u32_backend = [libsignal-client/u32_backend]
u64_backend = [libsignal-client/u64_backend]
simd_backend = [libsignal-client/simd_backend]

In particular I am seeking std and u32_backend - and include the others for sake of completeness.

Stores traits and implementations (for instance SessionStore and it's InMemSessionStore) don't implement the Send trait because of the #[async_trait(?Send)] macro.

I understand that maybe, this makes this trait is easier to implement but it also prevents further implementations from spawning tasks in different threads.

Crates like sled (used by presage for stores) do have the Send trait so it would be great if we could remove this limitation.

Is there another reason why we prevent from implementing this trait?

If you think this is not an error an this is useful, I can work on rewriting this part of code and submit a pull request.

I'm not sure there's any advantage requiring structs to be initialized with a custom rng. We might want to just use rng::thread_rng() when we need it. (it's already done like that in a few places, so it would also be a good occasion to clean up)

Signal Android provisions the account/secondary device entirely using the websocket connection, which doesn't interpret parameters like name or capabilities the same way.

Hello,
I wrote a Signal chat bot in Rust, and I'm currently using signal-cli through dbus to do all the backend stuff.
Is this crate in a state, where I could use it in my project? The docs are a bit empty...
Are the following features implemented?

• Sending/Receiving Messages to/from groups and users
• Sending/Receiving Attachments to/from groups and users
• Registering as a secondary device by taking a tsdevice link
• Registering other devices by providing a tsdevice link
• Reacting to messages
• Deleting messages

Thanks!

We have constructions of the form

let url = Url::parse(&self.cfg.cdn_urls[&0])
    .expect("valid cdn base url")           
    .join(path)                             
    .expect("valid CDN path");              

They lead to the discussion whether we should return those errors from these methods in PushService (and probably elsewhere). I argue it is unnecessary, because they should be checked in the construction of the relevant structs. On the other hand, do we check these? We should evaluate whether the types we use are strong (strong enough), and maybe move some of the error parsing logic down elsewhere.

ServiceCipher: Clone implies that I can concurrently process two messages that should've been processed sequentially. Even considering that the underlying storage mechanism is synchronised/mutex'd, that's not enough: the synchronisation mechanism cannot protect against readA-readB-writeA-writeB internally.

The simplest mitigation would be to Arc<Mutex> the complete insides of ServiceCipher, the coolest would be by considering the session that needs to be accessed:
we could lock only a single session to enforce serialized access.
That's a lot of code though.

In particular: acknowledging messages is not implemented.

Leaving this as an issue, since we currently only require the message pipe.

StoreContext extension traits, or a struct, or ... No idea, but it was a thing with our own libsignal-protocol-rs, but not anymore with libsignal-client. Would be nice to have some ergonomics about this, because the method calls are quite involved.

This is a follow-up ticket to figure out if/what/when with the strip_padding functions.

See comment from @rubdos https://github.com/Michael-F-Bryan/libsignal-service-rs/pull/27/files#r515660453

Currently, the trace log contains secrets, such as the phone number and signaling password. We might want to filter these out.

@gferon We could introduce a feature = "unhygienic-logging", or we could do cfg!(debug-assertions), to still allow to log these things. What do you think? I'd vote that a debug build can contain sensitive information, while release mode should really filter and censor these crucial things.

Things to censor:

• Attachment keys
• Signaling key
• Phone numbers
• UUIDs
• public keys (identity key comes to mind)

instead of libsignal-protocol-c. It's already used in production in (at least) the Android app.

Link: https://github.com/signalapp/libsignal-client

First of all, nice project! I've been poking around to use it for my own Signal CLI utility.

However, I have been unable to get authorized with the push service after linking a device and instantiating a new push service with appropriately set service config and credentials (i.e. all requests end up with 401 Unauthorized).

After some more investigation (and after looking at the forked libsignal-service-java), I came to understand that the authorization header should also include the device ID, in case the request is being made on behalf of non-primary device. I.e. for non-primary device, the header should be composed in format {identifier}.{device_id}:{password}.

Locally, I was able to make the authorization work by building the login with the said device ID.

I was wondering whether this is the right solution to my problem (or whether I'm doing something incorrectly from the beginning). If so, I'd be also happy to provide a PR for this.

On Android it uses this function:

nonce has 12 bytes from the the beginning of the avatar and the profile key has a length of 32.

https://github.com/signalapp/Signal-Android/blob/a47448b6c6c26a0d7f7156ce54eeaf2a6a34ed5d/libsignal/service/src/main/java/org/whispersystems/signalservice/api/crypto/ProfileCipherInputStream.java#L22-L35

https://github.com/signalapp/libsignal-client/blob/86ba9b5b60f6bbd3b42833e3144708d8c75f2dde/rust/bridge/shared/src/crypto.rs#L20-L42

Are you planing to use libsignal-client decryption/encryption functions in all the places in the future?

I stumbled on some breaking changes in libsignal-protocol upstream while trying to build gurk-rs, a dependent of libsignal-service-rs.

I worked around the issue by adding the tag 'v0.9.6' to the libsignal-protocol (https://github.com/signalapp/libsignal-client) dependency in my local checkout of libsignal-service-rs.

I've attached the build errors. I don't understand any Rust, so sorry I can't address the error specifically:
Hunx2Xq8.txt

When an account is already pin protected, it is currently impossible register and to unlock it.

I don't really understand what is the use of KBS and I'm not sure we have the tools needed to provide it. But now, it seems to be the only registration lock pin accepted (the old pin method isn't accepted by signal servers).

This is how signal-cli did it in their java implementation :

AsamK/signal-cli@425626e

Is there an easy way to add this in one of the libsignal-service-rs crates ?

It looks like we should encrypt the device name, but I'm not sure yet whether this is exactly the problem or not. (This stopped working correctly a few months ago.)

Currently, the Actix backend does not implement error conversion. We got the first crash in the wild, although the Whisperfish actor seemed to recover after that.

impl From<WsProtocolError> for AwcWebSocketError {
    fn from(e: WsProtocolError) -> AwcWebSocketError {
        todo!("error conversion {:?}", e)
        // return Some(Err(ServiceError::WsError {
        //     reason: e.to_string(),
        // }));
    }
}

[2021-12-22T14:27:25Z TRACE libsignal_service_actix::websocket] Triggering keep-alive
[2021-12-22T14:27:25Z TRACE libsignal_service::messagepipe] Sending request WebSocketRequestMessage { verb: Some("GET"), path: Some("/v1/keepalive"), body: None, headers: [], id: Some(1640183245225) }
[2021-12-22T14:27:25Z TRACE libsignal_service::messagepipe] request on route.
thread 'main' panicked at 'not yet implemented: error conversion Io(Kind(UnexpectedEof))', /home/mersdk/cargo/git/checkouts/libsignal-service-rs-57c3f8dab81a594f/49651bb/libsignal-service-actix/src/websocket.rs:47:9
stack backtrace:
   0:       0x5a74bf1f94 - std::backtrace_rs::backtrace::libunwind::trace::h4053ad6853eb3582
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:       0x5a74bf1f94 - std::backtrace_rs::backtrace::trace_unsynchronized::h3cd99e1d7628b4b0
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:       0x5a74bf1f94 - std::sys_common::backtrace::_print_fmt::h3ca5dd6a1c61f5e2
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/sys_common/backtrace.rs:67:5
   3:       0x5a74bf1f94 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9c15be0c4a0616a8
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/sys_common/backtrace.rs:46:22
   4:       0x5a74752d1c - core::fmt::write::he5c8b5c4e10fee36
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/core/src/fmt/mod.rs:1092:17
   5:       0x5a74bf1684 - std::io::Write::write_fmt::hb80c9754d7325278
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/io/mod.rs:1572:15
   6:       0x5a74bf0fb0 - std::sys_common::backtrace::_print::hf99a40a583c4b2ee
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/sys_common/backtrace.rs:49:5
   7:       0x5a74bf0fb0 - std::sys_common::backtrace::print::hf01f1c360c3f3281
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/sys_common/backtrace.rs:36:9
   8:       0x5a74bf0fb0 - std::panicking::default_hook::{{closure}}::he97a30ca46a3471d
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/panicking.rs:208:50
   9:       0x5a74bf03a0 - std::panicking::default_hook::h28e2b8725e916778
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/panicking.rs:225:9
  10:       0x5a74bf03a0 - std::panicking::rust_panic_with_hook::h381a1a1d878d983f
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/panicking.rs:591:17
  11:       0x5a74c0a238 - std::panicking::begin_panic_handler::{{closure}}::h3e441aa93da6512f
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/panicking.rs:497:13
  12:       0x5a74c0a1b4 - std::sys_common::backtrace::__rust_end_short_backtrace::h6bd7448eccdae96b
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/sys_common/backtrace.rs:141:18
  13:       0x5a74c0a168 - rust_begin_unwind
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/std/src/panicking.rs:493:5
  14:       0x5a74750e50 - core::panicking::panic_fmt::he8b3ba9c2f95546f
                               at /home/rsmet/rpmbuild/BUILD/rustc-1.52.1-src/library/core/src/panicking.rs:92:14
  15:       0x5a74a66658 - tokio::runtime::task::raw::poll::h94e25952ded6141d
  16:       0x5a74c36210 - tokio::task::local::LocalSet::tick::he6168425f2750c9d
  17:       0x5a74897600 - <futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll::h667069554f2a683a
  18:       0x5a74b10e70 - ProcessQtEvent
  19:       0x5a74d5b27c - _ZN5Waker11customEventEP6QEvent
                               at /home/mersdk/cargo/registry/src/github.com-1285ae84e5963aae/qmetaobject-0.2.5/src/future.rs:66:194
  20:       0x5a74d5b27c - _ZN5Waker11customEventEP6QEvent
                               at /home/mersdk/cargo/registry/src/github.com-1285ae84e5963aae/qmetaobject-0.2.5/src/future.rs:59:14
  21:       0x7d62ad8af0 - _ZN7QObject5eventEP6QEvent
  22:       0x7d62aae144 - _ZN16QCoreApplication6notifyEP7QObjectP6QEvent
  23:       0x7d62aae2e8 - _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent
  24:       0x7d62ab06b8 - _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData
  25:       0x7d62b00648 - <unknown>
  26:       0x7d60c0c234 - g_main_context_dispatch
  27:       0x7d60c0c4a0 - <unknown>
  28:       0x7d60c0c534 - g_main_context_iteration
  29:       0x7d62b00a90 - _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
  30:       0x7d62aac608 - _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE
  31:       0x7d62ab41d4 - _ZN16QCoreApplication4execEv
  32:       0x5a74887ec8 - qmeta_async::run::h6a7bebc2d3d1853f
  33:       0x5a74718e7c - harbour_whisperfish::main::hfc7c76c99c89e269
  34:       0x5a74a0770c - std::sys_common::backtrace::__rust_begin_short_backtrace::hd45e477692160929
  35:       0x5a7471a484 - main
  36:       0x7d6169311c - __libc_start_main
  37:       0x5a74716874 - <unknown>
[2021-12-22T14:28:10Z DEBUG libsignal_service::messagepipe] WebSocket stream ended.
[2021-12-22T14:28:10Z INFO  libsignal_service::messagepipe] Sink was closed. Reason: Ok(())
[2021-12-22T14:28:10Z DEBUG harbour_whisperfish::worker::client] Attempting reconnect
[2021-12-22T14:28:10Z TRACE libsignal_service_actix::websocket] Will start websocket at Url [REDACTED]

I'd like to introduce an MSRV for libsignal-service-rs, because we (Whisperfish) are constrained to 1.44 by Jolla. I think we can persuade Jolla relatively easily to bump the version, but this will have a significant delay (2 months every time).

@gferon, @Michael-F-Bryan, would you be okay with making everything compatible down to 1.44? If so, I'd kindly ask @gferon to alter the Github Actions to have a fixed version on 1.44. I'll gladly write the patches for compat, both here and in -protocol!

Seems like create_multi_device_sent_transcript_content is missing the UUID field. Currently rebasing the strong types onto master, and I noticed. Will probably fix this in that PR.

I just got a Whisperfish log from a user, that contains the following (censored):

[2020-12-21T09:32:41Z DEBUG libsignal_service_actix::push_service] AwcPushService::put response: 
    ClientResponse HTTP/1.1 423 Locked
      headers:
        "date": "Mon, 21 Dec 2020 09:32:41 GMT"
        "content-type": "application/json"
        "x-signal-timestamp": "160854316xxxx"
        "connection": "keep-alive"
        "content-length": "181"
[2020-12-21T09:32:41Z TRACE libsignal_service_actix::push_service] Unhandled response with body: Ok(b"{\"timeRemaining\":NUMBER,\"backupCredentials\":{\"username\":\"4e3c26d8-UUID-XXX\",\"password\":\"4e3-UUID-XXX:NUMBER:SOMETHING-HEX\"}}")
[2020-12-21T09:32:41Z TRACE mio::poll] deregistering handle with poller
[2020-12-21T09:32:41Z ERROR harbour_whisperfish::worker::setup] Error in registration: Unexpected response: HTTP 423

It seems like 423 means that the account is locked by a PIN code, and we somehow need to supply the PIN code to actually be able to re-register.

We might want to implement this unlocking procedure together with the migration, since this actually means we can import from Android or iOS phones!

This has been done in protocol, but not yet completely here.

For SailfishOS, we require MSRV = 1.52. It would be great if we could enforce this in CI.