capitalization

7 files changed, 24 insertions, 24 deletions

diff --git a/ControlWindow.hs b/ControlWindow.hs
index e561017..5163a95 100644
--- a/ControlWindow.hs
+++ b/ControlWindow.hs
@@ -137,14 +137,14 @@ askToAllow ochan _ _ (UnSigned pk) = atomically $ writeTMChan ochan $
 	ControlOutputAction $ SessionKeyRejected pk
 askToAllow ochan promptchan responsechan k@(GpgSigned pk _) = do
 	putStrLn "Someone wants to connect to this debug-me session."
-	putStrLn "Checking their Gnupg signature ..."
+	putStrLn "Checking their GnuPG signature ..."
 	v <- gpgVerify [] k
 	case v of
 		Nothing -> do
-			putStrLn "Unable to download their Gnupg key, or signature verification failed."
+			putStrLn "Unable to download their GnuPG key, or signature verification failed."
 			reject
 		Just gpgkeyid -> flip catch woterror $ do
-			putStrLn "Checking the Gnupg web of trust ..."
+			putStrLn "Checking the GnuPG web of trust ..."
 			ss <- isInStrongSet gpgkeyid
 			ws <- downloadWotStats gpgkeyid
 			putStrLn $ describeWot ws ss
diff --git a/Role/Developer.hs b/Role/Developer.hs
index 51ada28..2cc6c1c 100644
--- a/Role/Developer.hs
+++ b/Role/Developer.hs
@@ -68,7 +68,7 @@ developer dsv ichan ochan sid = withSessionLogger (Just "remote") sid $ \logger
 			"(But, you can't type anything yet.)"
 		emitOutput startoutput
 		displayInControlWindow controlinput
-			"Waiting for the user to check your Gnupg key and grant write access ..."
+			"Waiting for the user to check your GnuPG key and grant write access ..."
 		authUser spk ichan ochan devstate logger
 			>>= go controlinput controloutput logger devstate
   where
diff --git a/debug-me.1 b/debug-me.1
index 8b39974..638f7d5 100644
--- a/debug-me.1
+++ b/debug-me.1
@@ -11,13 +11,13 @@ debugging fast, fun, and easy, by letting the developer access your
 computer remotely, so they can immediately see and interact with the
 problem. Making your problem their problem gets it fixed fast.
 .PP
-A debug-me session is logged and signed with the developer's Gnupg 
+A debug-me session is logged and signed with the developer's GnuPG 
 key, producing a chain of evidence of what they saw and what they did. 
 So the developer's good reputation is leveraged to make debug-me secure.
 .PP
 When you start debug-me without any options, it will connect to a debug-me
 server, and print out an url that you can give to the developer to get
-them connected to you. Then debug-me will show you their Gnupg key and who
+them connected to you. Then debug-me will show you their GnuPG key and who
 has signed it. If the developer has a good reputation, you can proceed
 to let them type into your console in a debug-me session. Once the
 session is done, the debug-me server will email you the signed
@@ -44,7 +44,7 @@ default server.
 .SH DEVELOPER OPTIONS
 .IP url
 Connect to a debug-me session on the specified url, to see and interact
-with the user's bug. You need a Gnupg key to use this.
+with the user's bug. You need a GnuPG key to use this.
 .IP "--watch url"
 Connect to a debug-me session on the specified url and display what
 happens in the session. Your keystrokes will not be sent to the session.
diff --git a/debug-me.cabal b/debug-me.cabal
index ffeefed..d3043a5 100644
--- a/debug-me.cabal
+++ b/debug-me.cabal
@@ -17,13 +17,13 @@ Description:
  so they can immediately see and interact with the problem. Making your
  problem their problem gets it fixed fast.
  .
- A debug-me session is logged and signed with the developer's Gnupg
+ A debug-me session is logged and signed with the developer's GnuPG
  key, producing a chain of evidence of what they saw and what they did.
  So the developer's good reputation is leveraged to make debug-me secure.
  .
  When you start debug-me without any options, it will connect to a debug-me
  server, and print out an url that you can give to the developer to get
- them connected to you. Then debug-me will show you their Gnupg key and who
+ them connected to you. Then debug-me will show you their GnuPG key and who
  has signed it. If the developer has a good reputation, you can proceed
  to let them type into your console in a debug-me session. Once the
  session is done, the debug-me server will email you the signed
diff --git a/doc/evidence.mdwn b/doc/evidence.mdwn
index 1b44ee0..ae1590b 100644
--- a/doc/evidence.mdwn
+++ b/doc/evidence.mdwn
@@ -3,10 +3,10 @@ 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
+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.
+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
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
diff --git a/doc/index.mdwn b/doc/index.mdwn
index 1051a53..25db3cd 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -17,13 +17,13 @@ debugging fast, fun, and easy, by letting the developer access your
 computer remotely, so they can immediately see and interact with the
 problem. Making your problem their problem gets it fixed fast.
 
-A debug-me session is logged and signed with the developer's Gnupg 
+A debug-me session is logged and signed with the developer's GnuPG 
 key, producing a chain of evidence of what they saw and what they did. 
 So the developer's good reputation is leveraged to make debug-me secure.
 
 When you start debug-me without any options, it will connect to a debug-me
 server, and print out an url that you can give to the developer to get
-them connected to you. Then debug-me will show you their Gnupg key and who
+them connected to you. Then debug-me will show you their GnuPG key and who
 has signed it. If the developer has a good reputation, you can proceed
 to let them type into your console in a debug-me session. Once the
 session is done, the debug-me server will email you the signed