summaryrefslogtreecommitdiffhomepage
path: root/doc/faq.mdwn
diff options
context:
space:
mode:
authorJoey Hess <joeyh@joeyh.name>2017-05-02 18:07:27 -0400
committerJoey Hess <joeyh@joeyh.name>2017-05-02 18:07:27 -0400
commite8e389a4bce4f9783ec5a0b57f89843ac00342da (patch)
treed6e7d69f89c539b19f88f610fad433f5bc1027d1 /doc/faq.mdwn
parent87e0e9cf517d2ca2f9dc1011d1924fb068db78e4 (diff)
downloaddebug-me-e8e389a4bce4f9783ec5a0b57f89843ac00342da.tar.gz
capitalization
Diffstat (limited to 'doc/faq.mdwn')
-rw-r--r--doc/faq.mdwn20
1 files changed, 10 insertions, 10 deletions
diff --git a/doc/faq.mdwn b/doc/faq.mdwn
index 155dd5f..c9b46ea 100644
--- a/doc/faq.mdwn
+++ b/doc/faq.mdwn
@@ -7,23 +7,23 @@
#### Should I let John Doe connect to my debug-me session? I don't know that guy.
When a developer connects to your debug-me session, it will display
-their Gnupg key, and the number of people who have signed it. It will
+their GnuPG key, and the number of people who have signed it. It will
also list the names of some of those people (the best connected ones).
If the developer of software you use is connecting to debug-me,
-their software documentation might say what their Gnupg key is. Then you
-can simply check that the Gnupg key ids match.
+their software documentation might say what their GnuPG key is. Then you
+can simply check that the GnuPG key ids match.
If debug-me says that "John Doe is probably a real person", it means
-that he's connected to the strong set of the Gnupg web of trust.
+that he's connected to the strong set of the GnuPG web of trust.
Other people, who certianly are real, have verified his identity.
So even if you don't know his name, it can be safe to let him connect.
But it's a gut call. If in doubt, don't let the developer connect.
-If debug-me says "identity cannot be verified!", it means that the Gnupg
+If debug-me says "identity cannot be verified!", it means that the GnuPG
key couldn't be downloaded at all, or the developer is not connected to the
-strong set of the Gnupg web of trust. Be super wary in this case.
+strong set of the GnuPG web of trust. Be super wary in this case.
#### I don't feel comfortable letting someone run commands on my computer. Can I still use debug-me?
@@ -45,7 +45,7 @@ debug-me to let them type, there would be a proof of anything bad they did.
#### How does debug-me prove when the developer uses it to do something bad?
The debug-me session log file records everything the developer saw and did
-in a debug-me session. Each keystroke they sent is signed with their Gnupg
+in a debug-me session. Each keystroke they sent is signed with their GnuPG
key, and is part of a signed chain of activities. By examining this
evidence, it can be cryptographically proven that the developer did what
they did.
@@ -60,11 +60,11 @@ make sure you get a copy.
Here's a quick checklist:
-* Make a Gnupg key, if you don't already have one.
+* Make a GnuPG key, if you don't already have one.
* Get it signed by at least one person who's connected to the strong
- set of the Gnupg web of trust. The more signatures the better.
+ set of the GnuPG web of trust. The more signatures the better.
Keysigning parties are great.
-* Include your Gnupg key id in your project's documentation, so users
+* Include your GnuPG key id in your project's documentation, so users
will know which key is yours. It also helps to sign git tags,
tarballs, git commits, etc with your key.
* When a user has a bug that you need more information to reproduce and