From 9e3041ef3933e2ead203d36e0c7dd4115002b67b Mon Sep 17 00:00:00 2001 From: James Crayne Date: Wed, 23 Apr 2014 22:11:10 -0400 Subject: bugs.txt --- bugs.txt | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 bugs.txt diff --git a/bugs.txt b/bugs.txt new file mode 100644 index 0000000..2ba2c68 --- /dev/null +++ b/bugs.txt @@ -0,0 +1,69 @@ + +Expired Keys Bug +================ +Currently, kiki does not convey the information that a key has expired. +Suggest appending [Expired] to the end of the line. + +Q. What should happen if a master key expires but the subkey is still valid? +Probably treat the subkey as if expired as well. OR at the very least remove +the back arrows. + + +Nest level (network level) on user id +====================================== +Next to the word `signed', but before the colon, perhaps a number in parenthesis +should be placed (0) indicates a signature of the working key, (1) implies it is +signed by a key the working key signed. (2) it is signed by a key that was signed +by a key that the working key has signed. + +Some symbol could be used for signatures that are completely outside of the web, +(oo) perhaps. Where oo suggests the infinity symbol. It might also mean signatures +greater than some predefined nest-level for efficiency reasons, so nest levels +greater than say 5, for example, are treated as (oo). + + +Orphaned subkeys +================ +it is probably useful to track and convey information about keys that are not under +the authority of any known master key. It is possible to treat such keys as masters +or to treat them as subkeys, but as it is conventional that masters have uids and +subkeys have usage tags, it may be preferable to treat an ssh key as a sub key. + +Another possibility is to treat them as both a master and a sub key, making duplicate +entries in the keyring for the key. If this is done, then of course, we can treat them +as if they are cross certified (<->). + +Whatever policy is adopted, it should keep in mind that the user may wish later on +to reclassify said keys under a master, or to have them automatically reclassified +when a master is imported which has a subkey which matches the orphan. + +Perhaps kiki should have the concept of a ghost master, where a user id is given, but +there is no private, nor public key. Then later on if a master key is imported with the +exact same user id, and it is signed by the working key, then all of the subkeys that are +currently under the ghost can hop over to the new master. Back signatures will only show +if they were also imported. + +User Interface +============== +Yet Another UI Proposal + *As stated in the kiki.txt proposal, kiki should have top level commands and then + options under those commands. + + *Top level commands: show, sync-secret, import-public, export-public.. + + - The idea of this proposal is to keep the KEYSPEC notation, SPEC=file{SHELL_CMD} + but to use it across the board, on import as well as sync, and export. + + - The difference between import and sync is merely whether the file being + imported is also updated or not. Export using a similar interface again + but only writing to the specified files, possibly appending, but never + adding information to the gpg keyrings. + + - At some point the interface can be expanded with analogous sync-public and + import-secret, etc... there is a clear suggested place to put any new + functionality. + + - Since import commands are not allowed to write to files, it makes little sense + to allow them to be created with SHELL_CMD. If that is what the user intends, + he can simply run SHELL_CMD manually and then run kiki using only the SPEC=file. + -- cgit v1.2.3