arc4random: Replace memset(3) with explicit_bzero(3)
As far as I can tell, all of the calls to memset(3) in
lib/libc/crypt/arc4random.c are intended to wipe memory to avoid having
the randomly generated data in memory twice, so it would seem good
practice to use explicit_bzero(3) to avoid this being optimized out.
Index: lib/libc/crypt/arc4random.c
===
RCS file: /cvs/src/lib/libc/crypt/arc4random.c,v
retrieving revision 1.55
diff -u -p -r1.55 arc4random.c
--- lib/libc/crypt/arc4random.c 24 Mar 2019 17:56:54 - 1.55
+++ lib/libc/crypt/arc4random.c 19 Dec 2019 12:51:23 -
@@ -98,7 +98,7 @@ _rs_stir(void)
/* invalidate rs_buf */
rs->rs_have = 0;
- memset(rsx->rs_buf, 0, sizeof(rsx->rs_buf));
+ explicit_bzero(rsx->rs_buf, sizeof(rsx->rs_buf));
rs->rs_count = 160;
}
@@ -119,7 +119,7 @@ static inline void
_rs_rekey(u_char *dat, size_t datlen)
{
#ifndef KEYSTREAM_ONLY
- memset(rsx->rs_buf, 0, sizeof(rsx->rs_buf));
+ explicit_bzero(rsx->rs_buf, sizeof(rsx->rs_buf));
#endif
/* fill rs_buf with the keystream */
chacha_encrypt_bytes(>rs_chacha, rsx->rs_buf,
@@ -134,7 +134,7 @@ _rs_rekey(u_char *dat, size_t datlen)
}
/* immediately reinit for backtracking resistance */
_rs_init(rsx->rs_buf, KEYSZ + IVSZ);
- memset(rsx->rs_buf, 0, KEYSZ + IVSZ);
+ explicit_bzero(rsx->rs_buf, KEYSZ + IVSZ);
rs->rs_have = sizeof(rsx->rs_buf) - KEYSZ - IVSZ;
}
@@ -152,7 +152,7 @@ _rs_random_buf(void *_buf, size_t n)
keystream = rsx->rs_buf + sizeof(rsx->rs_buf)
- rs->rs_have;
memcpy(buf, keystream, m);
- memset(keystream, 0, m);
+ explicit_bzero(keystream, m);
buf += m;
n -= m;
rs->rs_have -= m;
@@ -172,7 +172,7 @@ _rs_random_u32(uint32_t *val)
_rs_rekey(NULL, 0);
keystream = rsx->rs_buf + sizeof(rsx->rs_buf) - rs->rs_have;
memcpy(val, keystream, sizeof(*val));
- memset(keystream, 0, sizeof(*val));
+ explicit_bzero(keystream, sizeof(*val));
rs->rs_have -= sizeof(*val);
}
Re: openssl.1: note default -md value for openssl enc and how to get list of available hashes
On 12/18/19 5:46 AM, Theo Buehler wrote:
> The diff modifies the CA section, not ENC. I need to check if we can
> do something about the weak defaults there, but the diff is not
> correct.
That's my bad.
New diff inline.
> For ENC, it's indeed correct that the default was changed from md5 to
> sha256, and this should be updated. However, I'm not sure that we
> should add a list-message-digest-algorithms reference. I'd just note
> that the default is sha256 and be done with it.
The reason why I added list-message-digest-algorithms was to keep the
intention of the original part that said "Digest may be one of [...]":
a list of valid options.
However, the list is liable to expand and best practices are liable to
change, so I wanted to resolve that with a dynamic reference to
list-message-digest-algorithms instead.
Now I've just removed that part in hopes that introduction at the top of
openssl.1 makes this clear enough.
>> Inspired by a conversation on misc@ a few weeks ago ("LibreSSL vs.
>> OpenSSL enc command").
>> Perhaps it's also worthwhile to have a HISTORY section/subsection or
>> historical note about this since it's probably of interoperability
>> concern for older files.
>
> Yes, the question of how to decrypt files that were encrypted with md5
> as a digest comes up from time to time on the lists. Not convinced
> that a HISTORY section would help that. The appropriate place would
> have been an upgrade note, but the opportunity was missed...
My reason for proposing that is a fear that people will still find years
old or even decades old files much later on, forgetting or not realizing
that they need to change -md.
Having a note in the man page would help that specific scenario.
The format of the man page doesn't lend itself to doing so, however.
Index: usr.bin/openssl/openssl.1
===
RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
retrieving revision 1.116
diff -u -p -r1.116 openssl.1
--- usr.bin/openssl/openssl.1 28 Nov 2019 11:21:33 - 1.116
+++ usr.bin/openssl/openssl.1 18 Dec 2019 05:16:10 -
@@ -2176,11 +2176,8 @@ option.
Use
.Ar digest
to create a key from a pass phrase.
-.Ar digest
-may be one of
-.Cm md5
-or
-.Cm sha1 .
+The default value is
+.Cm sha256 .
.It Fl none
Use NULL cipher (no encryption or decryption of input).
.It Fl nopad
openssl.1: note default -md value for openssl enc and how to get list of available hashes
This diff changes the documentation of openssl(1) enc to note the
default value (sha256) and replace the "hardcoded" list of md5, sha1
with instructions to use list-message-digest-algorithms instead.
Inspired by a conversation on misc@ a few weeks ago ("LibreSSL vs.
OpenSSL enc command").
Perhaps it's also worthwhile to have a HISTORY section/subsection or
historical note about this since it's probably of interoperability
concern for older files.
Index: usr.bin/openssl/openssl.1
===
RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
retrieving revision 1.116
diff -u -p -r1.116 openssl.1
--- usr.bin/openssl/openssl.1 28 Nov 2019 11:21:33 - 1.116
+++ usr.bin/openssl/openssl.1 16 Dec 2019 18:09:54 -
@@ -416,10 +416,10 @@ The default is
.Cm pem .
.It Fl md Ar alg
The message digest to use.
-Possible values include
-.Ar md5
-and
-.Ar sha1 .
+A list of possible values can be obtained with the pseudo-command
+.Cm list-message-digest-algorithms .
+The default value is
+.Ar sha256 .
This option also applies to CRLs.
.It Fl msie_hack
This is a legacy option to make
ppt.6: HISTORY: Command seems to have existed since V7
ppt(6) seems to have had an interesting history. It seems to have been mentioned in the V1 manual as ppt(I), seemingly actually doing something related to paper tape. Then it vanished as far as I could tell. In V7, it seems to have found its current form as a game and got documented on bcd(6) (https://man.openbsd.org/UNIX-7/bcd.6); the bcd game itself shipped with V6 already, but had no man page. However, as far as I can tell, V7 shipped only with binaries for ppt(6), not with source code; 4.3BSD-Tahoe was technically the first source code version of it and presumably a rewrite. This patch adjusts the HISTORY section to match these findings. Index: games/ppt/ppt.6 === RCS file: /cvs/src/games/ppt/ppt.6,v retrieving revision 1.2 diff -u -p -r1.2 ppt.6 --- games/ppt/ppt.6 18 Nov 2014 02:25:12 - 1.2 +++ games/ppt/ppt.6 11 Oct 2019 16:39:55 - @@ -68,10 +68,10 @@ is printed for undecipherable input line .%R "ECMA Standard for Data Interchange on Punched Tape" .Re .Sh HISTORY -The +A .Nm command first appeared in -.Bx 4.3 Tahoe . +.At v7 . The options .Fl d and
proot.1: Formatting fix
This patch fixes a newline in proot.1 preventing LOCKDIR from being rendered correctly. Note that this causes the input line to be very long, which seemed okay to me because dhcp-options.5 does the same (e.g. on line 184). Index: share/man/man1/proot.1 === RCS file: /cvs/src/share/man/man1/proot.1,v retrieving revision 1.4 diff -u -p -u -p -r1.4 proot.1 --- share/man/man1/proot.1 29 May 2019 19:37:06 - 1.4 +++ share/man/man1/proot.1 8 Jun 2019 10:07:31 - @@ -225,8 +225,7 @@ directory containing the base sets. .It All the ports specific sub directories if they are defined, namely -.Cm DISTDIR , WRKOBJDIR, LOGDIR, PACKAGE_REPOSITORY , PLIST_REPOSITORY , -LOCKDIR. +.Cm DISTDIR , WRKOBJDIR, LOGDIR, PACKAGE_REPOSITORY , PLIST_REPOSITORY , LOCKDIR . .It The .Cm PORTSDIR
kqueue.2: formatting fixes and minor HISTORY expansion
I've taken a stab at improving kqueue.2 formatting.
Most of the changes are markup fixes.
I used ".Dv NULL" over plain "null" in accordance with
lib/libc/stdlib/malloc.3 rev. 1.113.
I also added a note to the HISTORY section that kqueue()/kevent() have
been available in OpenBSD since 2.9;
the wording matches growfs(8).
I'm not sure how to handle the undocumented EPERM that is returned if a
pledge(2) does not include "proc" when an attempt is made to attach to a
process with EVFILT_PROC.
It does feel somewhat non-obvious, but is noted in neither pledge(2) nor
kqueue(2).
Index: lib/libc/sys/kqueue.2
===
RCS file: /cvs/src/lib/libc/sys/kqueue.2,v
retrieving revision 1.37
diff -u -p -u -p -r1.37 kqueue.2
--- lib/libc/sys/kqueue.2 13 Jan 2018 17:13:12 - 1.37
+++ lib/libc/sys/kqueue.2 2 May 2019 13:28:27 -
@@ -67,9 +67,9 @@ is not returned.
Multiple events which trigger the filter do not result in multiple
kevents being placed on the kqueue; instead, the filter will aggregate
the events into a single
-.Li struct kevent .
+.Vt struct kevent .
Calling
-.Fn close
+.Xr close 2
on a file descriptor will remove any kevents that reference the descriptor.
.Pp
.Fn kqueue
@@ -83,8 +83,8 @@ is used to register events with the queu
events to the user.
.Fa changelist
is a pointer to an array of
-.Va kevent
-structures, as defined in
+.Vt struct kevent ,
+as defined in
.In sys/event.h .
All changes contained in the
.Fa changelist
@@ -107,19 +107,23 @@ specified unlike
.Xr select 2 .
If
.Fa timeout
-is a non-null pointer, it specifies a maximum interval to wait
+is not
+.Dv NULL ,
+it specifies a maximum interval to wait
for an event, which will be interpreted as a
-.Li struct timespec .
+.Vt struct timespec .
If
.Fa timeout
-is a null pointer,
+is
+.Dv NULL ,
.Fn kevent
waits indefinitely.
To effect a poll, the
.Fa timeout
-argument should be non-null, pointing to a zero-valued
-.Va timespec
-structure.
+argument should not be
+.Dv NULL ,
+pointing to a zero-valued
+.Vt struct timespec .
The same array may be used for the
.Fa changelist
and
@@ -130,7 +134,7 @@ is a macro which is provided for ease of
kevent structure.
.Pp
The
-.Va kevent
+.Vt kevent
structure is defined as:
.Bd -literal
struct kevent {
@@ -144,28 +148,28 @@ struct kevent {
.Ed
.Pp
The fields of
-.Li struct kevent
+.Vt struct kevent
are:
.Bl -tag -width XXXfilter
-.It ident
+.It Fa ident
Value used to identify this event.
The exact interpretation is determined by the attached filter,
but often is a file descriptor.
-.It filter
+.It Fa filter
Identifies the kernel filter used to process this event.
The pre-defined system filters are described below.
-.It flags
+.It Fa flags
Actions to perform on the event.
-.It fflags
+.It Fa fflags
Filter-specific flags.
-.It data
+.It Fa data
Filter-specific data value.
-.It udata
+.It Fa udata
Opaque user-defined value passed through the kernel unchanged.
.El
.Pp
The
-.Va flags
+.Fa flags
field can contain the following values:
.Bl -tag -width XXXEV_ONESHOT
.It Dv EV_ADD
@@ -200,7 +204,7 @@ to return with
.Dv EV_ERROR
set without draining any pending events after updating events in the kqueue.
When a filter is successfully added the
-.Va data
+.Fa data
field will be zero.
This flag is useful for making bulk changes to a kqueue.
.It Dv EV_ONESHOT
@@ -222,9 +226,9 @@ below.
.Pp
The predefined system filters are listed below.
Arguments may be passed to and from the filter via the
-.Va fflags
+.Fa fflags
and
-.Va data
+.Fa data
fields in the kevent structure.
.Bl -tag -width EVFILT_SIGNAL
.It Dv EVFILT_READ
@@ -235,9 +239,9 @@ on the descriptor type.
.Bl -tag -width 2n
.It Sockets
Sockets which have previously been passed to
-.Fn listen
+.Xr listen 2
return when there is an incoming connection pending.
-.Va data
+.Fa data
contains the size of the listen backlog.
.Pp
Other socket descriptors return when there is data to be read,
@@ -248,47 +252,47 @@ This may be overridden with a per-filter
time the filter is added by setting the
.Dv NOTE_LOWAT
flag in
-.Va fflags ,
+.Fa fflags ,
and specifying the new low water mark in
-.Va data .
+.Fa data .
On return,
-.Va data
+.Fa data
contains the number of bytes in the socket buffer.
.Pp
If the read direction of the socket has shutdown, then the filter
also sets
.Dv EV_EOF
in
-.Va flags ,
+.Fa flags ,
and returns the socket error (if any) in
-.Va fflags .
+.Fa fflags .
It is possible for EOF to be returned (indicating the connection is gone)
while there is still data pending in the socket buffer.
.It Vnodes
Returns when the file pointer is not at the end of file.
-.Va data
+.Fa data
contains the offset from current position to end of file,
and may be negative.
If
.Dv NOTE_EOF
is set in
-.Va fflags ,
+.Fa fflags ,
.Fn kevent
will also return when the file pointer is at the end of file.
The end of file
Re: acme-client.1: update STANDARDS
On 4/24/19 4:15 PM, Florian Obser wrote: > On Wed, Apr 24, 2019 at 09:34:57AM -0400, Bryan Steele wrote: >> On Wed, Apr 24, 2019 at 03:08:59PM +0200, Fabio Scotoni wrote: >>> [...] >> >> Isn't RF C8555 ACMEv2? acme-client(1) only supports ACMEv1, so I don't >> think this is correct. >> > > Indeed, this is not correct. > Oops, my bad. It seemed more straightforward than it was. I apologize for the noise caused by my bogus diff; please disregard it. Fabio
acme-client.1: update STANDARDS
This diff updates the acme-client(1) STANDARDS section. Currently, it lists an RFC draft for the ACME protocol. Since March of this year, there is a proposed standard with an actual RFC number. While at it, make the format match ssh(1) STANDARDS by providing .%A and .%D entries. Index: usr.sbin/acme-client/acme-client.1 === RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v retrieving revision 1.29 diff -u -p -u -p -r1.29 acme-client.1 --- usr.sbin/acme-client/acme-client.1 3 Feb 2019 20:39:35 - 1.29 +++ usr.sbin/acme-client/acme-client.1 24 Apr 2019 13:05:10 - @@ -145,7 +145,12 @@ is reloaded: .Xr httpd.conf 5 .Sh STANDARDS .Rs -.%U https://tools.ietf.org/html/draft-ietf-acme-acme-03 +.%A R. Barnes +.%A J. Hoffman-Andrews +.%A D. McCarney +.%A J. Kasten +.%D March 2019 +.%R RFC 8555 .%T Automatic Certificate Management Environment (ACME) .Re .Sh HISTORY
Re: new man page: rcsfile.5
Dear Ingo, On 4/23/19 9:30 PM, Ingo Schwarze wrote: >>> Index: rcsfile.5 > [...] >>> +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >>> +.\" > >> Nitpick: The other man pages in the usr.bin/rcs/ tree do not have a >> trailing .\" -- except for rcs(1). >> You may wish to make this consistent this one way or another, >> likely in a separate commit. > > I put the .\" here because i guess that's the more usual way in > OpenBSD, but it's not important enough for changing it in existing > pages. > > [...] Duly noted. I wonder if it might be worth noting that somewhere, though I'm not sure where. >>> +.Bl -tag -width Ds >>> +.It Ic date Ar . Ar mm . Ar dd . Ar HH . Ar MM . Ar SS > >> Are you sure you want to do this without Pf/Ns? >> You may have inadvertently introduced spaces here and > > Oops, indeed, thanks for catching that. > Fixed in my tree: > > .It Ic date Ar . Ns Ar mm . Ns Ar dd . Ns Ar HH . Ns Ar MM . Ns Ar SS > >> Maybe this should be [YY]YY because two-digit years do exist. > > I think the > > Oo Ar YY Oc Ns Ar YY . > > which that would require would be even more complicated than what > is there now. The can be considered a placeholder, and the > text already makes it clear that the actual value can be shorter. Works for me. With these changes, rcsfile.5 looks okay to me now. Thank you for your patience. Fabio
Re: new man page: rcsfile.5
On 4/23/19 7:15 PM, Ingo Schwarze wrote: >>> At the top of the file, a Copyright notice and license is missing. >>> Please conisder using /usr/share/misc/license.template with the >>> comment markers changed to .\" . > >> I intentionally skipped on adding the copyright notice and license >> because I felt it would be presumptuous -- I wanted to keep open >> the option of a copyright assignment to an OpenBSD contributor open >> in case the OpenBSD project wished for it, just in case. > > If you weren't a lawyer, i would feel tempted to suspect that you > misunderstood how Copyright works in general. As things stand, i > may be misunderstanding what you intend to say here. Either way, > i suspect you misunderstand how ownership of intellectual property > works in OpenBSD in particular. For the sake of correctness I must state that I'm not a lawyer; however, I do have a law degree from a Swiss university (master of law). > By international law (Berne Convention), you cannot give away Copyright. > Copyright always resides with the natural person who is the original > creator of a Work. It is inalienable. The "Copyright" line is merely > a statement of fact. > > Is it correct that you wrote all the text in the file? > If so, your name needs to be there. It is indeed correct that I wrote all the text in the file (except, by definition, your suggestions). > According to the Berne Convention, even though you cannot give away > the moral rights that constitute the core of Copyright, you can give > away the economic rights arising from a Work. Some publishers of > software (for example the FSF) ask for that. But in OpenBSD, we > strongly encourage original authors to retain all economic rights > arising from their Works, and simply grant a standardized license > themselves, such that OpenBSD can distribute the Works. Thank you for clarifying. Since I wasn't aware how documentation (and code) from outsiders contributing to OpenBSD would be treated, I figured I should err on the side of caution and not grant any license in the initial publication. Requests with regards to assignment of rights could have been possible, after all. Granting the economic rights becomes somewhat meaningless if there is a pre-existing liberal license and you had wished that the rights had been granted exclusively to a single entity. > The OpenBSD > project doesn't own any rights and isn't even a legal entity. (That's why I said "to an OpenBSD contributor", not "to the OpenBSD project" in my previous e-mail, actually.) Some nitpicks in the diff follow. > Index: Makefile > === > RCS file: /cvs/src/usr.bin/rcs/Makefile,v > retrieving revision 1.40 > diff -u -p -r1.40 Makefile > --- Makefile 15 Oct 2010 08:44:12 - 1.40 > +++ Makefile 23 Apr 2019 17:04:55 - > @@ -1,7 +1,9 @@ > #$OpenBSD: Makefile,v 1.40 2010/10/15 08:44:12 tobias Exp $ > > PROG=rcs > -MAN= ci.1 co.1 ident.1 merge.1 rcs.1 rcsclean.1 rcsdiff.1 rcsmerge.1 rlog.1 > +MAN= ci.1 co.1 ident.1 merge.1 \ > + rcs.1 rcsclean.1 rcsdiff.1 rcsmerge.1 rlog.1 \ > + rcsfile.5 > > SRCS=ci.c co.c ident.c merge.c rcsclean.c rcsdiff.c rcsmerge.c > rcsparse.c \ > rcsprog.c rlog.c rcsutil.c buf.c date.y diff.c diff3.c rcs.c rcsnum.c \ > Index: rcsfile.5 > =========== > RCS file: rcsfile.5 > diff -N rcsfile.5 > --- /dev/null 1 Jan 1970 00:00:00 - > +++ rcsfile.5 23 Apr 2019 17:04:55 - > @@ -0,0 +1,154 @@ > +.\" $OpenBSD$ > +.\" > +.\" Copyright (c) 2019 Fabio Scotoni > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" Nitpick: The other man pages in the usr.bin/rcs/ tree do not have a trailing .\" -- except for rcs(1). You may wish to make this consistent this one way or another, likely in a separate commit. >
Re: new man page: rcsfile.5
Dear Ingo, Thank you for your insightful suggestions, which I've incorporated. On 4/23/19 2:52 PM, Ingo Schwarze wrote: > I think the source should go to /usr/src/usr.bin/rcs/rcs.5 > and it should be installed to /usr/share/man/man5/rcs.5. I've adjusted the updated man page (inline) .Dt and .Nm to match this. However, I would advise you not to. rcs(5) may be surprising for anyone coming from the other implementations of single-file version control systems: - GNU RCS ships rcsfile(5), and - all versions of SCCS ship sccsfile(4) (even Schily and BitKeeper). > [...] > > At the top of the file, a Copyright notice and license is missing. > Please conisder using /usr/share/misc/license.template with the > comment markers changed to .\" . I intentionally skipped on adding the copyright notice and license because I felt it would be presumptuous -- I wanted to keep open the option of a copyright assignment to an OpenBSD contributor open in case the OpenBSD project wished for it, just in case. Added in the updated man page inline, including the $OpenBSD$ keyword at the top. Your suggestions and/or subsequent in-tree changes may warrant a copyright notice of your own. > Please avoid inventing names that don't actually appear in the file. > I suggest using: > > [...] I ended up going with the .Ss variant because the man page is short enough that a table of contents of sorts is unnecessary. > I'd prefer "Ic head" (and similarly in the following) because "head" > is a stand-alone keyword, not an argument to something else. ,s/Cm/Ic/g performed. Thank you for clarifying. The relationship between Cm and Ic hasn't been clear to me, especially since mdoc(7) says that Cm is "[a]lso useful when specifying configuration options or keys". UTC time and cvs(1) reference incorporated. The UTC time actually made me double check the date parser; historical RCS files do have two-digit years after all. The respective text has been updated to match. (At least they're UTC unlike stock SCCS, which uses local time with no timezone information anywhere in the file.) .\" $OpenBSD$ .\" .\" Copyright (c) 2019 Fabio Scotoni .\" .\" Permission to use, copy, modify, and distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" .\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .Dd $Mdocdate$ .Dt RCS 5 .Os .Sh NAME .Nm rcs .Nd format of an RCS file .Sh DESCRIPTION An RCS file is a text file. It consists of four sections, each separated by two empty lines. RCS files should not be edited by hand; the .Xr rcs 1 programs should be used instead. .Ss Administrative data The RCS file begins with admin data. Each entry in this section consists of either one or multiple values. Entries that take one value are specified on one line: The keyword and its corresponding value are separated by a tab character. Entries that take multiple values begin with a keyword on one line; the values are specified on subsequent lines, one per line and prefixed with a tab character. If the list is empty, the semicolon immediately follows the keyword. Entries are terminated with a semicolon. The entries are: .Bl -tag -width Ds .It Ic head Ar rev Highest revision number. .It Ic branch Ar rev Revision number that specifies the default branch (optional). .It Ic access List of users that are allowed to check in new revisions with .Xr ci 1 . This keyword is not followed by a tab; instead, the list of users is specified with one username per line. The list is terminated by a single semicolon. .It Ic symbols List of symbolic names used as aliases for specific revisions. Each entry consists of a symbolic name followed by a colon and the revision. .It Ic locks List of locked revisions. Each entry consists of a username followed by a colon and the locked revision. .It Ic strict Indicates that locks are strict; if missing, locks are not strict. This entry takes no value and immediately follows the list of locks without a newline. .It Ic comment @ Ns Ar leader Ns Ic @ Contains the comment leader surrounded by at signs. .It Ic expand @ Ns Ar mode Ns Ic @ Indicates the keyword substitution mode. See .Xr rcs 1 for the possible keyword substitution modes. If this entry is not given in the admin section, .Ar kv must be assumed. .El .Ss List of d
new man page: rcsfile.5
While familiarizing myself with OpenRCS, I noticed that there's no rcsfile(5). This may be handy for people whose RCS file got corrupted for whatever reasons. Other *NIXes that ship SCCS tend to have a sccsfile(4), so I figured it could be worthwhile to have something of that nature for OpenRCS. Feedback would be appreciated, as would be proofreading by someone who's done more work with RCS files than I have. .Dd $Mdocdate$ .Dt RCSFILE 5 .Os .Sh NAME .Nm rcsfile .Nd format of an RCS file .Sh DESCRIPTION An RCS file is a text file. It consists of multiple sections, each separated by two empty lines. RCS files should not be edited by hand; the RCS programs should be used instead. .Pp The RCS file consists of four sections: .Bl -tag -width "deltatexts" -compact .It admin Administrative data about the RCS file itself. .It deltas List of deltas, i.e. metadata about changes. .It desc A description of what the file. .It deltatexts List of the changes made by each delta. .El .Pp The RCS file begins with admin data. Each entry in this section consists of either one or multiple values. Entries that take one value are specified on one line: The keyword and its corresponding value are separated by a tab character. Entries that take multiple values begin with a keyword on one line; the values are specified on subsequent lines, one per line and prefixed with a tab character. If the list is empty, the semicolon immediately follows the keyword. Entries are terminated with a semicolon. The entries are: .Bl -tag -width Ds .It Cm head Ar rev Highest revision number. .It Cm branch Ar rev Revision number that specifies the default branch (optional). .It Cm access List of users that are allowed to check in new revisions with .Xr ci 1 . This keyword is not followed by a tab; instead, the list of users is specified with one username per line. The list is terminated by a single semicolon. .It Cm symbols List of symbolic names used as aliases for specific revisions. Each entry consists of a symbolic name followed by a colon and the revision. .It Cm locks List of locked revisions. Each entry consists of a username followed by a colon and the locked revision. .It Cm strict Indicates that locks are strict; if missing, locks are not strict. This entry takes no value and immediately follows the list of locks without a newline. .It Cm comment @ Ns Ar leader Ns Cm @ Contains the comment leader surrounded by at signs. .It Cm expand @ Ns Ar mode Ns Cm @ Indicates the keyword substitution mode. See .Xr rcs 1 for the possible keyword substitution modes. If this entry is not given in the admin section, .Ar kv must be assumed. .El .Pp The RCS file continues with a list of deltas. Deltas are separated by empty lines. The list begins with the head and ends with the initial revision. Each entry begins with the revision number, followed by a newline. After that, the structure follows the admin section. .Bl -tag -width Ds .It Cm date Ar .mm.dd.HH.MM.SS Indicates the date and time the revision was checked in. The date consists of the year, the month, the day of month, the hour, the minute and the second, each separated by dots. The year is specified in four digits, the other values are specified in two digits each. .It Cm author Ar username Author's username. This entry immediately follows the .Cm date without a newline. .It Cm state Ar value Contains the state of this delta, which is an arbitrary string. This entry immediately follows the .Cm author without a newline. .It Cm branches List of revision numbers that are branches stemming from this delta. .It Cm next Ar rev Next revision. Chronologically, this is the .Em previous revision. For the initial check-in, .Ar rev is empty, but the tab character that acts as separator is nonetheless present. .El .Pp The RCS file continues with the description. It consists of the string .Cm desc followed by a newline and then an at sign. The description is an arbitrary string that can span multiple lines. A single at sign on a line terminates the description. At signs anywhere in the description itself are escaped by prefixing them with another at sign. .Pp Finally, the RCS file contains the deltatexts. The list of deltatexts is ordered the same as the list of deltas. Deltatexts are separated by two lines. Each entry begins with the revision number, followed by a newline. The text .Dq Cm log follows on its own line. The log message follows on another new line; it consists of an at sign, the log message itself (which may span multiple lines), and finally an at sign on its own line. Then the text .Dq Cm text follows on its own line. The format is the same as for the description and log message. As with the description, at signs anywhere in the log message or in the deltatext itself are escaped by prefixing them with another at sign. The deltatext of the head consists of the full file contents. All subsequent deltatexts contain the differences to the previous deltatext in the format of .Xr diff 1 .Fl n . .Sh
hack.6: mdoc punctuation fixes
This patch cleans up some minor punctuation issues in the hack(6) man page. The placement of the comma in an Ev list matches crontab(1) and sysmerge(8) now. It also introduces .Dq for double quotes to the hack(6) man page. Index: games/hack/hack.6 === RCS file: /cvs/src/games/hack/hack.6,v retrieving revision 1.21 diff -u -p -r1.21 hack.6 --- games/hack/hack.6 5 Apr 2019 09:02:27 - 1.21 +++ games/hack/hack.6 8 Apr 2019 14:08:43 - @@ -122,7 +122,8 @@ option suppresses printing of the news. The .Fl u .Ar playername -option supplies the answer to the question "Who are you?". +option supplies the answer to the question +.Dq Who are you? . When .Ar playername has as suffix one of @@ -133,7 +134,8 @@ has as suffix one of .Em -C , or .Em -W , -then this supplies the answer to the question "What kind of character ... ?". +then this supplies the answer to the question +.Dq What kind of character...? . .Pp The .Fl s @@ -154,7 +156,7 @@ Your home directory. Your shell. .It Ev TERM The type of your terminal. -.It Ev HACKPAGER, PAGER +.It Ev HACKPAGER , PAGER Pager used instead of default pager. .It Ev MAIL Mailbox file.
Re: what.1: remove BUGS section
On 1/20/19 3:11 PM, Ingo Schwarze wrote: > Hi Fabio, > > Fabio Scotoni wrote on Sun, Jan 20, 2019 at 12:52:18PM +0100: > >> The what(1) man page has a BUGS section, >> which mdoc(7) says is discouraged in OpenBSD. > > What? Using BUGS sections is perfectly fine. > > The mdoc(7) manual page does not intend to say that using BUGS > sections is discouraged in OpenBSD. > > Why do you think it says that? That's my mistake. I misinterpreted this part in mdoc(7): 160 \&.\e\(dq .Sh BUGS 161 \&.\e\(dq .Sh SECURITY CONSIDERATIONS 162 \&.\e\(dq Not used in OpenBSD. I mistook the list of section headings near the end to all fall through to SECURITY CONSIDERATIONS, which says "Not used in OpenBSD." I should've noticed that assessment being inaccurate because the STANDARDS section is clearly not discouraged and it's part of the same list. >> The contents of the BUGS section is mostly unhelpful anyway. > > Indeed, thanks for reporting the weird text. > It doesn't mention any BUGS, so it's in the wrong section. > >> Talking about BSD not being able to distribute SCCS doesn't help >> anyone; >> not behaving like the original SCCS is obvious considering the >> STANDARDS section specifically notes OpenBSD extensions and >> compliance with POSIX. > > I almost felt like proposing to delete the utility outright. > We stopped embedding identifier strings into binaries many years ago. >> Then again, who knows whether some scripts somewhere still call it. > Keeping it costs almost nothing, and it is not dangerous. what(1) *is* in an odd spot, being the only part of SCCS that actually got rewritten for BSD. CSSC and Schily SCCS would theoretically also provide what(1) and the rest of SCCS.
what.1: remove BUGS section
The what(1) man page has a BUGS section, which mdoc(7) says is discouraged in OpenBSD. The contents of the BUGS section is mostly unhelpful anyway. Talking about BSD not being able to distribute SCCS doesn't help anyone; not behaving like the original SCCS is obvious considering the STANDARDS section specifically notes OpenBSD extensions and compliance with POSIX. Index: usr.bin/what/what.1 === RCS file: /cvs/src/usr.bin/what/what.1,v retrieving revision 1.19 diff -u -p -r1.19 what.1 --- usr.bin/what/what.1 22 Jan 2015 19:10:17 - 1.19 +++ usr.bin/what/what.1 20 Jan 2019 10:04:41 - @@ -94,14 +94,3 @@ The .Nm command appeared in .Bx 4.0 . -.Sh BUGS -As -.Bx -is not licensed to distribute -.Tn SCCS , -this is a rewrite of the -.Nm -command which is part of -.Tn SCCS . -As such it may not behave exactly the same as that -command does.
cvsintro.7: patch to fix .Bx invocation
The cvsintro(7) man page uses ".Bx -licensed", which is rendered as "-licensedBSD". This patch fixes this to correctly read "BSD-licensed" in both mandoc and groff. I'm not entirely sure if .Bx should even be used here, though apparently that decision has been made deliberately. Index: cvsintro.7 === RCS file: /cvs/src/usr.bin/cvs/cvsintro.7,v retrieving revision 1.15 diff -u -p -r1.15 cvsintro.7 --- cvsintro.7 14 Aug 2013 08:46:07 - 1.15 +++ cvsintro.7 29 Nov 2018 19:18:34 - @@ -223,7 +223,7 @@ unless the development network is local. .Xr sshd 8 .Sh HISTORY The OpenCVS project is a -.Bx -licensed +.Bx Ns -licensed rewrite of the original Concurrent Versioning System written by Jean-Francois Brousseau. The original CVS code was written in large parts by Dick Grune,
