1 files changed, 36 insertions, 36 deletions
diff --git a/man/man4/factotum.4 b/man/man4/factotum.4
index 3a2d3d7c..02466fcf 100644
--- a/man/man4/factotum.4
+++ b/man/man4/factotum.4
@@ -10,7 +10,7 @@ factotum \- authentication agent
 ] [
 .B -s
 .I srvname
-] 
+]
 .\" [
 .\" .B -m
 .\" .I mtpt
@@ -79,7 +79,7 @@ same user id as it.  For select protocols such as
 it can also act as a client for other processes provided
 its user id may speak for the other process' user id (see
 Plan 9's
-\fIauthsrv\fR(6)).
+.IR authsrv (6)).
 .I Factotum
 can act in the role of server for any process.
 .PP
@@ -127,7 +127,7 @@ RSA encryption and signatures, used by SSH and TLS.
 passwords in the clear.
 .TP
 .B vnc
-.IR vnc (1)'s
+.MR vnc (1) 's
 challenge/response.
 .TP
 .B wep
@@ -186,7 +186,7 @@ cpu server.  On starting, it will attempt to get a
 key from NVRAM using
 .B readnvram
 (see
-.IR authsrv (3)),
+.MR authsrv (3) ),
 prompting for anything it needs.
 It will never subsequently prompt for a
 key that it doesn't have.
@@ -227,7 +227,7 @@ the kernel at boot time.
 .PP
 A
 .I "key tuple
-is a space delimited list of 
+is a space delimited list of
 .IB attribute = value
 pairs.  An attribute whose name begins with an exclamation point
 .RB ( ! )
@@ -245,7 +245,7 @@ specific to each supported protocol.
 .PP
 All keys can have additional attibutes that act either as comments
 or as selectors to distinguish them in the
-.IR auth (3)
+.MR auth (3)
 library calls.
 .PP
 The factotum owner can use any key stored by factotum.
@@ -305,9 +305,9 @@ such as
 and
 .B auth_challenge
 (see
-.IR auth (3))
+.MR auth (3) )
 to specify which key and protocol to use for an authentication.
-Like a key tuple, a key template is also a list of 
+Like a key tuple, a key template is also a list of
 .IB attribute = value
 pairs.
 It must specify at least the protocol and enough
@@ -367,7 +367,7 @@ turned on by the
 option.
 .PP
 By default when factotum starts it looks for a
-.IR secstore (1)
+.MR secstore (1)
 account on $auth for the user and, if one exists,
 prompts for a secstore password in order to fetch
 the file
@@ -385,11 +385,11 @@ sets a public/private keypair for ssh authentication,
 generated by
 .B ssh_genkey
 (see
-.IR ssh (1)).
+.MR ssh (1) ).
 .PD
 .SS "Confirming key use
 .PP
-The 
+The
 .B confirm
 file provides a connection from
 .I factotum
@@ -397,7 +397,7 @@ to a confirmation server, normally the program
 .IR auth/fgui .
 Whenever a key with the
 .B confirm
-attribute is used, 
+attribute is used,
 .I factotum
 requires confirmation of its use.  If no process has
 .B confirm
@@ -429,7 +429,7 @@ the same user id as
 .IR factotum .
 .SS "Prompting for keys
 .PP
-The 
+The
 .B needkey
 file provides a connection from
 .I factotum
@@ -481,11 +481,11 @@ RPC's) until done
 if successful, reading back an
 .I AuthInfo
 structure (see
-.IR authsrv (3)).
+.MR authsrv (3) ).
 .PP
 The RPC protocol is normally embodied by one of the
 routines in
-.IR auth (3).
+.MR auth (3) .
 We describe it here should anyone want to extend
 the library.
 .PP
@@ -545,7 +545,7 @@ necessary
 authentication has succeeded, an
 .B AuthInfo
 structure (see
-.IR auth (3))
+.MR auth (3) )
 can be retrieved with an
 .B authinfo
 RPC
@@ -621,7 +621,7 @@ is expected to be a long hexadecimal string.
 These are useful for manually debugging of binary protocols.
 .TP
 .B authinfo
-retrieve the AuthInfo structure.  
+retrieve the AuthInfo structure.
 The possible replies are:
 .RS
 .TP
@@ -661,7 +661,7 @@ with its own roles and required key attributes.
 and
 .I p9cr
 are used to authenticate to Plan 9 systems;
-valid 
+valid
 .BR role s
 are
 .B client
@@ -691,7 +691,7 @@ is a meta-protocol that negotiates a protocol
 .RB ( p9sk1
 or
 .BR p9sk2 )
-and an authentication domain and then invokes the 
+and an authentication domain and then invokes the
 given protocol with a
 .B dom=
 attribute.
@@ -703,7 +703,7 @@ and
 are intended to be proxied via
 .I auth_proxy
 (see
-.IR auth (3)).
+.MR auth (3) ).
 .\" The protocols follow
 .\" .IR p9any (7)
 .\" and
@@ -736,7 +736,7 @@ before being sent over the network.
 .PP
 .I Vnc
 is the challenge-response protocol used by
-.IR vnc (1);
+.MR vnc (1) ;
 valid roles are
 .B client
 and
@@ -746,7 +746,7 @@ The client protocol requires a
 key with attribute
 .BR !password .
 Conventionally, client keys also have
-.B user 
+.B user
 and
 .B server
 attributes.
@@ -763,7 +763,7 @@ except that the challenge and response are not textual.
 and
 .I cram
 are challenge-response protocols typically
-used to authenticate 
+used to authenticate
 to mail servers.
 The client protocols require
 .B proto=apop
@@ -774,7 +774,7 @@ keys with
 and
 .B !password
 attributes.
-Conventionally, client keys also have 
+Conventionally, client keys also have
 .B server
 attributes.
 The server protocol requires a
@@ -828,7 +828,7 @@ structure (defined in
 .PP
 .I Pass
 is a client-only protocol that hands out passwords
-from 
+from
 .B proto=pass
 keys with
 .B user
@@ -840,7 +840,7 @@ a string: a space-separated quoted user name and password
 that can be parsed with
 .I tokenize
 (see
-.IR getfields (3)).
+.MR getfields (3) ).
 Conventionally, client keys have distinguishing attributes
 like
 .B service
@@ -860,7 +860,7 @@ keys with
 .BR !key2 ,
 or
 .B !key3
-attributes.  
+attributes.
 The protocol with
 .I factotum
 is:
@@ -873,7 +873,7 @@ opens the device's control file, sets the wireless secret using the key,
 and turns on encryption.
 If the key has an
 .B essid
-attribute, 
+attribute,
 .I factotum
 uses it to set the wireless station ID.
 .PP
@@ -891,7 +891,7 @@ uses
 keys with
 .B ek
 and
-.B n 
+.B n
 attributes, large integers specifying the public half
 of the key.
 If a key is to be used for decryption or signing,
@@ -905,13 +905,13 @@ and
 .BR !dk
 specifying the private half of the key;
 see
-.IR rsa (3).
+.MR rsa (3) .
 Conventionally,
 .I rsa
 keys also have
 .B service
 attributes specifying the context in which the key is used:
-.B ssh 
+.B ssh
 (SSH version 1),
 .B ssh-rsa
 (SSH version 2),
@@ -946,7 +946,7 @@ and
 The hash function must be known to
 .I factotum
 because the signature encodes the type of hash used.
-The 
+The
 .B encrypt
 and
 .B verify
@@ -972,11 +972,11 @@ attributes.
 If the key is to be used for signing, it must also have a
 .B !secret
 attribute; see
-.IR dsa (3).
+.MR dsa (3) .
 Conventionally,
 .I dsa
 keys
-also have 
+also have
 .B service
 attributes specifying the context in which the key is used:
 .B ssh-dss
@@ -992,7 +992,7 @@ Unlike
 .IR rsa ,
 the
 .I dsa
-protocol ignores the 
+protocol ignores the
 .B hash
 attribute; it always uses SHA1.
 .PP
@@ -1019,4 +1019,4 @@ The response is a hexadecimal string of length 32.
 .SH SOURCE
 .B \*9/src/cmd/auth/factotum
 .SH SEE ALSO
-.IR ssh-agent (1)
+.MR ssh-agent (1)