1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
A debug-me log file is evidence of what happened in a debug-me session.
It shows what the developer who connected to the server saw, and what the
developer did.
The log file uses an Ed25519 session key that is signed by the developer's
GnuPG key, so everything the developer did in the session is effectively
signed by their GnuPG key. It's impossible to generate a log file that
shows a developer doing something other than what they did, unless you
have the developer's GnuPG private key.
The log file is formatted as a series of JSON objects, and includes both
messages from the user's debug-me, and from the developer's debug-me. See
[[protocol]] for more details about the messages.
The important thing is that each message points to the SHA256 hash of a
previous message, which builds up a chain. This chain can be
verified by simply checking the hashes.
Use `debug-me --verify` to verify a debug-me log file. It will display
any GnuPG keys that signed session keys, and will verify all session key
signatures, and all hashes.
## graphing debug-me sessions
The chain of activities can be visualized by running `debug-me --graphviz
logfile`.
Here's an example. Reading down the graph, you'll see the shell started,
the developer typed "echo hi" and then saw the output of the command,
and then ended the session with control-d.
[[laggy.png]]
That debug-me session had some lag. In the middle of its
graph, you can see that the developer typed "h", and before that letter
echoed back, went on to type "o ". Thus, the chain splits to reflect the
different perspectives of the local and remote debug-me programs at that
point. Since they were able to agree on a resolution, the chain then
merges back together.
|
