Change-Id: If56a102c1861b762623acdbe11358b0bc85085c5

Due to certStore changes, we should force the certificate pinning
after forceReloadAccount

Change-Id: I1a98f86847607e9c48b91b5448185e3d25763a49

If all pending connections fails, it should remove all waiting callbacks
and not only the connecting one.
So, introduce a structure to make the difference between PendingCb linked
to a ongoing DHT request and others waiting for the request to finish.
If all ongoing requests fails, all waiting callbacks are called. This
avoid wrong "Already connecting" messages.

Change-Id: I518f1ef85294f55f78d1b75638b1612c68ea0a0a

We're in 2023 and supporting c++17, every supported compiler should
have correct headers.

Change-Id: I81bda5df7a54a0943529d37d20e2852c651c8c6b

jami-client-qt#681
jami-client-qt#880
jami-client-qt#908

Change-Id: Idcf20c821cf0b619d9ee6ccfcaf3ba153622a679

Sébastien Blin authored 2 years ago and Adrien Béraud committed 1 year ago

Change-Id: I4fe092e978d77213ebf29fea9d2a256bd1954d6c

GitLab: jami-plugins#38
Change-Id: I42b4f25460285a677a226671bf85e0c1039e7c37

Change-Id: Id84e465996138a16aa425dde37baa389240f4221

Else, we can see several deadlock (closeVideoInput() will wait
forever, because a signal is emitted before the method is finished
causing a deadlock in sdbus-cpp)

Change-Id: I87d5a5d51e80f3b75e60354595f8c618def361ff

Change-Id: I50749a002936da4159be9479f256aa45fce64221

Vladimir Stoiakin authored 1 year ago and Sébastien Blin committed 1 year ago

Change-Id: If10740b4fd192a1043c5f83adc9072fe67df7862

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: I4627179aefe44e7cc0720c28076f70d2aaf17b0c

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

Else, passing the path and not the content of the file will cause:
Could not read certificate - ASN1: error in TAG

Change-Id: I2db356d1ccf8d3b059072cc14e64df8369f84e77

Kateryna Kostiuk authored 1 year ago and Sébastien Blin committed 1 year ago

If client calls some APIs from the account, convModule_ may be
un-initialized if the account is not yet ready, causing potential
segfaults

Change-Id: If47c9d5466e42dee58ea1ebbdd71404ee94a82d1

convModule()->bootstrap should not use configurationMutex_ while
locking conversations. Else we may have:
thread 1: configurationMutex_->conversationsMtx_
thread 2: conversationsMtx_->configurationMutex_
causing a deadlock

So, retrieve known devices before bootstrapping the conversation

Change-Id: Ib194edaa255b5ffde9e58ea7e0be0226943bb118

This will output to the "Output" pane in Visual Studio.

Change-Id: I74e229670c990f09af247b02dc3ae753ad7db9c6

Sébastien Blin authored 1 year ago and Andreas Traczyk committed 1 year ago

Change-Id: I9ef704107897a0a057e7d43feeb24d5e2eb73679

Else, it can cause a message forever sending.

https: //git.jami.net/savoirfairelinux/jami-client-ios/-/issues/281
Change-Id: Ia3bbf508a955137c5d57d8f7b45b2f6b0ac232be

Kateryna Kostiuk authored 1 year ago and Sébastien Blin committed 1 year ago

It is unnecessary because the device performs synchronization
during the bootstrap. Moreover, it could result in the
failure to receive notifications on iOS because iOS does not
respond to sync connections in the background. However, the
other side may consider it as already connected.

jami-client-ios#281

Change-Id: Id55e7bfaafba1e45a6c27afdebf682c33acd9d30

Change-Id: Ibb8963b9aa02c21e5382413b7918f0e1e0baea4a

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

We use GNUTls >= 3.6.7 so this is always true.

Change-Id: Ifcc996a95faf056a3c0eed35cffc17becddeeed3

Change-Id: I157118c875868aa1cae7d0b0ea02644175d33b70

The check in this loop is useless as we already have the transport
that we are searching for. Moreover, locking sipConnsMtx_ from
a pjsip operation (here sipvoiplink) may cause a deadlock.

Change-Id: Ic263d69a3f5518857a93a4a4576a4a63b7fda575

Change-Id: Ief11062f573e331d497aa267a1cd8723a757b113

Multiple changes are included in this patch:
+ Remove pendingConversationFetchMtx_ and use conversationsMtx_
instead to avoid any potential weird state
+ Remove RepeatedTask causing two fetch operations to happen
+ Remove bugguy map access causing a fetch to happen even if
previously removed

A test for the problematic scenario is added to avoid any future
regression.

Change-Id: I9b5f93fc11f053a0552e5f34711130d5a5c22c05

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

+ Like for windows, add write permissions if possible
+ Rewrite removeAll() condition because it returns an integer.

Change-Id: Id5eb413ed8a6a6345d9208646cdfb13f5c5810bb

Alireza Toghyiani authored 1 year ago and Kateryna Kostiuk committed 1 year ago

Gitlab: jami-client-ios#275

Change-Id: I34c2bd8e34d5c4932dcc2e2555659419c88b6202

When the LIBJAMI_FLAG_NO_AUTOSYNC flag is used, it is still
necessary to call startSync in order to receive invitations.
This patch applies the LIBJAMI_FLAG_NO_AUTOSYNC flag to startSync
callbacks.

jami-client-ios#280

Change-Id: Ieb8a1fb8542c4caf975e13d5a3210bdbc1099a55

GitLab: #855
Change-Id: Iaf9819d082b3b3e43291eb58f0ca59f168971542

Pierre Nicolas authored 1 year ago and Adrien Béraud committed 1 year ago

Allows to fix a bug on android where updatedpreference signal was not emitted

GitLab: jami-android#1271
Change-Id: I015269da19acb18dc0cdfb8310cb12b73aeb585f

Kateryna Kostiuk authored 2 years ago and Kateryna Kostiuk committed 1 year ago

On iOS, both Jami.app and notifications extension could modify
conversations and requests files. This patch adds API to reload
conversations and requests so Jami.app and notifications extension
could have up to date information.

Change-Id: I5873bc69c329bd6c78e7f4d60a01c9471e19bcd1

Else, destruction of the object can occurs during a async task
causing weird crashes.

Change-Id: Ia5f7e8f7324a8e8708c94890627d8576538289d3

+ Use JAMI_ERROR/JAMI_WARNING/JAMI_DEBUG/JAMI_LOG
+ Add a new error signal if an error occurs while comitting

Change-Id: Ic0ec594911bb7d29f6419f9ec1cba060c973d0d6

Change-Id: Ic7044e0aaef48403ab879750f43da202bbee21e0

This commit uses latest gmp version since it fixes
build for arm64 for macOS with assembly enabled.

It does not fix the build for iPhone, so the
option --disable-assembly should still be used when
building for iOS.

Change-Id: I045e0372c36367f22f8b8a95aaac987e559c6d02

GitLab: #854
Change-Id: If260bd73205d579cbe7c963bf3497bff202c1b55

Change-Id: Ic23ace5dbc183781d0020db647a5ac6e77e376fc

To build for arm64 on macOS, Darwin version 20 or higher
is required.

Change-Id: I6da0b78e64eee2b0b3b6169be58fd261ac3085be

Change-Id: I86622eb65679a2c953804fc87344d1733e5cb7b6

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: I267631faf3bdd24164553de669440c0e8d104638