[WireGuard] [PATCH 2/4] explain "security reasons"

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

It's generally preferable to avoid vague "security reasons" if there
is a specific concern.

I think the reason we don't want the secret key material directly on
the command line is because of the command line's argument exposure in
the process table.

If there is another reason, i'd be happy to see a different patch
explaining it.
---
 src/tools/wg.8 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/tools/wg.8 b/src/tools/wg.8
index bffe58b..77e9b0d 100644
--- a/src/tools/wg.8
+++ b/src/tools/wg.8
@@ -55,7 +55,8 @@ Sets configuration values for the specified \fI<interface>\fP. Multiple
 for a peer, that peer is removed, not configured. If \fIlisten-port\fP
 is not specified, the port will be automatically generated when the
 interface comes up. Both \fIprivate-key\fP and \fIpreshared-key\fP must
-be a files, for security reasons, but if you're using
+be files to avoid exposing secret material via the process table's view
+of the command line.  However, if you're using
 .BR bash (1),
 you may safely pass in a string by specifying as \fIprivate-key\fP or
 \fIpreshared-key\fP the expression: <(echo PRIVATEKEYSTRING). If
-- 
2.8.1