mbenlioglu / tor-cli Goto Github PK

Problem

     Encryption/decryption keys that are used by client and server may expire or revoked any time! Currently the system does not explicitly handles such situations, and most likely won't work on its own, which will require manual manipulation of keys on both client & server sides in case of such a case.

Proposition

• Add a key revocation scheme and overwrite expired/revoked keys with fresh ones. (Related to #6 )
• Check whether the keys in drive are updated, remove old key (don't just blatantly import what's there)
  • Need to be careful about security weaknesses here, make it clear what are we assuming
• Actively request fresh keys from either side. (which will require a daemon to listen and respond such requests)

Problem

     Client is not able to use some functionalities that are provided by internal torrent client (deluge). Some of which are pause, resume or remove a torrent. Need to discuss which of these should be available and how. (Might be implemented such that #2 can be resolved as well)

Although remote tool has support for multiple torrent downloading, local user cannot add and must wait for torrent to finish to add a new one

Problem

• The progress-bar in tracker shows the same percentage despite downloading.
• After downloading is finished, the tracker is not killing itself. And, if you want to download the second item, previous item's progress-bar is showing up.

We need a descriptive README

Problem

    Remote and Local scripts currently can't work on the same machine as their configurations will probably collide.

Question

    Should we think about their coexistence or prevent it completely?

Problem

• Option flags are used (or needs to be used but missing some cases) but not utilized correctly (e.g. usage output)
• Need a unifying script (with correct options) for remote and local instances, which will keep the issue #3 in mind

• Initial design contains many duplications and flaws which should be fixed

Problem

    Old keys from server, and/or clients with same email are not overwritten and may cause issues during encryption/decryption. Need to adapt a better key model.

Problem

    Due to lack of structure, generating a release is not trivial. Scripts for local and remote instances coexist in the same folders, and needs to be handpicked during release. (which also makes it hard for someone to build from repo)

Note: Consider issue #3 when redesigning