Hi. It was surprising to me that, according to #756 , the "connect from other device" feature actually encrypts transferred account data with generated short password instead of using it for some kind of authentication and/or encryption key negotiation algorithm.
It would be much more safe to use one of Password-Authenticated Key Exchange (PAKE) algorithms. There is a working and pretty decent file transfer tool https://github.com/magic-wormhole/magic-wormhole you can use as a reference.
Why is it worth implementing:
(By the way, I was under impression that this feature was already implemented this way.)
https://monitor.f-droid.org/builds/log/cx.ring/301:
2021-06-15 05:29:38,977 INFO: Removing specified files
2021-06-15 05:29:38,977 ERROR: Could not build app cx.ring: glob path 'client-electron' did not match any files/dirs
2021-06-15 05:29:38,977 DEBUG: Error encoutered, stopping by user request.
As I can see in aptitude
package manager, the jami
package for Debian depends on libnm0
, but not on the network-manager
itself. I see it as a good approach, because it is not always desirable to have network-manager
itself being installed (because in some non-trivial setups it can actually break networking), while allowing integration when it is available.
531663d0e8ba1e4ad217fc7083fcb2918e47cc83
exits in https://git.jami.net/savoirfairelinux/ring-project.git, but it does not exist in https://review.jami.net/ring-project. The F-Droid package metadata points to https://review.jami.net/ring-project.
There is also no android/release_301
tag in https://review.jami.net/ring-project.
Yes, and as I can see, the build which happened afterwards failed. Or is that because of some other issue not mentioned here?
If I understood it right, the changes in d225a9a4 will not be grabbed by the F-Droid's auto update because there is no android/release_%c
tag pointing at it. Was that intended?