summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--bugs.txt69
1 files changed, 69 insertions, 0 deletions
diff --git a/bugs.txt b/bugs.txt
new file mode 100644
index 0000000..2ba2c68
--- /dev/null
+++ b/bugs.txt
@@ -0,0 +1,69 @@
1
2Expired Keys Bug
3================
4Currently, kiki does not convey the information that a key has expired.
5Suggest appending [Expired] to the end of the line.
6
7Q. What should happen if a master key expires but the subkey is still valid?
8Probably treat the subkey as if expired as well. OR at the very least remove
9the back arrows.
10
11
12Nest level (network level) on user id
13======================================
14Next to the word `signed', but before the colon, perhaps a number in parenthesis
15should be placed (0) indicates a signature of the working key, (1) implies it is
16signed by a key the working key signed. (2) it is signed by a key that was signed
17by a key that the working key has signed.
18
19Some symbol could be used for signatures that are completely outside of the web,
20(oo) perhaps. Where oo suggests the infinity symbol. It might also mean signatures
21greater than some predefined nest-level for efficiency reasons, so nest levels
22greater than say 5, for example, are treated as (oo).
23
24
25Orphaned subkeys
26================
27it is probably useful to track and convey information about keys that are not under
28the authority of any known master key. It is possible to treat such keys as masters
29or to treat them as subkeys, but as it is conventional that masters have uids and
30subkeys have usage tags, it may be preferable to treat an ssh key as a sub key.
31
32Another possibility is to treat them as both a master and a sub key, making duplicate
33entries in the keyring for the key. If this is done, then of course, we can treat them
34as if they are cross certified (<->).
35
36Whatever policy is adopted, it should keep in mind that the user may wish later on
37to reclassify said keys under a master, or to have them automatically reclassified
38when a master is imported which has a subkey which matches the orphan.
39
40Perhaps kiki should have the concept of a ghost master, where a user id is given, but
41there is no private, nor public key. Then later on if a master key is imported with the
42exact same user id, and it is signed by the working key, then all of the subkeys that are
43currently under the ghost can hop over to the new master. Back signatures will only show
44if they were also imported.
45
46User Interface
47==============
48Yet Another UI Proposal
49 *As stated in the kiki.txt proposal, kiki should have top level commands and then
50 options under those commands.
51
52 *Top level commands: show, sync-secret, import-public, export-public..
53
54 - The idea of this proposal is to keep the KEYSPEC notation, SPEC=file{SHELL_CMD}
55 but to use it across the board, on import as well as sync, and export.
56
57 - The difference between import and sync is merely whether the file being
58 imported is also updated or not. Export using a similar interface again
59 but only writing to the specified files, possibly appending, but never
60 adding information to the gpg keyrings.
61
62 - At some point the interface can be expanded with analogous sync-public and
63 import-secret, etc... there is a clear suggested place to put any new
64 functionality.
65
66 - Since import commands are not allowed to write to files, it makes little sense
67 to allow them to be created with SHELL_CMD. If that is what the user intends,
68 he can simply run SHELL_CMD manually and then run kiki using only the SPEC=file.
69