tmac: introduce real manual reference macro instead of overloading IR
The overloading of IR emits magic \X'...' sequences that turn into HTML manual links. But not all such IR invocations should be manual links; those had to be written to avoid the IR macro before. Worse, the \X'...' ending the IR causes troff to emit only a single space after a period. Defining a new IM macro for manual references fixes both problems. Fixes #441.
This commit is contained in:
Russ Cox
parent
a1c4307800
commit
977b25a76a
297 changed files with 1790 additions and 1774 deletions
|
|
@ -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
|
||||
.IM 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)),
|
||||
.IM 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)
|
||||
.IM 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))
|
||||
.IM 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)
|
||||
.IM 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)).
|
||||
.IM 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)).
|
||||
.IM authsrv (3) ).
|
||||
.PP
|
||||
The RPC protocol is normally embodied by one of the
|
||||
routines in
|
||||
.IR auth (3).
|
||||
.IM 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))
|
||||
.IM 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)).
|
||||
.IM 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);
|
||||
.IM 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)).
|
||||
.IM 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).
|
||||
.IM 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).
|
||||
.IM 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)
|
||||
.IM ssh-agent (1)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue