groff 1.23.0 added .MR to its -man macro package. The NEWS file states
that the inclusion of the macro "was prompted by its introduction to
Plan 9 from User Space's troff in August 2020." From d32deab it seems
that the name for Plan 9 from User Space's implementation was suggested
by groff maintainer G. Brandon Robinson.
Not sure if the intention was to make these definitions compatible, but
it would be nice if they were.
Currently, Plan 9 from User Space's .MR expects its second argument to
be parenthesized. groff's .MR does not. This results in extra
parentheses appearing in manual references when viewing Plan 9 from User
Space's manual pages on a system using groff.
229 lines
3.9 KiB
Groff
229 lines
3.9 KiB
Groff
.TH SECSTORE 1
|
|
.SH NAME
|
|
aescbc, ipso, secstore \- secstore commands
|
|
.SH SYNOPSIS
|
|
.B secstore
|
|
[
|
|
.B -s
|
|
.I server
|
|
]
|
|
[
|
|
.B -(g|G)
|
|
.I getfile
|
|
]
|
|
[
|
|
.B -p
|
|
.I putfile
|
|
]
|
|
[
|
|
.B -r
|
|
.I rmfile
|
|
]
|
|
[
|
|
.B -c
|
|
]
|
|
[
|
|
.B -u
|
|
.I user
|
|
]
|
|
[
|
|
.B -v
|
|
]
|
|
[
|
|
.B -i
|
|
]
|
|
.PP
|
|
.B aescbc
|
|
-e
|
|
.I <cleartext
|
|
.I >ciphertext
|
|
.br
|
|
.B aescbc
|
|
-d
|
|
.I <ciphertext
|
|
.I >cleartext
|
|
.PP
|
|
.B ipso
|
|
[
|
|
.B -a -e -l -f
|
|
] [
|
|
.I file
|
|
\&...
|
|
]
|
|
.SH DESCRIPTION
|
|
.PP
|
|
.I Secstore
|
|
authenticates to the server
|
|
using a password and optionally a hardware token,
|
|
then saves or retrieves a file.
|
|
This is intended to be a credentials store (public/private keypairs,
|
|
passwords, and other secrets) for a factotum.
|
|
.PP
|
|
Option
|
|
.B -p
|
|
stores a file on the secstore.
|
|
.PP
|
|
Option
|
|
.B -g
|
|
retrieves a file to the local directory;
|
|
option
|
|
.B -G
|
|
writes it to standard output instead.
|
|
Specifying
|
|
.I getfile
|
|
of . will send to standard output
|
|
a list of remote files with dates, lengths and SHA1 hashes.
|
|
.PP
|
|
Option
|
|
.B -r
|
|
removes a file from the secstore.
|
|
.PP
|
|
Option
|
|
.B -c
|
|
prompts for a password change.
|
|
.PP
|
|
Option
|
|
.B -v
|
|
produces more verbose output, in particular providing a few
|
|
bits of feedback to help the user detect mistyping.
|
|
.PP
|
|
Option
|
|
.B -i
|
|
says that the password should be read from standard input
|
|
instead of from
|
|
.BR /dev/tty .
|
|
.PP
|
|
Option
|
|
.B -n
|
|
says that the password should be read from NVRAM
|
|
(see
|
|
.MR authsrv 3 )
|
|
instead of from
|
|
.BR /dev/tty .
|
|
.PP
|
|
The server is
|
|
.BR tcp!$auth!secstore ,
|
|
or the server specified by option
|
|
.BR -s .
|
|
.PP
|
|
For example, to add a secret to the file read by
|
|
.MR factotum 4 ,
|
|
run
|
|
.sp
|
|
.EX
|
|
% cd somewhere-private
|
|
% auth/secstore -g factotum
|
|
secstore password:
|
|
% echo 'key proto=apop dom=x.com user=ehg !password=hi' >> factotum
|
|
% auth/secstore -p factotum
|
|
secstore password:
|
|
% cat factotum | 9p write -l factotum/ctl
|
|
.EE
|
|
.PP
|
|
and delete the window.
|
|
The middle commands fetch the persistent copy of the secrets,
|
|
append a new secret,
|
|
and save the updated file back to secstore.
|
|
The final command loads the new secret into the running factotum.
|
|
.PP
|
|
The
|
|
.I ipso
|
|
command packages this sequence into a convenient script to simplify editing of
|
|
.I files
|
|
stored on a secure store.
|
|
It copies the named
|
|
.I files
|
|
into a private directory,
|
|
plumbs them to the editor,
|
|
and waits for a line on the console
|
|
Once a line is typed,
|
|
signifying that editing is complete,
|
|
.I ipso
|
|
prompts the user to confirm copying modifed or newly created files back to
|
|
.I secstore.
|
|
If no
|
|
.I file
|
|
is mentioned,
|
|
.I ipso
|
|
grabs all the user's files from
|
|
.I secstore
|
|
for editing.
|
|
.PP
|
|
By default, ipso will edit the
|
|
.I secstore
|
|
files and, if
|
|
one of them is named
|
|
.BR factotum ,
|
|
flush current keys from factotum and load
|
|
the new ones from the file.
|
|
If the
|
|
.BR -e ,
|
|
.BR -f ,
|
|
or
|
|
.BR -l
|
|
options are given,
|
|
.I ipso
|
|
will just perform only the requested operations, i.e.,
|
|
edit, flush, and/or load.
|
|
.PP
|
|
The
|
|
.B -a
|
|
option of
|
|
.I ipso
|
|
provides a similar service for files encrypted by
|
|
.I aescbc
|
|
.RI ( q.v. ).
|
|
With the
|
|
.B -a
|
|
option, the full rooted pathname of the
|
|
.I file
|
|
must be specified and all
|
|
.I files
|
|
must be encrypted with the same key.
|
|
Also with
|
|
.BR -a ,
|
|
newly created files are ignored.
|
|
.PP
|
|
.I Aescbc
|
|
encrypts and decrypts using AES (Rijndael) in cipher
|
|
block chaining (CBC) mode.
|
|
.SH SOURCE
|
|
.B \*9/bin/ipso
|
|
.br
|
|
.B \*9/src/cmd/auth/secstore
|
|
.SH SEE ALSO
|
|
.MR factotum 4 ,
|
|
.MR secstored 1
|
|
.SH BUGS
|
|
There is deliberately no backup of files on the secstore, so
|
|
.B -r
|
|
(or a disk crash) is irrevocable. You are advised to store
|
|
important secrets in a second location.
|
|
.PP
|
|
When using
|
|
.IR ipso ,
|
|
secrets will appear as plain text in the editor window,
|
|
so use the command in private.
|
|
.PP
|
|
Establishing a private directory in which to store the secret
|
|
files is difficult on Unix.
|
|
On most systems,
|
|
.I ipso
|
|
creates a mode 700 directory
|
|
.BI /tmp/ipso. user
|
|
and works there.
|
|
On Linux systems,
|
|
.I ipso
|
|
looks for a
|
|
.B tmpfs
|
|
file system; if it exists,
|
|
.I ipso
|
|
creates the
|
|
.BI ipso. user
|
|
directory in its root
|
|
instead of
|
|
.BR /tmp .
|
|
.PP
|
|
.I Ipso
|
|
should zero the secret files before removing them.
|