Open HappyDr0id opened 1 year ago
When I was debugging https://github.com/appmattus/certificatetransparency/issues/97 I could see that coroutine job cancellations get transformed into SSLPeerUnverifiedException and then this may be bubbling up to some place where you are logging errors. I am also getting a ton of these in crashlytics.
Thanks for your insights @sudojhill! That can explain a part of the reports I'm getting indeed, but I also got feedbacks about users being suddenly blocked in the app because network calls are all blocked, and they have to restart the app to then be able to use the app, which is really impacting the user experience. For info, I rolled back to the 1.1.1 version of the lib unfortunately (with custom setup to use v3 log lists) to make the user experience good again π¬
The network calls being blocked I believe is also explained by the ticket I mentioned. Once you are in that state, you are stuck.
https://github.com/appmattus/certificatetransparency/issues/98 is another ticket I raised that questions the caching mechanism because once the cache is considered too old but the log list hasn't been updated, then every network request makes a network call to the remote log list and causes https://github.com/appmattus/certificatetransparency/issues/97 very easily.
If you wanted to try something, you could try using LogListDataSourceFactory.createDataSource
and change the last parameter to something like Instant.now().minus(14, ChronoUnit.DAYS)
so that the local cache does not expire so quickly and hopefully the remote log list is updated within 14 days. The default is 1 day which I think is not enough.
Hey π
First of all, thanks for all your work on the library and its maintenance π
I recently updated the library from v1.1.1 to v2.4.7 to be able to use the v3 log lists without any custom setup of the lib, and follow the latest developments. And since the app versions containing this update have spread to our production users, we spotted new reports of SSLPeerUnverifiedExceptions in Firebase reports.
Those reports only concern app versions containing the lib update and not previous app versions running with the v1.1.1: β¬οΈ
For the migration itself, I went from this (1.1.1 library version setup):
to this (2.4.7 library version setup)
when building the
OkHttpClient
of the app. This way to do follows what's described in the docs forOkHttp
setups: https://github.com/appmattus/certificatetransparency/blob/main/docs/okhttp.mdSo does it ring a bell to anyone? Should I setup the library differently, through
installCertificateTransparencyProvider
for example, to get better chances to avoid those failures?Thanks in advance for any help π