Re: documentation

2022-05-24 Thread Ingo Schwarze

Tom Smyth wrote on Tue, May 24, 2022 at 05:02:42PM +0100:
> On Tue, 24 May 2022 at 16:54, Gustavo Rios wrote:

>> I would like to download a pdf version of the faq and pf guide
>> for openbsd 7.1.

I assume you are talking about

and .

The OpenBSD project does not provide PDF or manual page versions
of these documents but only the HTML versions on the web.

>> May some one here point me where i could fetch the pdf documentation
>> from ?

Of course, feel free to use any HTML-to-PDF conversion program
to convert these documents from HTML to PDF yourself.

> any manual pages that you wish to convert to PDF can be done with PDF
> stuart@  had once recommended the following command for creating a nice pdf
> manual of the PF firewall
> man -T pdf pf.conf > pf.conf.pdf

Sure, but i doubt that Gustavo is trying to ask about

which is much shorter than

and also doesn't include the the rest of the FAQ.

The main reason why the FAQ is provided as online HTML documents
rather than manual pages is personal preference of the person (tj@)
who maintains these documents (for free), and also that he thinks
it is easier to get help from others maintaining these documents
when they are in HTML format than it would be if they were in
manual page format.

Around here, it isn't unusual that the person doing the work gets
to make most of the decisions involved, unless other developers
are strongly opposed to their choices.


Re: How to Get the kernel-specific source or configuration of the distribution without installation

2022-04-25 Thread Ingo Schwarze

Parodper wrote on Mon, Apr 25, 2022 at 08:47:20AM +0200:
> O 24/04/22 ás 10:13, sunying escribiu:

>> We are studying on the default value of Kernel Configuration items
>> in each Linux mainstream distribution.
>> May I ask if your distribution has the open kernel source website url
>> (eg. git:// ... 

The official website is .

This is an unofficial clone, usually having the same content (no
guarantee, though):

>> Or directly the url of kernel configuration files
>> (eg.

> OpenBSD's kernel configs are under 
> arch)/conf/GENERIC(.MP) and 
> See 
> also

These URIs are correct.

>> Or some other public way to get your distribution's kernel-specific
>> configuration files

Alternatively, you can use anonymous CVS:

>> on different kernel versions without installation?

OpenBSD does not support different kernel versions.
The only officially supported version of the kernel is GENERIC{,MP}.
All users are advised to run GENERIC or GENERIC.MP.

The various RAMDISK* kernel configs you will find in the above
directories are installation kernels and unfit for use in production.


Ingo Schwarze 

Re: rc.daily missing diff markers

2022-04-24 Thread Ingo Schwarze
Hi Lyndon,

Lyndon Nerenberg (VE7TFX/VE6BBM) wrote on Fri, Apr 22, 2022 at 02:31:55PM -0700:

> Sure.  It just caught my attention today because this is probably
> the first time I've seen such a large batch of changes in one email
> like that.  Which has no doubt happened endless times in the past,
> but I never noticed it until today for some reason.

Indeed, it has mildly bothered me for two decades that this happens at
least once, usually twice a year for every machine i maintain.

For an upgrade, having all those lines is not useful.  Even if i made
some mistake during an upgrade, i wouldn't spot it among such a large
amount of noise.

But i never had an idea how to make this comparison more useful for
upgrades without degrading its usefulness in everyday operation.


Re: rc.daily missing diff markers

2022-04-22 Thread Ingo Schwarze
Hi Lyndon,

Lyndon Nerenberg wrote on Fri, Apr 22, 2022 at 09:33:57AM -0700:

> In the output from the daily insecurity report run, the sections on
> setuid and block device changes are missing any diff markup.  The
> remaining sections are fine.
> From this morning's post-7.1-upgrade run:
> Setuid changes:
> -r-sr-xr-x 2 root  bin  355952 Sep 30 13:01:03 2021 /sbin/ping
> -r-sr-xr-x 2 root  bin  358736 Apr 11 16:46:17 2022 /sbin/ping
> -r-sr-xr-x 2 root  bin  355952 Sep 30 13:01:03 2021 /sbin/ping6
> -r-sr-xr-x 2 root  bin  358736 Apr 11 16:46:17 2022 /sbin/ping6
> -r-sr-x--- 1 root  operator 274936 Sep 30 13:01:04 2021 /sbin/shutdown
> -r-sr-x--- 1 root  operator 277592 Apr 11 16:46:17 2022 /sbin/shutdown
> [...]
> Block device changes:
> brw-r- 1 root operator 6,  0   Mar 4  14:48:06 2022 /dev/cd0a
> brw-r- 1 root operator 6,  0   Apr 21 12:19:45 2022 /dev/cd0a
> brw-r- 1 root operator 6,  2   Mar 4  14:48:06 2022 /dev/cd0c
> brw-r- 1 root operator 6,  2   Apr 21 12:19:45 2022 /dev/cd0c
> brw-r- 1 root operator 6,  16  Mar 4  14:48:01 2022 /dev/cd1a
> brw-r- 1 root operator 6,  16  Apr 21 12:19:40 2022 /dev/cd1a
> [...]

That's not new, it has been like that for at least 14 years and likely
much longer:

From: Charlie Root 
Date: Sun, 27 Apr 2008 01:31:15 +0200
Subject: daily insecurity output
Setuid changes:
-r-sr-xr-x  1  root  bin   157408   Feb  11  00:00:58  2008  /sbin/ping
-r-sr-xr-x  1  root  bin   157440   Apr  21  02:58:12  2008  /sbin/ping
-r-sr-xr-x  1  root  bin   180896   Apr  21  02:58:12  2008  /sbin/ping6
-r-sr-xr-x  1  root  bin   181024   Feb  11  00:00:58  2008  /sbin/ping6
Block device changes:
brw-r-  1  root  operator  16,  0 Apr  26  21:21:20  2008  /dev/ccd0a
brw-r-  1  root  operator  16,  0 Feb  16  18:24:18  2008  /dev/ccd0a
brw-r-  1  root  operator  16,  1 Apr  26  21:21:20  2008  /dev/ccd0b
brw-r-  1  root  operator  16,  1 Feb  16  18:24:18  2008  /dev/ccd0b

Which means my 2011 rewrite of the utility (together with afresh1@)
merely preserved the traditional format.

These lines do not come from diff(1); see the functions check_filelist()
and adjust_columns() for details.

I don't think adding the more characters to each line would be a good idea.
It would cause line wrapping in mail even more often than the long lines
already do now.  Besides, there is no real ambiguity because the file
name in the last column makes the pairing obvious and the dates right
in front of that show the direction of the change.


Re: support update

2022-04-13 Thread Ingo Schwarze
Hi Duncan,

Duncan Hart wrote on Wed, Apr 13, 2022 at 03:28:38AM -0400:

> 0
> C Australia
> P Victoria
> T South Yarra
> Z 3141
> A PO Box 530
> O Applied OpenBSD
> I Duncan Hart
> M
> U
> B +61 3 7065 5840
> N Proactively secure application development and consultancy for BCHS
> (OpenBSD, C, httpd, SQLite) software stack on IBM POWER9 platforms.

Committed, thanks for keeping your entry up to date.


Committed diff:

Index: build/support.dat
RCS file: /cvs/www/build/support.dat,v
retrieving revision 1.373
diff -u -r1.373 support.dat
--- build/support.dat   2 Mar 2022 11:19:39 -   1.373
+++ build/support.dat   13 Apr 2022 10:23:27 -
@@ -107,16 +107,16 @@
 C Australia
 P Victoria
-T Melbourne
-Z 3000
+T South Yarra
+Z 3141
+A PO Box 530
 O Applied OpenBSD
 I Duncan Hart
-A PO Box 2530
 B +61 3 7065 5840
-N Proactively secure web application development
-using the BCHS (OpenBSD, C, httpd, SQLite) software stack.
+N Proactively secure application development and consultancy for BCHS
+(OpenBSD, C, httpd, SQLite) software stack on IBM POWER9 platforms.
 # Start of Belgium

Re: HW raid adapter - Adaptec 8405 SGL

2022-01-13 Thread Ingo Schwarze

Nick Holland wrote on Thu, Jan 13, 2022 at 11:30:58AM -0500:
> On 1/13/22 5:58 AM, Stuart Henderson wrote:
>> On 2022-01-13, Aleksander Dzierżanowski  wrote:

>>> Is 'Adaptec 8405 SGL' hardware raid controller working under OpenBSD?
>>> I saw there is *some* Adaptec support, but the model is not listed
>>> explicitly.
>>> Please advise if I should try to rent a dedicaated server with such
>>> card or simply avoid this configuration.

>> Avoid.
>> Look for mfii for fast/advanced RAID or maybe mpii for something more
>> basic.

> Yeah, you don't want to use Adaptec for anything other than maybe
> leveling your table.
> Consolidation of old posts into one spot here:

That war story is from 2009/2010, around the time when Adaptec
went out of business in 2010, but Adaptec has already been a terrible
choice for at least half a decade before that.

Here is my own war story:  (2004-12-23)
... then follow the thread to ...

If finally ends here:  (2005-01-10)
Adaptec tells me in direct email:
"As you know it is not supported in FreeBSD officially and we
 appreciate your offering to test the firmware but at this time
 there is no plan to support FreeBSD or OpenBSD yet."

Then, another try a few months later:  (2005-03-26)  (2005-03-26)
(Same problems under Linux as under OpenBSD)
...  (2005-06-21)
(Full summary of all the problems)  (2005-09-23)
(Note this is 3/4ers of a year after initially finding the problems
 and after switching to completely different hardware except
 for keeping the AAC card only, and after switching to Linux):
"I'm holding my breath and trying not to touch it any more."

Four years later:  (2009-11-09)
"Trash your aac(4) hardware and use softraid(4).
 At least that's what i'm doing right now.
 In a nutshell: insufficient docs, thus incomplete support;
 buggy firmware, thus unreliable with any operating system;
 Adaptec does not want customers using free software in the full
 sense of the word.  They do write huge Linux drivers covering up
 the worst bugs in scary ways, but management is only provided by
 an unwieldy non-standard vendor-supplied Linux-only interactive
 stand-alone tool, and there is no bioctl(8) support."

At that point, continue with Nick's story.


Re: Is fw_update documentation outdated?

2021-12-26 Thread Ingo Schwarze
Hi Alexander,

Alexander wrote on Sun, Dec 26, 2021 at 08:11:51PM +:
> On 2021/12/25 18:02, Ingo Schwarze wrote:

>> The new fw_update shell script is not in CVS yet.
>> This command provides a clue that could lead you to suspect the above:
>>$ grep -m 1 OpenBSD $(which fw_update) 
>>   #  $OpenBSD$
>> That's a CVS tag which has not been processed by CVS yet.

> Just to keep the noise on the mailing list down in case I run into
> something like this again at some point:
> Is that tag the usual indicator of such uncommitted code

No, it is not usual.  In most cases of uncommitted patches that
are being tested in snapshots, the patches change *.c files before
compiling.  Compiled files in OpenBSD usually do not contain the CVS
IDs of the source files used.  Some historical operating systems
(and maybe even a few current systems, i'm not sure about that)
did include SCCS or CVS tags into compiled files, and that's what
the what(1) utility was designed for in the remote past:

   $ what /usr/src/bin/cat/*.c
$OpenBSD: cat.c,v 1.32 2021/10/24 21:24:21 deraadt Exp $
   $ what /bin/cat

On some other or older systems, "what /bin/cat" might also return the
CVS ID(s).  But even that wouldn't really help for your purpose.
In most cases, it would only be the ID of the latest commited
revision; the patch being tested would typically change some lines
of code, but it would usually not change the ID.

You only saw the unexpanded $OpenBSD$ ID in this case because it
was a completely new uncommitted file intended for later commit,
and because it was not a compiled file but a script where the
source code gets installed directly.

In the rare cases where you do find such an unexpanded CVS ID, it's a
medium strength indicator pointing to a possible uncommitted patch,
but even then it's not 100% certain - there could be other, even more
unusual reasons for seeing such a thing.

> or are there other things I should look for before asking here again?

In general, it can be quite hard to identify uncommitted changes,
even for developers.  A generally working way to identify them 
basically does not exist.  (And maintaining an official list would
be a horrendous make-work project.)

Sometimes, compiling the tool that behaves strangely yourself
from CVS -current sources and comparing behaviour to the same
tool in the snapshot may help - if behaviour differs, that's
a medium strength indicator of a possible uncommitted patch.
Or, of course, you might have miscompiled it...
Your specific example demonstrates that this suggestion does
not always help: nothing to compile there, and you (rightly)
failed to even find any sources...

For users, i think best practice is as follows:  if something does not
work as you think it should, and if reviewing the manual pages, the
FAQ, and searching through recent postings on tech@, bugs@, and misc@
still leaves you wondering, then ask, providing as much much detail
as you can: which exact OS version or snapshot, what exactly you did,
what you expected, and what happened instead.  If the tool misbehaves
in the snapshot but works when you compile it yourself from -current,
say so.  In other words, your report was of very reasonable quality.
Nobody will expect that you make a definitive statement like "this is a
regression caused by an uncommitted patch in snapshots" in your report.

If it appears to misbehave, it's worth a report.  And if there
is an uncommitted patch in snapshot, than hopefully at least one
developer is watching closely.  After all, asking Theo to put a
patch into snapshots for testing but then *not* watch the bugs@
mailing list for reports that might be related would make very
little sense!


Currently, it looks relatively unlikely that the new fw_update(8)
is really going to loose the -n option; or else it might regrow
it shortly after the initial commit.  No guarantee though.
Best advice for users is to wait for the dust in this area to settle.

Re: Is fw_update documentation outdated?

2021-12-25 Thread Ingo Schwarze
Hi Alexander,

Alexander wrote on Sat, Dec 25, 2021 at 04:07:07PM +:

> I just wanted to check for new firmware versions:
> $ fw_update -n
> fw_update: unknown option -- -n
> usage:  fw_update [-d | -D] [-av] [-p path] [driver | file ...]
> This used to work

/usr/sbin/fw_update used to be a symbolic link to /usr/sbin/pkg_add,
but recent snapshots appear to contain an uncommitted change by
Andrew Fresh  that makes /usr/sbin/fw_update a stand-
alone shell script such that it will become usable in the installer.

For now, you can still run the pkg_add-based version that supports
the -n option like this:

   $ cd
   $ cp /usr/sbin/pkg_add fw_update
   $ perl ./fw_update -n

But this may or may not become impossible in the near future.

Snapshot do sometimes contain patches that are being evaluated
before committing them.

> and is still documented like this in
> $ man 8 fw_update
> [...]
>  -n  Dry run.  Do not actually install or update any firmware
>  and whether it appears to be required by a driver.
> [...]
> (also

I expect the documentation will be updated when this gets committed,
or shortly afterwards.

> But /usr/sbin/fw_update does not contain this option anymore and
> consequently produces the error above.
> This mismatch puzzles me a bit and I'm even more confused when looking
> at which has been in
> the attic for the last 6 years.
> I'm guessing I'm just uninformed and don't understand CVSweb but I'd
> like to learn, so:
> Is the documentation for fw_update outdated?
> Where do I actually find the version history of the fw_update that is
> installed on my system in CVSweb?

That history is purely a matter of the future.

The new fw_update shell script is not in CVS yet.

This command provides a clue that could lead you to suspect the above:

   $ grep -m 1 OpenBSD $(which fw_update) 
  # $OpenBSD$

That's a CVS tag which has not been processed by CVS yet.


> My system:
> $ head -1 /etc/motd
> OpenBSD 7.0-current (GENERIC.MP) #200: Fri Dec 24 22:15:01 MST 2021

Re: openbsd is shockingly good

2021-12-19 Thread Ingo Schwarze
Hi, wrote on Sat, Dec 18, 2021 at 09:37:35PM +:

> I have to say I am really impressed. This is how IT should be done. My
> compliments to the developers.

Heh, you are evoking pleasant old memories.  That's exactly how i felt
shortly after a SysOp colleague made the casual remark "why don't we try
OpenBSD 2.7 for this multi-purpose server?"  It surprised me because i had
never heard of that one.  Before that, i had used the following operating
systems: hpl, HP Basic 2.1, Commodore BASIC, MS DOS, MS Windows, Ultrix,
HP-UX, AIX, DEC OSF/1, SuSE, Redhat, Debian, and a handful whose names
i have forgotten.

Being fairly experienced with Debian and completely new to OpenBSD,
getting real work done typically took less than half the time with OpenBSD
than it used to take with Debian.  And it only got better collecting
experience.  In one admittedly bizarre episode two or three years later,
i solved a problem in less than an hour by setting up an OpenBSD machine
(probably 3.1 or 3.3 or thereabout) that a Debian developer who also
happened to be present on-site (and who later became a member of the
Debian release team) had wrestled with for two hours and then given up on.

Have fun,

Re: Missing action list in lesskey man page

2021-12-06 Thread Ingo Schwarze
Hi Jason and Richard,

Jason McIntyre wrote on Sat, Dec 04, 2021 at 09:18:56PM +:
> On Sat, Dec 04, 2021 at 07:11:01PM +0100, Richard Ulmer wrote:
>> jmc@ wrote:

>>> the actions do indeed match those in the command list. whether there are
>>> any undocumented ones, i don;t know. i suppose you'd have to go poking
>>> in the source.

>> Out of curiosity I did take a peek at the source and found this that
>> there are indeed undocumented actions:
>> - 'display-flag'  is an undocumented alias for 'display-option'
>> - 'end'   is an undocumented alias for 'goto-end'
>> - 'first-cmd' is an undocumented alias for 'firstcmd'
>> - 'flush-repaint' is an undocumented alias for 'repaint-flush'
>> - 'toggle-flag'   is an undocumented alias for 'toggle-option'

I don't think those should be documented.  The only purpose action
names can be used for is for lesskey(1).  So having aliases helps
noone.  Besides, this stuff is already overcomplicated,
overengineered, and full of feature creep without aliases,
so documenting aliases would only exacerbate the mess.

>> - 'debug' is an entirely undocumented action

I grepped the usr.bin/less source directory for A_DEBUG and it appears
to be unused.  So i conclude "debug" does nothing and should not be

>> - 'forw-skip' is an entirely undocumented action

That's apparently used if and only if less_is_more.
The 's' key behaves differently in more(1) than in less(1).
According to command.c, in more(1), it does this:

 * Skip ahead one screen, and then number lines.

That's madness because the point of more(1) is compatibility,
not featurism.  Probably, the 's' key ought to be deleted from more(1),
it is undocumented in the more(1) manual page anyway.  Documenting
it in lesskey(1) would seem wrong to me.

>> - 'shell' appears in the lesskey(1) man page but does not work

Good catch, deleting that was forgotten when deleting the '!'
command from less(1) - which was done for security reasons.

>> I'd much prefer to have
>> the actions explained in the lesskey(1) man page.

No way.  Copying half of the less(1) manual to the lesskey(1) manual
would result in a maintenance nightmare.

What matters most is that the less(1) manual is correct, complete,
and as readable as possible - even though the latter is hard to
achieve given all the feature creep.

The lesskey(1) manual page is secondary to that, documenting something
that is almost entirely feature creep and not very well-designed
on top of that.  We can try to make it correct, complete, and
readable to as far as possible, but the following two mistakes must
be avoided:

 1. Let's not make less(1) harder to read by refering to lesskey(1).
 2. Let's not make lesskey(1) harder to maintain by usurping
part of the purpose of the less(1) manual.

>> Doing this still
>> doesn't explain everything; e.g. this still confuses me:

On the one hand, that's a consequence of less(1) being so
overcomplicated; it's unavoidably hard to understand.
On the other hand, wording of the manual could be improved
in many places for precision and clarity.

>>  s toggle-option o
>> translates to
>>  s filename
>>  Save the input to a file.
>>  This only works if the input is a pipe,
>>  not an ordinary file.

> it confuses me too! i have no idea why they have used "toggle-option".

Because the 's' action does the same as the less(1) -o command
line option.  After pressing the 's' key in less(1), you get a prompt
where you can type the name of the log file you want to create.
That file name you type is used in the same way as the .Fl o Ar logfile
option argument which you could have provided on the command line
when you started less(1).

>>> we could maybe make this clearer:
>>> #command
>>> \r  forw-line
>>> ...
>>> to sth like this:
>>> #command action
>>> \r   forw-line
>>> ...

I don't like that too much.  From code inspection, it appears that
control lines like "#command" ignore trailing garbage, and that
implementation detail could maybe be exploited to sneak in comments.
But that is undocumented, so relying on it in the documentation
feels confusing.

>> I'd prefer a separate list where each action is described with a little
>> more detail, than just having the example.

It's not an example; it documents the default key bindings
and the action names.  What the actions do is subject matter
for less(1), not for lesskey(1).

>>> however we still import less. i'd want to make sure that's
>>> not stepping on anyone's toes to make local changes.

We forked the "less" program and made many extensive changes.
I think we are free to improve the documentation as we see fit.

>> I wanted to hear some second opinions first and make sure, that I didn't
>> miss anything. If I still think the documentation is lacking after that,

No doubt less(1) documentation can be improved regarding 

Re: Default window manager

2021-11-27 Thread Ingo Schwarze
Hi, wrote on Sat, Nov 27, 2021 at 04:34:48PM -0500:

> I am wondering if there are plans to change the
> default window manager in OpenBSD.

No, i don't think there is any interest.

Experience taught us that importing additional code into the base
sytem is a bad idea unless at least one developer is actively
working on it and unless there is a real need.

Apart from a very small group sporadically working on cwm(1),
i'm not aware of any OpenBSD developer working on a window
manager, so your suggestion fails the first test.

Even though it is low-quality code, the dafault fvwm(1) just works.
Besides, you can trivially install whatever window manager you like
using packages.  So your suggestion fails the second test, too.


Re: MANPATH resets output paper setting

2021-11-06 Thread Ingo Schwarze
Hi Jan,

Jan Stary wrote on Sat, Nov 06, 2021 at 04:05:10PM +0100:
> Ingo Schwarze wrote:
>> Jan Stary wrote:

>>> This is current/amd64 on a PC.
>>> It seems that if MANPATH is set (to something nonempty),
>>> the settings in /etc/man.conf get ignored:
>>> $ cat /etc/man.conf
>>> output paper a4
>>> $ man -Tps true | grep PageSize 
>>> %%BeginFeature: *PageSize Letter
>>> <>setpagedevice
>>> $ env | grep MAN
>>> MANPATH=/home/hans/man:/usr/local/man:/usr/share/man:/usr/X11R6/man
>>> $ export MANPATH=
>>> $ man -Tps true | grep Size 
>>> %%BeginFeature: *PageSize A4
>>> <>setpagedevice

>> Thanks for reporting.
>> This seemed like a trivial bug to me, so i fixed it right away in both
>> OpenBSD and, see the commit appended below.

> thank you for the quick fix. For completeness,
> I just confirm it fixes PDF output as well:
>   $ man -Tpdf ls | grep Media
>   /MediaBox [0 0 595 841]

Great, thank you for testing.
Testing is always highly welcome.

>> It turned out to be less trivial than i thought, i ended up completely
>> rewriting the manconf_parse() function.  Yes, i am aware that other bug
>> reports against mandoc are still pending, and i'm a bit behind, you just
>> got lucky that this one *seemed* simple at first...  "That is probably
>> easy to do with a three-line diff..."

> Point taken: always make sure the bug seems trivial
> so that it gets up the list :-)

LOL.  :-D

Then again, it's not that far from the truth.  The best bug reports are
those making it trivial for developers to understand what is going on.

Your report was exemplary, stating very clearly and concisely what
you did, what you expected, and what happened instead, without any
additional fuss.


Re: MANPATH resets output paper setting

2021-11-05 Thread Ingo Schwarze
Hi Jan,

Jan Stary wrote on Fri, Nov 05, 2021 at 01:24:19PM +0100:

> This is current/amd64 on a PC.
> It seems that if MANPATH is set (to something nonempty),
> the settings in /etc/man.conf get ignored:
>   $ cat /etc/man.conf
>   output paper a4
>   $ man -Tps true | grep PageSize 
>   %%BeginFeature: *PageSize Letter
>   <>setpagedevice
>   $ env | grep MAN
>   MANPATH=/home/hans/man:/usr/local/man:/usr/share/man:/usr/X11R6/man
>   $ export MANPATH=
>   $ man -Tps true | grep Size 
>   %%BeginFeature: *PageSize A4
>   <>setpagedevice

Thanks for reporting.

This seemed like a trivial bug to me, so i fixed it right away in both
OpenBSD and, see the commit appended below.

It turned out to be less trivial than i thought, i ended up completely
rewriting the manconf_parse() function.  Yes, i am aware that other bug
reports against mandoc are still pending, and i'm a bit behind, you just
got lucky that this one *seemed* simple at first...  "That is probably
easy to do with a three-line diff..."


Log Message:
Make sure that the configuration file is always read, even when
running with the -M option or with a MANPATH environment variable
that has neither a leading or trailing ":" nor any "::".  If -M or
MANPATH override the configuration file rather than adding to it,
just ignore any "manpath" directives while processing the configuration

This fixes a bug reported by Jan Stary 
on misc@.

Modified Files:

Revision Data
Index: manpath.c
RCS file: /home/cvs/mandoc/mandoc/manpath.c,v
retrieving revision 1.43
retrieving revision 1.44
diff -Lmanpath.c -Lmanpath.c -u -p -r1.43 -r1.44
--- manpath.c
+++ manpath.c
@@ -31,63 +31,51 @@
 #include "mandoc.h"
 #include "manconf.h"
-static void manconf_file(struct manconf *, const char *);
+static void manconf_file(struct manconf *, const char *, int);
 static void manpath_add(struct manpaths *, const char *, char);
 static void manpath_parseline(struct manpaths *, char *, char);
-manconf_parse(struct manconf *conf, const char *file,
-   char *defp, char *auxp)
+manconf_parse(struct manconf *conf, const char *file, char *pend, char *pbeg)
-   char*insert;
+   int use_path_from_file = 1;
/* Always prepend -m. */
-   manpath_parseline(>manpath, auxp, 'm');
+   manpath_parseline(>manpath, pbeg, 'm');
-   /* If -M is given, it overrides everything else. */
-   if (NULL != defp) {
-   manpath_parseline(>manpath, defp, 'M');
-   return;
-   }
-   /* MANPATH and man.conf(5) cooperate. */
-   defp = getenv("MANPATH");
-   if (NULL == file)
-   file = MAN_CONF_FILE;
-   /* No MANPATH; use man.conf(5) only. */
-   if (NULL == defp || '\0' == defp[0]) {
-   manconf_file(conf, file);
-   return;
-   }
-   /* Prepend man.conf(5) to MANPATH. */
-   if (':' == defp[0]) {
-   manconf_file(conf, file);
-   manpath_parseline(>manpath, defp, '\0');
-   return;
+   if (pend != NULL && *pend != '\0') {
+   /* If -M is given, it overrides everything else. */
+   manpath_parseline(>manpath, pend, 'M');
+   use_path_from_file = 0;
+   pbeg = pend = NULL;
+   } else if ((pbeg = getenv("MANPATH")) == NULL || *pbeg == '\0') {
+   /* No MANPATH; use man.conf(5) only. */
+   pbeg = pend = NULL;
+   } else if (*pbeg == ':') {
+   /* Prepend man.conf(5) to MANPATH. */
+   pend = pbeg + 1;
+   pbeg = NULL;
+   } else if ((pend = strstr(pbeg, "::")) != NULL) {
+   /* Insert man.conf(5) into MANPATH. */
+   *pend = '\0';
+   pend += 2;
+   } else if (pbeg[strlen(pbeg) - 1] == ':') {
+   /* Append man.conf(5) to MANPATH. */
+   pend = NULL;
+   } else {
+   /* MANPATH overrides man.conf(5) completely. */
+   use_path_from_file = 0;
+   pend = NULL;
-   /* Append man.conf(5) to MANPATH. */
-   if (':' == defp[strlen(defp) - 1]) {
-   manpath_parseline(>manpath, defp, '\0');
-   manconf_file(conf, file);
-   return;
-   }
+   manpath_parseline(>manpath, pbeg, '\0');
-   /* Insert man.conf(5) into MANPATH. */
-   insert = strstr(defp, "::");
-   if (NULL != insert) {
-   *insert++ = '\0';
-   manpath_parseline(>manpath, defp, '\0');
-   manconf_file(conf, file);
-   manpath_parseline(>manpath, insert + 1, '\0');
-   return;
-   }
+   if (file == NULL)
+   file = MAN_CONF_FILE;

Re: Spleen with russian (maybe more) cyrillic symbols

2021-10-05 Thread Ingo Schwarze
Hi Slava,

Slava Voronzoff wrote on Tue, Oct 05, 2021 at 03:01:26PM +0300:

> I'm working right now on adding cyrillic to Spleen font. How can I later
> add it to OpenBSD kernel and ports? Pull request to main font on github
> (Hi, Frederic) or patch here?

You cannot add it to the kernel because the kernel does not support
UTF-8, but only US-ASCII, and US-ASCII contains no code points for
cyrillic letters.

Full UTF-8 support is definitely not wanted in the kernel.  Adding
extremely minimalistic UTF-8 support to the kernel is not completely
out of the question, but some developers are likely to feel sceptic even
about that.  Consequently, trying to pursue a project of adding anything
related to UTF-8 to the kernel is likely to end in frustration if the
person trying that does not have a significant amount of experience with
getting OpenBSD kernel patches committed.

I'm sorry that i know absolutely nothing about fonts in ports, maybe
someone else can answer that part of the question.


Re: Are there any protection againts heisting the "shell builtin"s?

2021-09-08 Thread Ingo Schwarze
Hi Jim,

jim hook wrote on Wed, Sep 08, 2021 at 11:24:18AM +0200:

> test$ cd
> rmplayer
> test$
> test$ type cd
> cd is a function
> test$
> test$ tail -4 .profile
> cd()
> {
> echo rmplayer
> }
> test$
> test$ uname -mrs
> OpenBSD 6.9 amd64
> test$

Those are useful features.  I doubt you will find any Unix user who
never used aliases or shell functions to modify the behaviour of
system commands to better suit their personal taste.  Even myself,
though i dislike changing default configuration in general,
currently have an alias in place that modifies the default behaviour
of rm(1).  From what i have heard, most OpenBSD developers use
aliases or shell functions for several commands, not just for one.

> Thinking of that home dirs could be on a shared storage, that can
> be accessed by others and maliciously modify the ".profile",
> etc. files of the targeted user.

That is not an issue by any stretch of the imagination.  If anyone
else has write access to your home directory, you have already lost
the game, and the number of ways how they own you is is next to


Re: Snapshot generation stalled?

2021-09-01 Thread Ingo Schwarze
Hi Karel,

Karel Gardas wrote on Wed, Sep 01, 2021 at 07:32:50PM +0200:

> installed snapshot on amd64 week or so ago to see how it is working. 
> It's #195 from Aug 23. During the past few days I've checked from time 
> to time
> with sysupgrade (with or without -s) but it always claimed I'm on the 
> latest snapshot.
> I've also switched from to and then to 
> to see if there are some difference due to outdated 
> mirror(s) but still the same result.
> So let me ask is snapshot generation stopped for whatever reason for 
> now, or am I doing anything wrong with sysupgrade?

Running -current is one thing.  Running bleeding-edge code right
from the middle of a hackathon is quite another.  If that is *really*
what you intend to do, please look at the release(8) manual page.


Re: Run a command on "last day of month"

2021-09-01 Thread Ingo Schwarze

Adam Paulukanis wrote on Wed, Sep 01, 2021 at 04:39:54PM +0200:

> if today is the last day of the month, tomorrow will be 1st.

That is a non-portable assumption and a trap that many people seem
to fall into.

For example, in the shire calendar, 1 Afterlithe (~= July) is the
fourth day after 30 Forelithe (which always is the last day of
Forelithe ~= June) in some years, and the fifth day after in other
years, but never the first, second, or third.  Similarly, 1 Afteryule
(~= January) is the third day after 30 Forejule (the last day in
Foreyule ~= December).  That also implies that January 1 is *never*
the first day of the year, and that the last day of the last month
of a year is *never* the last day of that year.

Localization is an extremely hard and complex task.  For that reason,
OpenBSD believes the C library is the wrong place to attempt to
provide such functionality.  The same applies to general-purpose
command line tools like date(1), ls(1), and cron(8).  The price to
pay in terms of complexity, and hence ultimately in bugs, would be


Re: support update

2021-08-27 Thread Ingo Schwarze

Duncan Hart wrote on Sun, Aug 22, 2021 at 05:31:09PM +1000:

> 0
> C Australia
> P Victoria
> T Melbourne
> Z 3000
> A PO Box 2530
> O Applied OpenBSD
> I Duncan Hart
> M
> U
> B +61 3 7065 5840
> N Proactively secure web application development using the BCHS (OpenBSD, C, 
> httpd, SQLite) software stack.


Re: Submitting Patches

2021-07-25 Thread Ingo Schwarze
Hi Ben, wrote on Sun, Jul 25, 2021 at 01:44:41PM -0400:

> I've made a patch for the Xenocara project,
> and would like to submit it.

So, why didn't you?

This is absolutely not specific to OpenBSD: Never ask what to with
patches without including them in the first message, for no project
and in no context.  You are just wasting peoples' time.  If it turns
out to be the wrong place, the patch can be forwarded.

> What is the best mailing list/developer/maintainer to send it to?

When in doubt, tech@, see .

In particular, read these paragraphs:

 * Include a useful Subject line
 * Trim your signature
 * Include important information

Nobody can provide a more specific answer without seeing the patch.


Re: /var/log/failedlogin is a binary file with a lot of null bytes?!

2021-07-17 Thread Ingo Schwarze

podolica wrote on Sat, Jul 17, 2021 at 12:36:05PM +:
> Philip Guenther  schrieb am 17. Juli 2021 um 11:09:

>> That file is specific to the 'login' command, specifically the
>> source file /usr/src/usr.bin/login/failedlogin.c and consists of
>> an array of the 'badlogin' structure specified there. If you want
>> to dump its contents in a more readable format then you should write
>> a small program to do so in C or some other language which can
>> easily handle binary files.

> Thank you, that seems to be an explanation. Lerning never stops :-)

By the way, to help learning even more, part of what Philip explained
can be guessed from the manual, even though it isn't fully spelled out.
What one might do to find out is this:

   $ man failedlogin
  man: No entry for failedlogin in the manual.

Hmm, that file does not have its own manual page in section 5.
That means it is likely used by one single program only.  But which one?

   $ man -k any=failedlogin
  login(1) - log into the computer

Ah, bingo, so let's read that page!

   $ man login
  If the file /var/log/failedlogin exists, login will record failed login
  attempts in this file.

  Immediately after logging a user in, login displays the system copyright
  notice, the date and time the user last logged in, the date and time of
  the last unsuccessful login (if the file /var/log/failedlogin exists),
  the message of the day as well as other information. 
  /var/log/failedlogin  failed login account records

Admittedly, that's the end of the documentation as far as i can see.

If you wanted to know even more, you would then go read the source
code of the program in question:

   $ which login

Consequently, it likely lives in /usr/src/usr.bin/login/.


Re: groups new

2021-07-16 Thread Ingo Schwarze
Hi Stefan,


While committing, i added the missing "P Baden" because it appears
we sort the German groups alphabetically by Land.

Some might regard the following as typical ;-) for Germany:

This Group is not just an informal group (like, for example, the
OpenBSD project itself is), but a formal, legal entity in the form
of a registered association according to the German civil law (BGB)
officially registered with the district court.  The group has formal,
written bylaws, a board, chairman, CFO, and cash auditors, formal
membership (including membership fees), formal annual members'
meetings discussing stuff like elections, budget discharges and so
on and so forth...  :-o

But don't worry, *anybody* can participate in all activities without
being required to become a member, and without having to participate
in any of the formalities.


And no, it a totally unfounded rumour and a vicious lie that naddy@
was nominated for CFO during the last annual members' meetings on
May 7, 2021.  I just invented that out of thin air!

Stefan Hagen wrote on Fri, Jul 16, 2021 at 12:22:55PM +0200:

> 0
> C Germany
> P 
> T Heidelberg
> F 1st Friday and 3rd Monday each month at 7:00PM
> O Unix User Group Rhein-Neckar (UUGRN)
> I Stefan Hagen
> M
> U
> N *BSD

Re: groups new

2021-07-16 Thread Ingo Schwarze
Hi Stefan,

Stefan Hagen wrote on Fri, Jul 16, 2021 at 12:22:55PM +0200:

> U

i suspect that your web server is misconfigured; at least for me,
it appears to redirect to itself:

 $ w3m -dump_source
Redirection loop detected (

302 Found

302 Found

OpenBSD httpd

Could you please check?


Re: new support

2021-07-16 Thread Ingo Schwarze
Hi Robert,

nice to have a service provider in Poland, too.  :-)

Committed; it will show up on the OpenBSD site with a short delay.

  Ingo wrote on Thu, Jul 15, 2021 at 04:26:56PM +0200:

> 0
> C Poland
> P mazowieckie
> T Radom
> Z 26-600
> O APISOFT Sp. z o.o.
> I Robert Zajda
> A Wiejska 58a/25
> M
> U
> B +48 503 146 490
> X
> N Linux/BSD consulting, installation, maintenance and support services.
> Secure servers, VPN, firewalls, OpenBSD-based Web Hosting.
> 15 years of experience.

Re: style.9 typos

2021-07-16 Thread Ingo Schwarze
Hi Claudio and Todd,

Todd C. Miller wrote on Thu, Jul 15, 2021 at 02:01:23PM -0600:

> You are expected to know that ^I (control-I) is the tab character.
> Using ^I instead of a literal tab character in the manual was
> supposed to make it clear that this is a tab and not a series of
> spaces but maybe it is not so obvious...

You aren't even expected to know; "I" being the ninth letter of the
alphabet, hence ^I = 0x09 = ht not necessarily being obvious is the
reason why the manual page already explains it explicitely, it

  Put a tab after the first word, i.e., use `int^Ix;'
  and `struct^Ifoo *x;'.

So i think the OP's patch is wrong.

It is also wrong because using a literal tab character in roff(7)
input in filled mode is discouraged roff(7) syntax:

   $ printf 'foo\tbar' | mandoc -Tlint
  mandoc: :1:4: WARNING: tab in filled text

   $ man mandoc
  tab in filled text
  (mdoc, man) The meaning of tab characters is only well-defined in non-
  fill mode: In fill mode, whitespace is not supposed to be significant on
  text input lines.  As an implementation dependent choice, tab characters
  on text lines are passed through to the formatters in any case.  Given
  that the text before the tab character will be filled, it is hard to
  predict which tab stop position the tab will advance to.

So to use "intx", that string would have to be set in
unfilled mode.  And exactly that is already there, right below:

   struct foo {
   struct  foo *next;  /* List of active foo */
   struct  mumble amumble; /* Comment for mumble */
   int bar;

That struct display does contain literal tabs in the mdoc(7) source
code, as indeed it should.

Yes, tabs versus spaces is a royal PITA in Unix in general.
That long-standing source of confusion wasn't mitigated until
much later, when the Python programming language was invented.


Re: displaying and typing czech letters

2021-07-12 Thread Ingo Schwarze
Hi Tomas,

tomas rodr wrote on Mon, Jul 12, 2021 at 06:58:07PM +0200:

> I am currently tied by X to display the following
[ latin letters with Czech accents]
> Likewise the keyboard encoding is done by setxkbmap. What steps 
> would I have to take to achieve the same result without running X? 

Become both a kernel hacker and a UTF-8 hacker and implement UTF-8
support in the kernel, such that terminal and console drivers in
the kernel can use it.

And tread very carefully, such that other kernel hackers don't
feel tempted to start screaming "BLOAT!".


Re: support and consulting: new entry request

2021-06-30 Thread Ingo Schwarze
Hi Navan,

Navan Carson wrote on Wed, Jun 30, 2021 at 01:08:55PM -0600:

> The TLS certificate is invalid for
> It's for some names. 

I'm sorry, but so far, i'm unable to reproduce.  When i connect
to with HTTPs, the following certificate is
returned from the server:

Serial Number:
Issuer: C=US, O=Cloudflare, Inc., CN=Cloudflare Inc ECC CA-3
Subject: C=US, ST=California, L=San Francisco, O=Cloudflare, Inc.,
X509v3 extensions:
X509v3 Subject Alternative Name:,, DNS:*

I verified that with both firefox and nc(1).

I see nothing involving in there.


Re: Localization of date(1) and XFCE

2021-06-25 Thread Ingo Schwarze

Jan Stary wrote on Tue, Jun 22, 2021 at 11:24:15AM +0200:
> On Jun 20 18:58:31, wrote:

>> I speak Spanish and thus I use a locale called es_CL.UTF-8. XFCE is fine
>> with it. However, my date is expressed directly as it comes from date(1).
>> This is confirmed by their docs
>> so how do I make date to
>> work with my language.
>> This is my locale:
>> LANG=es_CL.UTF-8
>> LC_CTYPE="es_CL.UTF-8"
>> LC_TIME="es_CL.UTF-8"
>> LC_ALL=es_CL.UTF-8

> man locale
> Programs in the OpenBSD base system ignore the locale except
> for the character encoding, and it is not recommended to
> use any of these variables except that the following
> non-default setting is supported as an option:
>   export LC_CTYPE=en_US.UTF-8
> OpenBSD's date(1) ignores your locale setting.

That's the correct answer, and there are no plans to change that in
the future.

The reason is that we prioritize simplicity and maintainablity
of the C library, and consequently correctness and security,
over localization of base system facilities.  On top of that,
even if you do not take the horrible complication of the library
code that LC_* support would imply into account, LC_* also poses
some security risks from the user perspective, in particular in
system administration and maintenance contexts.  Predicatbility
of output, and consistent parsing of input, is more valuable for
low-level work than localization.

Perspectives may vary, but my personal opinion is that adding all
those LC_* variables to POSIX was a mistake.  The C library is
not a reasonable place to handle higly specialized and highly
complicated topics like localization.  They belong into
specialized programs like typesettung software, UI libraries
and the like, not into a general-purpose operating system.

In general, we try to follow POSIX because standardization and
portability have significant advantages.  But there are limits.
If standards requirements are too bad, we may decide to ignore
them in some (rare) cases.  Hence, on OpenBSD, you can rely on
predictable output from strftime(3) and on predictable parsing
by strptime(3).

All this is mostly documented, for example:

  STRFTIME(3)Library Functions Manual
 On systems other than OpenBSD, the LC_TIME locale(1) category can
 cause erratic output; see CAVEATS in setlocale(3) for details.

  SETLOCALE(3)   Library Functions Manual
 On systems other than OpenBSD, calling setlocale() or uselocale(3)
 with a category other than LC_CTYPE can cause erratic behaviour
 of many library functions.  For security reasons, make sure
 that portable programs only use LC_CTYPE.

 For example, the following functions may be affected.  The
 list is probably incomplete.  For example, additional library
 functions may be impacted if they directly or indirectly call
 affected functions, or if they attempt to imitate aspects of
 their behaviour.  Functions that are not standardized may be
 affected too.

 glob(3), strcoll(3), strxfrm(3), wcscoll(3), wcsxfrm(3),
 and the functions documented in regexec(3)

 catgets(3), catopen(3), nl_langinfo(3), perror(3),
 psignal(3), strerror(3), strsignal(3), and the functions
 documented in err(3)

 localeconv(3), nl_langinfo(3), strfmon()

 atof(3), localeconv(3), nl_langinfo(3), strfmon(), and
 the functions documented in printf(3), scanf(3),
 strtod(3), wcstod(3), wprintf(3), wscanf(3).  This
 category is particularly dangerous because it can cause
 bugs in the parsing and formatting of numbers, for
 example failures to recognize or properly write decimal

 getdate(), nl_langinfo(3), strftime(3), strptime(3).
 Similarly, this is prone to causing bugs in the parsing
 and formatting of date strings.

 On systems other than OpenBSD, this category may affect
 the behaviour of additional functions, for example:
 btowc(3), isalnum(3), isalpha(3), isblank(3), iscntrl(3),
 isdigit(3), isgraph(3), islower(3), isprint(3),
 ispunct(3), isspace(3), isupper(3), isxdigit(3),
 mbsinit(3), strcasecmp(3), strcoll(3), strxfrm(3),
 tolower(3), toupper(3), vis(3), wcscoll(3), wcsxfrm(3),


Re: mount(8) security and symlink(7)

2021-06-25 Thread Ingo Schwarze

Reuben ua Brig wrote:

> when OpenBSD is happy to change even man.conf

We change things when all of the following hold:

 1. There is a significant problem to be solved, or a significant
profit to be gained.  Regarding man.conf: the old format was
over-engineered, wordy, hard to use, too closely tied to
implementation details of the old man(1) and apropos(1)
programs, and ill-suited to work with the then-new mandoc.db(5).

 2. Someone does the complete design and the complete implementation.
In the case of man.conf(5), that was me.

 3. There is broad agreement among developers, *after* step 2 is
complete, that downsides are acceptable, that benefits suffienctly
outweigh the downsides, and that the design and implementation
meet our quality standards.
In the case of man.conf(5), most users weren't affected at all.
A few had to replace one big configuration file with a small one
that would be easier to maintain going forward.  A tiny number
of people might no longer have been able to use idiosyncratic
configurations that didn't work all that well even before the
change and certainly weren't advisable in the first place;
but frankly, i don't recall a single report to that effect.

I can't talk about the internals of the mount(2) syscall,
so i pass on that one to people who know better.

That one thing is changed in a significant way does not imply
that something else is easy to improve as well.



2021-06-04 Thread Ingo Schwarze
Hi Heinrich,

Heinrich Rebehn wrote on Sun, May 30, 2021 at 10:02:41AM +0200:

> I did see LESS_IS_MORE, but there were probably good reasons for
> the OpenBSD devs to switch to less(1).

Prosaic as it may seem, and featurism indeed feeling not too typical
for OpenBSD, my reason for switching basically was that less(1) has
more features and more(1) feels slightly antiquated.  Besides, our
implementation of more(1) is less(1) anyway under the hood, so there
is little reason to artificially restrict its functionality.  Also,
having :t tagging enabled by default and yet calling it "more" felt a
bit weird.  Finally, POSIX allows using an implementation-specific
pager by default as long as that is documented:
  see the "PAGER" entry below "ENVIRONMENT VARIABLES":

  If the PAGER variable is null or not set, the command shall be
  either "more" or another paginator utility documented in the system

> 'MANPAGER="less -X" does the trick, I was not aware that "termcap
> initialization and deinitialization" is responsible for clrscreen.
> I hope that disabling it completely will not have any adverse side
> affects.

Reading less/opttbl.c, -X sets the global no_init variable,
and judging from "grep -RF no_init /usr/src/usr.bin/less/",
that's only used at two places in less/screen.c, using tputs(3)
to send the enter_ca_mode and exit_ca_mode strings defined in .
According to terminfo(5), these two capabilities are terminal-dependent.
So -X has different effects depending on which terminal or teminal
emulator you are using and with which setting of the TERM variable.
The worst that might happen on some terminals is that less(1) might
display gibberish and/or leave the terminal in an unusable state when
exiting.  But i assume you will notice if -X has undesirable effects
on the terminal you are using.

Theoretically, fiddling with such low-level options might have security
implications, putting the terminal into a state where it interprets
what you are typing afterwards in a way you never intended.  Then
again, while printing random binary data to a terminal can definitely
have security implications depending on how the terminal is configured -
the default configuration of xterm(1) being quite sane on OpenBSD -
i never heard about real-world security issues caused by partially
skipping terminal initialization or de-initialization, so they seem
somewhat unlikely.  This isn't a definite statement that none exist
on any terminal, though.

In any case, whether less(1) clears the screen when exiting is terminal-
dependent.  I just tried at the PC console (Strg-Alt-F2) on the same
amd64-current machine where less(1) in xterm(1) does clear the screen:
at the console, at least with TERM=vt220, it does not.


Re: Updating user groups - deregistering Iran BSD User Group (IRBUG)

2021-01-26 Thread Ingo Schwarze
Hi Faraz,

Faraz Vahedi wrote on Thu, Jan 14, 2021 at 08:05:32AM +:

> With a heavy heart, I am writing to hereby announce the end of the
> IRBUG's activities, the user group that I have been running for about
> two years.  Because of the current situation in Iran, the pandemic era,
> and several other reasons, I sadly decided to stop our further
> activities as a user group

I deleted your entry for now, please speak up if you hear about any other
group in Iran that would make sense to be listed, or if the situation
improves such that activities can be resumed.

> and will I hereafter as an individual, keep on advocating, helping,
> and educating anyone interested if I could do so anytime.

All the best for you!

> Therefore, please remove the IRBUG from the list as it no longer
> is active.
> I am very much grateful to anyone who supported me during this journey,
> thank you very much, people. I hope I can make more contributions to
> the project in both technical and educational development.

Just watch out for bugs that show up in your personal usage of OpenBSD,
and try to write and send patches to fix them whenever possible.  :-)


Re: Website - Missing kstat man page

2021-01-03 Thread Ingo Schwarze

Daniel Jakots wrote on Sat, Jan 02, 2021 at 11:19:07PM -0500:
> On Sat, 2 Jan 2021 22:57:06 -0500,  wrote:

>> I came across a broken link during some pre-install research.
>> While browsing URL,
>> I noticed URL link on the webpage for kstat(1) generates
>> a "No results found." message when pointing to its man page:
>> Flagged as new, so I was curious about its general function.

> It looks like kstat isn't linked to the build so it's not built by
> default, therefore it's not present on the man.o.o server.

Correct.  To explain why the link is not live yet, i added a sentence

  The userland utility is not yet installed by default.

to the 68.html page.

I guess already having the link even though it is still dead is
intentional such that it springs to life as soon as the kstat(1) utility
will be installed by default.  Otherwise, we would be likely to forget
as release pages from the past are not very actively maintained.


> The source is in src/usr.bin/kstat. If you don't have any src tree
> around, you can either read it on github [1] or you can fetch the raw
> version [2] and give it to mandoc(1)
> [1]: 
> [2]: 
> (I could copy paste the resulting man page in this email, but you'd lose
> all the fancy markup :))
> Actually, mandoc(1) supports html output, here's what it gives

Re: OpenSMTPD-extras manual

2020-12-19 Thread Ingo Schwarze
Hi Maksim & Edgar,

Edgar Pettijohn wrote on Sat, Dec 19, 2020 at 03:37:22PM -0600:
> On Sat, Dec 19, 2020 at 08:02:19PM +0300, ??  wrote:

>> Where can I find any manuals and examples regarding OpenSMTPD-extras?


   $ man -k ^table-
   $ man table-passwd table-socketmap table-sqlite table-redis

>> Which table types are supported and do not have status "experimental"
>> like ldap tables?
>> E.g. what is opensmtpd-extras-python and how can I use it?

Not sure about thise questions.

> Your best bet is to git clone the repository and search for the tables, 
> etc you are interested in.

That would be unusual with OpenBSD; when possible, we try to include
documentation in user-installable packages and not only in source

Strangely, in this case, there are files

  table-postgres.5 table-mysql.5

in the source tarballs but not in the respective packing lists.

Strangely, the tarball also contains three empty README files.

> If there is a manual simply `mandoc file | less`.

Not the best advice ever...  :-/

Manually piping mandoc(1) output to less(1) is never needed.

If you have a manual page in the current directory - say, table-sqlite.5 -
then just

   $ man -l table-sqlite.5

is sufficient, and if it's properly installed, as the opensmtpd-extras
package does it, then just

   $ man table-sqlite

does the job without even needing to worry about the current directory.

> Unfortunantly there aren't manuals for all of the `extras`.

Hmm, you may be right about that one, for example a table-python(5)
manual page doesn't appear to exist.


Re: Making a portable version of imsg - where to find regression tests?

2020-12-12 Thread Ingo Schwarze
Hi Aisha,

Aisha Tammy wrote on Sat, Dec 12, 2020 at 05:40:14PM -0500:

> I was trying to create a small standalone portable version of the
> imsg utilities for linux and I managed to get it compiling (yea!!)
> and have put it on github [1].

I freely admit i didn't look at that.

> It is also working with trivial test cases that I manually generated.
> For completeness, I was also trying to find regression tests for imsg
> but I couldn't find them in the source code (in fact, couldn't find
> them for whole of libutil, make regress just does nothing).

OpenBSD never mixes regression tests into the main directories of the
src tree.  All regression tests are in /usr/src/regress/.  In particular,
those for libutil are in /usr/src/regress/lib/libutil/.

> Could anyone point to where I should look for these regression tests

If somebody wrote any regression tests for imsg, the place to put them
would be /usr/src/regress/lib/libutil/imsg/.

> (if they exist?)

It doesn't appear there are any automated tests for imsg right now.
Several parts of OpenBSD have regression tests, but not all have.


Re: support new

2020-12-09 Thread Ingo Schwarze
Hi Janne,

Janne Johansson wrote on Wed, Dec 09, 2020 at 01:23:23PM +0100:

> There is some,
> "We offer the server management service. We work on the deployment and
> management of servers with open source technologies such as CentOS, Debian,
> FreeBSD, OpenBSD and Ubuntu Server."

Fair enough, sorry for missing that, not sure why i did.

Maybe that's relatively new, it seems not all search engines picked
it up yet.

Anyway, i just added the entry.


Re: support new

2020-12-09 Thread Ingo Schwarze

AMG Labs wrote on Tue, Dec 08, 2020 at 03:55:52PM -0300:

> 0
> C Brazil
> P RS
> T Santo Antonio da Patrulha
> Z 95500-000
> O AMG Labs
> I Angelito Monteiro Goulart
> A Av. Cel Victor Villa Verde 126/301
> M
> U
> B +55 51 92000 7613
> X
> N We are a software development and server management company
> operating in the market since 2014. We work with the development of
> customized web systems and the deployment and management of servers
> based on open source technologies such as CentOS, Debian, FreeBSD,
> OpenBSD and Ubuntu Server.

Unless i'm mistaken, there is no mention of OpenBSD on your website.

The web hosting offers appear to be for Linux and Windows only, and
dedicated servers seem to be offered with Linux, Windows, and MacOS X.


Re: support new

2020-11-29 Thread Ingo Schwarze
Hi, wrote on Sun, Nov 29, 2020 at 01:40:18PM -0300:

> 0
> C Brazil
> P Ceará
> Z 60410442
> O MDFSoftware
> I Oliveira Filho, D. A.
> A Av. Eduardo Girão 355
> M
> U
> B +55-85-9-89739017
> X +55-85-9-96110010
> N Auditoria, Desenvolvimento, Suporte comercial para FreeBSD e
> OpenBSD, gateways de Internet, firewalls em cluster, sistemas de
> deteco de intruso e VPNs.

Your web site does not contain any mention of OpenBSD as far as i can
see, so i'm not adding it right now.

Also, there is almost no content on the web site and none of the
buttons that appear to explain the company's products lead anywhere.
The little text that is there mostly consists of web-scale buzzwords.

Feel free to resubmit after collecting some references to completed
projects and/or some success stories related to OpenBSD.


Re: development best practices

2020-11-28 Thread Ingo Schwarze
Hi Bjoern,

bjoern gohla wrote on Sat, Nov 28, 2020 at 12:27:47PM +:

> i'm fairly new to openbsd. and i've run into the following problem,
> where i want to hack a project (most recently trying to fix a possible
> issue with i3status), but building the from the git source
> tree fails.
> now, in the specific case, i'm trying to build a version that,
> also exists in ports, so we know it can be built on openbsd; and i
> presume the various patches included with the port are what makes it
> work.
> i could of course try to apply those patches and fix my issue. but then
> when i submit a PR upstream i'd have to remove them again. that seems
> cumbersome, expecially if done repeatedly.
> so what is the best practice in this situation? should i just upstream
> the ports patches?

It really depends on the case at hand.

Some patches can be upstreamed, only nobody did the work yet.
Some patches cannot be upstreamed because upstream never makes releases.
Some patches cannot be upstreamed because OpenBSD developers
  disagree with upstream about whether they are needed/useful/right.
Some (few) patches cannot be upstreamed because they deliberately
  change functionality in the OpenBSD port only.

So, let's assume you end up with some patches that will have to
stay or at least to stay for now.

Some of those may be required in the port, but the upstream build
system may at least be able to do builds without them.  Sometimes,
development for upstream purposes can be done without having such
patches in your upstream development tree.

But you may well end up in a situation where a small number of
patches may be required in your checkout of the upstream code to
do upstream-style builds at all.  In that case, you just need to
be careful to not include these patches when sending patches upstream.
And whenever sending patches upstream, you should of course consider
whether those are indeed independent of any other patches you can't
help having in your tree.

Nobody can save you from the work of understanding every single
patch you use before trying to send anything upstream...

These ideas are good enough for a port with moderate amounts of
patches (like textproc/groff).  The x11/i3status port might be of
a similar category.  I have no idea whether working on a behemoth
of the www/chromium kind (which has over 750 patches) and submitting
patches upstream without causing mixups would be feasible on OpenBSD.
There is certainly a limit to practicality, somewhere.


Re: support new

2020-11-17 Thread Ingo Schwarze
Hi Emre,

Emre Kal wrote on Tue, Nov 17, 2020 at 04:55:55PM +0100:

> If my request is rejected again, please provide me with the *objective*
> reasons why I am not allowed to list my services as a OpenBSD consultant.

That won't happen.

> I believe I am entitled

You are not entitled to anything.  The server is a
private server and the OpenBSD project is free to provide the
information it choses.  Just like you are free to advertise your
own services, or the services of other people you choose, on your
own website.  Nobody is entitled to an explanation.

Also note that we do not state the criteria for inclusion, nor are
they written down anywhere.  It's a matter of judgement.

In the past, it was considered whether the page support.html
should be deleted outright, to avoid distracting deevelopers
from development.  Even though i realize that such a page can
never be perfect, i consider it useful, so i committed to maintaining
it as best i can and trying to shield other developers from getting
distracted by it.

I'm not volunteering to follow any formal processes maintaining
it, and i feel convinced there is no need to.

That said, other developers are of course also free to commit
to the page.  But if they choose not to, they don't owe you an


Re: support new

2020-11-16 Thread Ingo Schwarze

i don't care greatly if another developer wants to add this, but i
advise against it.  Talking to this person is a tedious job, he
seems to not understand very well what you say or to not really
listen.  He is also quite bad at explaining stuff and it's hard to
figure out what he is driving at.  So i fear listing him might do
our users a disservice.


Emre Kal wrote on Mon, Nov 16, 2020 at 03:50:24AM +0100:

> 0
> C Turkey
> P
> T Istanbul
> Z 34330
> O Consultant
> I Emre Kal
> A Levent, Besiktas
> M
> U
> B
> X
> N OpenBSD consulting and support. Experienced in OpenBSD httpd,
> relayd and Packet Filter (PF).

Re: groups new

2020-11-01 Thread Ingo Schwarze

Computer Planet wrote on Sun, Nov 01, 2020 at 11:20:03PM +0100:

> 0
> P Cosenza
> T San Marco Argentano
> F Irregular
> O OpenBSD CpnetServer
> I Ernesto Bellomusto
> M
> U
> N OpenBSD | *BSD

Is there any evidence that this group actually exists?
That is, that it meetings were held in the past and/or that
speakers gave talks and/or that the group provides some
resources or information or support online?

If somebody thinks that founding a new group is a nice idea, we
usually don't list the new group until it is somewhat well-established.


Re: support new

2020-11-01 Thread Ingo Schwarze

Computer Planet wrote on Mon, Nov 02, 2020 at 12:07:00AM +0100:

> 0
> P Cosenza
> T San Marco Argentano
> Z 87018
> O Computer Planet
> I Ernesto Bellomusto
> A P.zza Giuseppe Garibaldi, 7
> M
> U 

That line seems inappropriate to me because, as far as i can see,
that page contains no information about your business or services
and no link to a site containing such information. only returns a security warning
("The certificate is not trusted because it is self-signed.") only returns a vague error message
("This was the problem...")

My opionion is that it would be better to provide some information
for the public on your site before adding the link to support.html.


> B 0039 0984513469
> X 0039 0984513469
> N OpenBSD, *BSD, Linux and UNIX-like Server Installation, Training
>   and Support. Over 25 years of experience. 

Re: mailing list management software

2020-10-27 Thread Ingo Schwarze

Craig Skinner wrote on Tue, Oct 27, 2020 at 12:26:03PM +:
> On Thu, 22 Oct 2020 17:12:42 +0300 Gregory Edigarov wrote:

>> is there any mailing list software which naturally supports virtual
>> domains?

> I've found MLMMJ rather good for multiple non-canonical domains:
> http://MLMMJ.Org/

By the way, it's available in ports as mail/mlmmj.

> The configuration files are different for each domain.

It is in use for exactly that purpose on the server,
which serves the mailing lists in two distinct domains:


The configuration is slightly quirky in so far as the configuration
files are not under /etc/, but below /var/spool/, totally mixed up
with all kinds of semi-permanent variable data (like subscriptions)
and also totally mixed up with outright spooling directories.

Documentation isn't exemplary, but sufficient to get it going.

Calling usage "joyful" is probably an exaggeration, but i'm not
aware of a better solution, and frankly, it is good enough for
usual purposes.


> Symlinks can be used to a default setup.
> Perl's Template Toolkit can produce config files.

Re: du man page

2020-10-21 Thread Ingo Schwarze
Hi, wrote on Wed, Oct 21, 2020 at 11:44:01AM +:

> In du(1) it reads:
> [...]
>  Display a summary of files and folders in the current directory,
>  sorted by size:
>$ du -sh * .??* | sort -h
> [...]
> This misses file names of the form .a, .1, etc. Better use something like
> $ du -ahd1 . | sort -h

Committed with three tweaks:

 * The "." is redundant, it is the default for "file",
   as documented in the first paragraph.
 * POSIX recommends a space between an option and its argument,
   and we usually follow that advice in our manuals.
 * I like the word "had" better than the word "ahd".

> Where is the best place to report these trivial documentation fixes?

If you include a patch, tech@.  If you don't, misc@ is fine.


Module name:src
Changes by: schwa...@cvs.openbsd.org2020/10/21 11:00:47

Modified files:
usr.bin/du : du.1 

Log message:
simplify and improve the example by using the -a and -d options;
suggested by , tweaked by me

Index: du.1
RCS file: /cvs/src/usr.bin/du/du.1,v
retrieving revision 1.37
diff -u -r1.37 du.1
--- du.130 Jan 2020 17:54:30 -  1.37
+++ du.121 Oct 2020 16:56:47 -
@@ -151,7 +151,7 @@
 Display a summary of files and folders in the current directory,
 sorted by size:
-.Dl $ du -sh * .??* | sort -h
+.Dl $ du -had 1 | sort -h
 .Xr df 1 ,
 .Xr fts_open 3 ,

Re: Using ports and updates to the release

2020-10-11 Thread Ingo Schwarze
Hi Ed,

Ed Gray wrote on Sun, Oct 11, 2020 at 07:21:32PM +0100:

> I'm still fairly new to openbsd and the idea of using ports
> in general rather than binary packages.

You are usually better off using packages than using ports,
especially as a new user.

Even as an experienced user doing lots of development and minor
amounts of ports development, i use packages most of the time.

In a nutshell, there are only three common reasons to compile a
port yourself:

 * You want to fix bugs in the port or update it and submit patches.
 * Or you want to experiment with local changes to the port.
 * Or you want to do some kinds of testing that require compiling
   from source (many kinds of testing don't require that).

For details, see about packages  # about ports

The latter page says, at the very top,

  The ports tree is meant for advanced users.  Everyone is encouraged
  to use the pre-compiled binary packages.  If you have questions
  about the ports tree, it is assumed that you have read the manual
  pages and this FAQ, and that you are able to work with it.

> Is it necessary to keep the ports tree updated if using a release version
> of openbsd e.g. pulling the stable tree from CVS before building new
> software?

The -release ports tree is compatible with both the -release and
the -stable base system of the same release.  Updating the -release
ports tree to become a -stable ports tree, or updating the relevant
parts of it in the same way, may be useful if you want to re-build
a specific package and a fix was committed to -stable for that
specific port.  But for the most common architectures, -stable
packages are now routinely available on the mirrors in the directory
/pub/OpenBSD/6.7/packages-stable/, so users rarely need the -stable
ports tree.


Re: time_t

2020-10-05 Thread Ingo Schwarze
Hi Peter,

Peter J. Philipp wrote on Mon, Oct 05, 2020 at 05:47:59PM +0200:

> When time_t was made, I think, positive integers meant time forwards, and 
> negative integers meant time backwards from epoch so that people born in 
> 1938 for example could be processed.

  A time() system call first appeared in Version 1 AT UNIX and
  used to return time in sixtieths of a second in 32 bits, which
  was to guarantee a crisis every 2.26 years.  Since Version 6 AT
  UNIX, time() scale was changed to seconds, extending the pre-crisis
  stagnation period up to a total of 68 years.


Re: time_t

2020-10-05 Thread Ingo Schwarze
Hi Rodrick,

Roderick wrote on Mon, Oct 05, 2020 at 03:16:24PM +:

> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
> In my FreeBSD running on a 64 bit processor this type is: int (__32_t).
> It considers this size enough for above information.

> In my OpenBSD running on a 32 bit processor this type is: long long
> (__64_t).
> None of both has an unsigned type, although time moves forward
> (more or less fast!!!).

> Is there a reason for this discrepancy? Is there no standard for the
> size of time_t?

only says:

  time_t shall be an integer type.

> And what does mean the types with __? I find it so confusing. :)

Names starting with double underscores are reserved by the C standard,
for example paragraphs 3.8.8 and 4.1.2 in C89, so an implementation
of the C language can use them internally without risking conflicts
with identifiers defined by conforming application programs.


Re: OpenBSD fakeroot

2020-10-03 Thread Ingo Schwarze
Hi Richard,

Richard Ipsum wrote on Sat, Oct 03, 2020 at 02:35:16PM +0200:
> On Sat, Oct 03, 2020 at 02:21:45PM +0200, Ingo Schwarze wrote:
>> Richard Ipsum wrote on Sat, Oct 03, 2020 at 01:14:07PM +0200:

>>> I needed fakeroot for some tests I'm writing,

>> You are not really explaining what it is that you actually
>> want to do...
>> So i'm guessing a bit:
>> says:
>>   fakeroot runs a command in an environment wherein it appears to
>>   have root privileges for file manipulation. This is useful for
>>   allowing users to create archives (tar, ar, .deb etc.) with files
>>   in them with root permissions/ownership.

> Yeah that's exactly what sfakeroot does. Like I say I looked into
> porting fakeroot, but it was way too complicated for me to be honest.
>> If that is what you need, then the OpenBSD facility serving the
>> same purpuse is documented here:

> Someone told me about that, but I couldn't see how to use it without
> already being root (in order to mount an fs with noperm).
> Maybe I missed something though?

Well, of course, if a machine is to be used for such a purpose,
then of course a system administrator of the machine has to allow
it.  That's the whole purpose of system administration, deciding
what a machine and its various parts can be used for, and by whom.
In this case, root needs to allocate a partition, create a file
system, and mount it with the desired permissions.

But after that, normal users can use the configured resources
in the way they are configured, at any time.

That's not very different from other kinds of making resources
available.  For example, if the system administrator does not enable, you cannot use the microphone, if they do not
mount a file system, normal users cannot access the disk partition,
or if the system administrator doesn't create an account for you,
you can't even log in...


Re: OpenBSD fakeroot

2020-10-03 Thread Ingo Schwarze
Hi Richard,

Richard Ipsum wrote on Sat, Oct 03, 2020 at 01:14:07PM +0200:

> I needed fakeroot for some tests I'm writing,

You are not really explaining what it is that you actually
want to do...

So i'm guessing a bit:


  fakeroot runs a command in an environment wherein it appears to
  have root privileges for file manipulation. This is useful for
  allowing users to create archives (tar, ar, .deb etc.) with files
  in them with root permissions/ownership.

If that is what you need, then the OpenBSD facility serving the
same purpuse is documented here:


Re: support new

2020-10-01 Thread Ingo Schwarze
Hi Ottavio,

Ottavio Caruso wrote on Thu, Oct 01, 2020 at 10:37:22AM +0100:
> On 01/10/2020 09:41, Ingo Schwarze wrote:
>> Mischa wrote on Wed, Sep 30, 2020 at 11:10:27PM +0200:

>>> U
>>> N Hosting OpenBSD VMs on dedicated vmm(4)/vmd(8) servers.

> BTW, for the non-initiated, what is this?

Just read the text at the URI cited above.  It explains in
detail what is.


Re: support new

2020-10-01 Thread Ingo Schwarze

Mischa wrote on Wed, Sep 30, 2020 at 11:10:27PM +0200:

> 0
> C Netherlands
> P
> T Amsterdam
> Z 1083 HN
> O OpenBSD Amsterdam
> I
> A Barbara Strozzilaan 251
> M
> U
> B
> X
> N Hosting OpenBSD VMs on dedicated vmm(4)/vmd(8) servers.

Committed, thanks.

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

2020-09-22 Thread Ingo Schwarze
Hi Demi,

Demi M. Obenour wrote on Mon, Sep 21, 2020 at 12:51:34PM -0400:

> The tool makes essential use of the execpromises argument
> to pledge(2), so that it can sandbox the program it executes.

This appears to conflict with the basic idea of pledge(2), which
is for the *programmer* to first do simple preparatory work that
requires full syscall access, then pledge(2) according to a precise
understanding of what the program is supposed to do during normal
operation.  Usually, it is not possible to properly pledge(2) a
program without designing it for pledge(2), sometimes called
"hoisting".  As a corollary, pledging a program from the outside,
without changing the code that is compiled, usually does not
provide significant benefit.

> While I understand that this argument is slated for removal,
> pledge(1) would not be possible without it.

Exactly, so this is not likely to go anywhere.

> pledge(1) is mainly intended for when the program being sandboxed
> is either potentially malicious,

Even in such cases, pledge(2) needs to be called from *within*
the program.  And that is what porters actually do.  Two examples
of programs that are very obviously malicious are firefox and
chromium.  Still, both call pledge(2) from within.

> If there is interest, I would
> also like to turn pledge(1) into a proper OpenBSD package at some
> point, so that it can be installed using pkg_add(1).

That might (potentially) meet resistance from porters because
it might stand in the way of deleting the execpromises feature
when the time comes.


Re: How do you get different $PS1 for /bin/sh and /bin/ksh?

2020-09-18 Thread Ingo Schwarze
Hi Ottavio,

Ottavio Caruso wrote on Fri, Sep 18, 2020 at 09:22:11AM +0100:

> On a side note, there's no mention of startup files in sh(1)
> and I wonder why.

>From sh(1), second paragraph:

  This manual page describes only the parts relevant to a POSIX
  compliant sh.  If portability is a concern, use only those
  features described in this page.

POSIX does not require that the shell handles any startup files,
neither any with "profile" in the name, nor any with "rc" in the name,
nor any with "login" in the name, see

I does require ENV though, and consequently, sh(1) mentions that.


Re: home printer

2020-09-17 Thread Ingo Schwarze
Hi Carson,

Carson Chittom wrote on Thu, Sep 17, 2020 at 09:51:45AM -0500:
> Jan Stary  writes:

>> Can people please recommend a home laser printer
>> that is known to work well with OpenBSD?
>> I would like to avoid cups, and possibly a2ps
>> and foo* and if= and all that dance
>> - a printer that speaks postscript and is as easy as
>> lp:lp=/dev/lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:

> HP at least used to (and I assume still do) make several decent 
> printers that spoke Postscript.

That answer used to be spot on until about the year 2000.  After
that, quality of HP laser printers went down the drain very rapidly.
One office i worked in decided in 2003 that the then more then five
year old HP LaserJet might die from old age soon and bought a new
one to be safe and not experience service disruption.  The old one
was left running, too, because why not, and printing traffic was
shared about evenly between the two because people tended to use
the one closest to their desk.

When the *successor* of the new one died from old age about six to
eight years later (i.e. when two of the new ones had worn out one
after the other, don't remember how long they lasted exactly, but
not longer than three or four years i think), the old one was still
going strong.  If i remember correctly, when the pre-2000 one finally
did die from old age, it was probably fifteen years old, if not
more, with continuous office use.

I doubt HP printers have become better again, but i'm not sure.

> In particular, I've used the 
> CP1525nw in the past with OpenBSD.  Haven't tried it in a couple 
> years, though; none of my OpenBSD machines need to print, these 
> days.

Same here.  Currently, a Kyocera P2135dn is sitting on the desk here,
but i can't say whether it is good because i'm printing so little.

To the OP, what matters is a decent PostScript Processor
and a RJ45 Ethernet connector, then it will work with OpenBSD
no matter what.


Re: Must disable /usr/libexec/security on backup disks

2020-09-14 Thread Ingo Schwarze
Hi Theo,

Theo de Raadt wrote on Mon, Sep 14, 2020 at 07:27:23AM -0600:

> I am happy enough with the diff, and also dislike having a flag.
> Can we get it commited


> and revisit the situation in 10 years?

I'm sorry, i cannot promise to keep my TODO list in order for ten
years, it often takes less than a month to forget items that should
be on it.

That said, i certainly agree that re-auditing code that hasn't been
looked at for a decade is almost always useful.  Any code.  Provided
that people manage to find sufficient time for reading code.


Re: Must disable /usr/libexec/security on backup disks

2020-09-14 Thread Ingo Schwarze
Hi Brian,

Brian Brombacher wrote on Mon, Sep 14, 2020 at 07:55:11AM -0400:

> Love the idea; however, the only drawback is if some Bad Person
> is twiddling around and leaves a suid or dev around on a file system
> that is nosuid or nodev, you lose visibility.

Doesn't look like a problem to me; that such bits and files are
ignored on file systems with these mount options is the whole point
of these options.  So AFAICT, such files are not special in such
places and hence visibility is not really useful.

> Maybe an option to always scan regardless of fs options?

I dislike options unless there is a really strong need for them.
Why would you want to be notified about SUID files on a nosuid
file system?  What would you want to do about them, and why?


Re: Must disable /usr/libexec/security on backup disks

2020-09-14 Thread Ingo Schwarze
Hi Theo,

Theo de Raadt wrote on Mon, Sep 14, 2020 at 04:06:08AM -0600:
> Ingo Schwarze  wrote:

>> are used for.  Some such file systems may permit SUID and/or device
>> files, so not checking them may be a dubious idea.

> The script could identify mountpoints with safer mount options and
> reduce scanning on them.
> That will also encourage admins to use restrictive mount options when
> possible.

I think that is an interesting idea.  That would be the patch below.
Given that the function find_special_files() looks for SUID, SGID,
and device files, i suggest this logic: skip a mount point if any
of the following is true:

 - it does not have the "local" mount option
 - or it has both the "nodev" and the "nosuid" mount options

I don't think explicitly matching the parentheses is needed.
The code below is simpler and possibly even more robust.

There is one minor downside.  Some people will once get mails similar
to the following:

  Setuid deletions:
  -r-sr-xr-x 2 root ... Mar 29 15:58:55 2020 /co/destdir/base/sbin/ping
  -r-sr-xr-x 2 root ... Mar 29 15:58:55 2020 /co/destdir/base/sbin/ping6
  -r-sr-x--- 1 root ... Mar 29 15:58:56 2020 /co/destdir/base/sbin/shutdown

  Device deletions:
  crw--- 1 ... 79, 0 ... /usr/obj/distrib/amd64/ramdiskA/mr.fs.d/dev/bio
  crw--- 1 ... 23, 0 ... /usr/obj/distrib/amd64/ramdiskA/mr.fs.d/dev/bpf

Nothing changed on disk, but security(8) now skips some file systems.
Then again, i don't think a one-time mail is a serious problem.

I suspect the "$type" test is obsolete and can be deleted because
i don't think any of the file system types afs, nnpfs, and procfs
are supported nowadays, but since that is unrelated, i'm not proposing
to change that in the same diff.  If people agree that should be
deleted, i'll send a separate diff.

> OTOH, Issues complained about a decade late... are often overblown.

Sure, but when somebody has a smart idea (like the one you just brought
forward), there is nothing wrong with polishing small turds, too.

Opinions, concerns, tests, OKs?

Index: security
RCS file: /cvs/src/libexec/security/security,v
retrieving revision 1.38
diff -u -p -r1.38 security
--- security27 Dec 2016 09:17:52 -  1.38
+++ security14 Sep 2020 11:13:47 -
@@ -540,9 +540,10 @@ sub find_special_files {
"cannot spawn mount: $!"
and return;
while (<$fh>) {
-   my ($path, $type) = /\son\s+(.*?)\s+type\s+(\w+)/;
+   my ($path, $type, $opt) = /\son\s+(.*?)\s+type\s+(\w+)(.*)/;
$skip{$path} = 1 if $path &&
-   ($type =~ /^(?:a|nnp|proc)fs$/ || !/\(.*local.*\)/);
+   ($type =~ /^(?:a|nnp|proc)fs$/ || $opt !~ /local/ ||
+($opt =~ /nodev/ && $opt =~ /nosuid/));
close_or_nag $fh, "mount" or return;

Re: Must disable /usr/libexec/security on backup disks

2020-09-14 Thread Ingo Schwarze
Hi Todd,

Todd C. Miller wrote on Sun, Sep 13, 2020 at 03:13:04PM -0600:
> On Sun, 13 Sep 2020 09:17:02 -, Rupert Gallagher wrote:

>> Since /usr/libexec/security runs blindly on every attached storage
>> media, it also runs on mounted tape and backup data volumes.

> It might be best to only check file systems listed in /etc/fstab
> that don't have noauto in the options field.

I'm not convinced about that.  Filesystems that are not automatically
mounted can serve a wide range of purposes.  Some may still be
mounted often, maybe even most of the time, depending on what they
are used for.  Some such file systems may permit SUID and/or device
files, so not checking them may be a dubious idea.

I don't think the OP raised an actual problem.  There are already
two solutions for it.  First, a backup file system should usually
be mounted, populated, and unmounted quickly rather than remaining
mounted all the time, to minimize the risk of damage to the backup.
Of course you do *not* run the backup at the same time as daily(8),
or even if you run the backup from daily.local(8), then you don't
run it in parallel to security(8), so there usually isn't any problem
in the first place.

Even if, for some weird reason, you want to keep the backup mounted
all the time, there is still no problem.  On some such machines,
checking it regularly for dangerous files might even be useful.
In cases where that is not useful, and more so if it causes problems
of some kind, just use SUIDSKIP as documented in security(8).
Only a human can decide which file systems should usefully be
checked, i don't think there is a reasonable way to guess from
fstab(5) or in some other automated way.

To summarize, i don't see why we should change the code.


Re: fido library

2020-08-26 Thread Ingo Schwarze
Hi Mihai,

besides, while it is often useful to bear with newbies,
a user who is no longer a bloody beginner at using computers can
be expected to type simple commands without asking for help, e.g.

   $ cd /usr/src/
   $ find . -name 'Makefile*' -exec grep lfido {} \; -print
  LDADD+= -lfido2 -lcbor -lusbhid
  LDADD+= -lfido2 -lcbor -lusbhid
  LDADD+= -lfido2 -lcbor -lusbhid

   $ man -k fido -a \( sec=1 sec=8 \)   
  ssh-sk-helper(8) - OpenSSH helper for FIDO authenticator support

   $ man ssh-sk-helper | sed '/^D/q'
  SSH-SK-HELPER(8) System Manager's ManualSSH-SK-HELPER(8)

 ssh-sk-helper  OpenSSH helper for FIDO authenticator support

 ssh-sk-helper [-v]



Re: exFAT support

2020-08-06 Thread Ingo Schwarze
Hi John, wrote on Thu, Aug 06, 2020 at 04:28:53PM -0700:

> I was considering making a kernel patch that reported it was
> an exFATfilesystem

Sounds like a layering violation.  The table of file system IDs
is in userland - /usr/src/sbin/fdisk/part.c - rather than in the
kernel, so the kernel is hardly a natural place for figuring out
what kind of filesystem is supposed to be on the partition.

> when the mount failed, which you would see if you were onttyC0, or could
> call up with dmesg, as with the kernel messages thathappen when you first
> plug a drive in.
> Is there a concise "philosophy" of when the kernel should print amessage
> post-boot?  Just when devices are dynamically configured?

I would put it as follows: kernel printf(9) is for
 1. boot messages (before init(8) starts)
(hotplugging hardware is similar even though it happens later)
 2. catastrophic kernel failures (like panics)
 3. catastrophic hardware failures (like a dying disk)
 4. debugging and data collection during active development

System-level errors (in particular from daemons) are usually reported
via syslog(3) instead.  Simply user errors like this one are reported
by the application program on stderr.


Re: Cleaning system's old ibraries/files after update to next -release or -current

2020-07-14 Thread Ingo Schwarze
Hi Ottavio,

Ottavio Caruso wrote on Tue, Jul 14, 2020 at 02:28:25PM +0100:
> On Tue, 14 Jul 2020 at 13:44, Ingo Schwarze  wrote:
>> Martin wrote on Tue, Jul 14, 2020 at 11:11:34AM +:

>>> After system update I found lots of 'old' libraries versions
>>> and possibly binaries from previous releases.
>>> Does anybody know an automated method to remove it after update?
>>> For instance previous libs before update to -current.

>> If you need to ask, just don't remove them.  Those files eat no bread,
>> and in some situations, some of the libs may still be in use.

> What about if one compiles ports? If OpenBSD is anything similar to
> NetBSD, on the latter having multiple libs might cause build
> breakages.

I don't remember ever hearing about anything like that on OpenBSD,
even though i do occasionally compile ports and i always have various
versions of various libraries lying around, both from base and from
ports.  (Given that i am not a very frequent porter, there might be
problems of the more unusual kind that i never heard about, but it's
certainly not something you need to worry about in general.)

If widespread problems caused by old files existed, the readily
available tool to delete old files would probably be advertised
more broadly and maybe even recommended for use.  But as things
are, you can merely use it if you know what you are doing and if
you want to, but at your own risk.  Less experienced users are more
likely to cause themselves trouble trying to use it than to get any
benefit from it.

And no, do not assume that OpenBSD is "like NetBSD" or "like FreeBSD".
They are different operating systems.  Yes, they do have common
ancestors, but the genetic lines diverged about 25 million years
ago.  Err, something like that, IIRC.


Re: Cleaning system's old ibraries/files after update to next -release or -current

2020-07-14 Thread Ingo Schwarze

Martin wrote on Tue, Jul 14, 2020 at 11:11:34AM +:

> After system update I found lots of 'old' libraries versions
> and possibly binaries from previous releases.
> Does anybody know an automated method to remove it after update?
> For instance previous libs before update to -current.

If you need to ask, just don't remove them.  Those files eat no bread,
and in some situations, some of the libs may still be in use.

Too many people come back after doing that, whining "i broke my system,
what can i do now".  That's annoying both for them and for the list.


Re: How do I get the man page for a package I haven't installed yet?

2020-06-27 Thread Ingo Schwarze

Eric Furman wrote on Tue, Jun 23, 2020 at 07:12:33PM -0400:
> On Tue, Jun 23, 2020, at 2:20 PM, Theo de Raadt wrote:
>> Ottavio Caruso  wrote:

>>> Unless I've got it all wrong,  will only
>>> display man pages for programs and commands in base. Is there a way to
>>> display the man page for a package/port I haven't installed and/or
>>> downloaded yet? (This assumes I haven't downloaded the ports cvs
>>> tree).

>> Doing that would be very annoying and painful, and very few people
>> would want it.  It would also substantially degrade the clarity at

> I think the best option is if the program you want to install has
> a web page would be to go there and ask them if they could
> put up the docs you want.

I'm not a fan of that advice.  Usually, it's not a good idea to go
huntiing for documentation on the web because you easily end up
with documentation for the wrong version.  Well, if you pay close
attention to which version you have and which version the documentation
is for, it may occasionally work - if whatever site you find reports
the version and reports it correctly.  It may suffice for a quick
first look to decide whether or not you want to seriously consider
using the software.

If you want to start studying the documentation in earnest, it may
be a better idea to just install the package, even if you don't
plan to run the software right away.  As opposed to systems like
Debian, installing a package you do not want to run is actually
safe on OpenBSD: OpenBSD will not automatically run things just
because you install them.


Re: How do I get the man page for a package I haven't installed yet?

2020-06-27 Thread Ingo Schwarze
Hi Marc,

Marc Espie wrote on Fri, Jun 26, 2020 at 10:43:49PM +0200:
> On Tue, Jun 23, 2020 at 12:20:35PM -0600, Theo de Raadt wrote:
>> Ottavio Caruso  wrote:

>>> Unless I've got it all wrong,  will only
>>> display man pages for programs and commands in base. Is there a way to
>>> display the man page for a package/port I haven't installed and/or
>>> downloaded yet? (This assumes I haven't downloaded the ports cvs
>>> tree).

>> Doing that would be very annoying and painful, and very few people
>> would want it.  It would also substantially degrade the clarity at

Which means that *if* we ever do this, it needs to be a separate
manpath "ports", "ports-current" or something similar, which would
result in URIs like

> Actually, it ought to be feasible to have the same mechanism in place for
> base  as a third party mechanism.
> I don't think it would be that difficult to setup, this obviously ought to
> be separate from the main OpenBSD installation, as the quality of manpages
> from ports is often not up-to-par compared to base.
> Both Ingo and naddy and I, we've been routinely passing all manpages from
> all packages through groff and mandoc and makewhatis to the point that
> over 99% of them would be clean for a usage similar to

Actually, you are mistaken here, i have never done that and i
wouldn't know how to do it.  All i did was look at ports setting
USE_GROFF, triage them, and improve mandoc(1) to handle them.
It is true that naddy helped a great deal with that.

That said, i have heard rumours that sthen@ can run things over all
manual pages in ports but i'm not quite sure, and i have no idea
how he does it.

If there is an easy way to get a tarball of all ports manual
pages (no matter whether for -current, -release, or both), putting
that up would be trivial and not cause significant additional work.
I'm simply not aware of an easy way to get that tarball.


Re: Why does OpenBSD still include Perl in its base installation?

2020-05-21 Thread Ingo Schwarze
Hi David,

Dawid Czelu?niak wrote on Tue, May 19, 2020 at 10:19:23PM +0200:

> I am a huge fan of minimal and custom installations
> as I mostly use OpenBSD to host simple HTTP servers.

That's perfectly fine.  These days, we consider the "minimal
installation" the base file sets, including xbase.  If you want,
you can leave out the game file set and the other x* file sets,
but it makes maintenance significantly harder for no benefit.
Your choice, really.

> I basically use vi to edit httpd.conf file,

Sure.  How else?  I think almost everybody used vi(1) or mg(1) for that.

> obtain a certificate from Let's Encrypt using built-in acme-client,
> then start the server and things just work.

Sure.  That's exactly the same way as i'm maintaining machines like and, too.

> I was wondering if I need the package manager in the minimal
> installation of the system as I only use built-in deamons (httpd, sshd)
> and UNIX utilities (vi, sed)? By package manager I mean
> pkg_* executables as well as its dependencies (most notably Perl).
> (The size of /usr/libdata/perl5 is about 50MB on my machine).
> I just want the minimal installation without any unnecessary
> scripting language. One way to achieve that could be
> to manually remove pkg_* executables and Perl from a machine,
> but it can easily end up with the broken system especially when
> done by unexperienced users.

I can confirm that.  Removing files that come with base in order
to make base smaller is a bad idea.  It tried that 20 years ago
when i already had several years of experience with various flavours
of Unix, and yet i consistently ended up with systems broken in
one way or another.

I did have a moderately good reason back then: i needed to run
OpenBSD (around 2.6 to 2.8 times) on a i386 machine that only had
200 MB of disk space.  Even then, that reason was only moderately
good; buying an additional disk of 4 GB would not have been very
expensive back then, so that would probably have been the most
reasonable choice.  But i did not want to spend money on that
machine, so i chose to, instead of installing any file sets, to
hand-pick the files i wanted, one by one.  That way, i did actually
get a working system, and i used it in production for a number of
years, doing several upgrades in the same way.  I learnt quite a
bit about the purposes of various files in the process.  I never
asked anyone for help with it.

Repeating such a stunt today would be quite pointless.  A 20GB disk
is more than sufficient for doing a base install, and you will have
problems to find a 20GB disk even in the trash.  The disks you will
readily find in the trash are typically at least ten times larger

> But then I thought about
> the second possible way: why not to extract pkg_* executables
> and Perl to the separate file set (pkgXX.tgz)?

As others said, absolutely not going to happen.
I think having fewer sets might provide some benefits,
but splitting sets would be a waste of time and asking for trouble.


Re: OpenBSD sysupgrade rocks

2020-05-20 Thread Ingo Schwarze
Hi Chris,

Chris Bennett wrote on Wed, May 20, 2020 at 02:07:27PM -0400:

> Do the work, a WIP is OK and submit a diff.

Not a bad idea, put your fingers where your mouth is!

> Please don't ask for features, once again.
> Really, I mean it. Don't ask for features!

I disagree.

About one third of the THANKS section of mandoc(1) release notes
typically consists of thanking people who asked for features.

Heck, i have even used presentations at international conferences
to thank people who asked for features.

As an example, i still fondly remember Paul Onyschuk's question
on August 9, 2014:

  "Are there any plans for providing a man(1) command also?  This
  would make mdocml a possible, standalone replacement for the groff
  and man-db combination (typical in Linux distributions)."

My first impulse was to reply "no, i dislike that idea".
Then i reconsidered, and less then three weeks later, it was done.
Nowadays, i could no longer imagine living without it.

For details, see pages 40-44 (marked SURPRISE TOPIC) of these slides:

The "thank you" mention in particular is on page 43.


Re: Why isn't src included with OpenBSD? (documentation)

2020-05-20 Thread Ingo Schwarze
Hi Andras,

Andras Farkas wrote on Tue, May 19, 2020 at 05:26:24PM -0400:
> On Mon, May 18, 2020 at 2:59 PM Ingo Schwarze  wrote:

>> Can somebody work through the tutorial and confirm that everything
>> still works as described with our -current vi(1)?  It is too
>> wordy for my personal taste, so i would hate having to read it all.

> I can do this.  I'll begin sometime this week, and send a report on
> it, and a diff too if necessary.  I'd love to see it included.
> :D

Good, i'll just wait for your results.

> In general: man pages are reference material


> (meant for people who are already familiar with unix or with the man
> page's topic,

I disagree with your definition of "reference manual".  A reference
manual is simply documentation of a tool that is complete, precise,
concise, and organized according to the inner logic of the tool.
Whether the reader is already familiar with the topic has nothing
to do with it.  Which preliminary knowledge is already needed to
even start contemplating a topic has nothing to do with it either.
You can't use the vi(1) tutorial either unless you already know what
these terms refer to: a directory, a file, a text file, a shell, ...

When i want to learn about a completely new tool, i usually strongly
prefer a good reference manual over a good user manual (i.e. an
incomplete manual trying to use simplified terms and to provide
simplified but longer explanations, organized according to didactial
considerations) over a good tutotial (and often i even prefer a
mediocre reference manual over good documentation of any other
kind).  In user manuals and tutorials, i rarely read more than the
section titles.  Reading those titles is occasionally useful to
understand what the software authors consider most relevant for
beginners.  Reading substantial amounts of text in a user manual
or tutorial usually feels like a waste of time to me.  If i need
the tool just once, there is just too much text in non-reference
documentation, and the relevant bits are harder to find.  If i
potentially want to use the tool often, sooner or later, i have to
read the reference manual anyway, so again no point to additionally
read user manuals or tutorials, which are often longer.  (I realise
this in part involves personal learning style, people who like
tutorials and user manuals do exist, but i guess they are less
common among OpenBSD users than elsewhere.)

> often not meant to be read cover to cover,

Most of our reference manuals = manual pages are well suited to
being read from cover to cover, and using them that way is definitely
encouraged.  There are some rare exceptions, though, for example
perlfunc(1) and openssl(1).  (To avoid misunderstanding, of course
they are also well-suited to looking up particular details you
aren't sure you remember correctly.)

> definitely doesn't hold your hand)

When needed, they most definitely do hand-holding.
For example, look at

Often, hand-holding just wouldn't be useful:

> a considerable amount of the documentation (though certainly not all!)
> in /usr/src is tutorial material (meant for learning something for the
> first time, easily read cover to cover, holds your hand) usable by newbs.

If they are correct and work with the current code, tutorials are
appropriate for installation in /usr/share/doc/ - like the mg(1)
tutorial which is already installed there.  Completeness is irrelevant
for tutorials.

If there are few tutorials there, that's likely because OpenBSD
developers were less eager to spend time on them than they were
about spending time elsewhere, and nobody else jumped in either.

We don't want user manuals in OpenBSD because we can't afford the
extra maintenance effort.  Even for a bloody beginner, an outdated
or inaccurate user manual is much worse than a good reference manual.


Re: Why isn't src included with OpenBSD? (documentation)

2020-05-18 Thread Ingo Schwarze
Hi Andras,

Andras Farkas wrote on Mon, May 18, 2020 at 01:07:36PM -0400:

> Lots of documentation is unavailable outside of the /usr/src tree.

It isn't "lots", it's only a tiny number of documents.

> that the answers could be found in
> Fsck_ffs - The UNIX File System Check Program
> This is perfectly fine.

Not really.  If it's reference documentation, it would be better
to have it in the manual page.

Of course, in some cases, whether some piece of information should
be part of the reference documentation or whether it is theoretical
background that would exceed the scope of documentation and be more
adequately explained in a research paper may be a matter of debate.

Explaining the meaning of messages that are displayed to the user
is, IMHO, usually in scope for documentation, unless the meaning
of these messages is totally obvious in the first place.


The ancient non-manual-page roff(7) documents were sacrificed a
decade ago because:

 (1) We want the base system self-contained, and keeping groff -
 which is piece of GNU "C with classes" software - in base
 just to format a handful of historical documents felt
 excessive.  Similarly, writing an -ms input mode for
 mandoc - which would cause a few weeks of work, and add
 probably a few thousand lines of code to the tree -
 also felt excessive for such a small set of documents:
 nobody has been writing new documentation in -ms or -me
 or even -mm for decades.  [kettenis@ did say that he'd
 appreciate a BSD-licensed roff in base, but that would
 cause even more work, so nobody tackled that, either.
 The licensing of the main modern roff implementations (and
 even those unmaintained historical ones that i'm aware of) is
 non-free: groff is GPL (viral), Heirloom and Solaris 10 troff
 are both CDDL (viral), Plan9 is Lucent Public License (polluted
 by verbiage about patents and explicitly asserting U.S. law),
 DWB is Eclipse Public License (viral).]

 (2) While no one denies that some parts of these ancient documents
 can occasionally still be useful, many parts are probably
 outdated since they haven't been maintained for deacdes.
 No one volunteered so far to check their content and
 properly add those parts that still apply to the respective
 manual pages.

 (3) Since they are unmaintained anyway, pointing to old copies
 on the web is not that much worse than having them installed,
 in this special case.  Of course, having the content installed
 would be even better, but it's not trivial to achieve.

> This is a situation I occasionally run into, where useful
> documentation isn't included with OpenBSD, nor is available on
> OpenBSD's website (FAQ, etc).  It's occasional, but it's frustrating
> every time.
> Not only are the USD, PSD, and SMM missing, but other bits of info
> often are, too.

In such cases, as an immediate measure to improve the situation,
please submit a patch to the SEE ALSO section of the respective
manual page.  I'd consider it a documnetation bug if a useful
supplemental document exists, no matter whether in the tree or
elsewehere, but isn't mentioned.

> For example, I first learnt vi a few years ago, back
> when I was first learning Unix, with these files:

Hum, looks like a reference to those files is indeed missing
from the manual page.

Also, i don't see what would be wrong with installing them to
Yes, the tutorial is painfully slow and extremely wordy, and some
parts are hilariously antiquated, like this:
  "Learning a new computer system implies learning a new text editor."
That wasn't even accurate at the time it was presumably written,
probably around 4.4BSD (i.e. almost 30 years ago).  It may have
been more or less true 40 years ago, though.

Can somebody work through the tutorial and confirm that everything
still works as described with our -current vi(1)?  It is too
wordy for my personal taste, so i would hate having to read it all.


Re: [www] list of associated projects: adding rpki-client

2020-05-17 Thread Ingo Schwarze
Hi Alex,

Alex Naumov wrote on Wed, May 13, 2020 at 01:10:47PM +0200:

> since rpki-client has its own home page like other "associated projects",
> it makes sense to add a new link.

Committed with a tweak; i put it next to OpenBGPD.

Thanks for the suggestion,

> Index: index.html
> ===
> RCS file: /cvs/www/index.html,v
> retrieving revision 1.740
> diff -u -p -r1.740 index.html
> --- index.html24 Apr 2020 12:33:07 -  1.740
> +++ index.html13 May 2020 11:08:11 -
> @@ -106,5 +106,6 @@
> +;>rpki-client

Re: TOFU/cert pinning in libtls

2020-05-10 Thread Ingo Schwarze
Hi Lucas,

Lucas wrote on Sat, May 09, 2020 at 06:18:50PM +:

> I experimented with cert FP pinning in the past, too. tls_peer_cert_hash
> is probably what you're looking for. Found it looking at
> /usr/include/tls.h. Then tried to find it referenced in other manpages,
> oolong$ man -k Xr=tls_peer_cert_hash 
> nc(1) - arbitrary TCP and UDP connections and listens
> That's far from ideal IMO,

While -k Xr= is occasionally useful, you should be aware that it does
a substring search, so it only finds manual pages that explicitly
reference tls_peer_cert_hash(3), but not manual pages that reference
the same page under the more usual name tls_conn_version(3) or under
other names like tls_peer_cert_notafter(3).

For example, as tedu@ pointed out:

   $ man -k Xr=tls_conn_version | sed 's/,.*//'

It would be theoretically possible to do this:

 * When searching for "Xr", treat that as a special case as follows:
 * First search for all pages having the Xr expression in their name
   rather than in an Xr macro.
 * Build a list of names from that, possibly including multiple names
   even when only a single page exists.
 * Search for Xr macros containing each of the names in turn
   and show all matching pages.

Then again, it would be quite ugly to implement that.  Doing such a
multi-step search also wouldn't be fast but might take quite some time.
And finally, while in this case, it's clearly what you would want,
in other cases, users might wish to only search for one specific
substring as we currently do, so your proposed behaviour would result
in false positives from their point of view.  Also, the current
behaviour is much easier to explain in the apropos(1) manual page,
which currently just needs to say

  Operator = evaluates a substring,
  while ~ evaluates a case-sensitive extended regular expression.

without having to explain a special case for Xr.

> but I don't know where, of the many tls_*
> manpages, would I reference it.

It is actually already referenced from at least four places in four
different tls*(3) pages.

Also, this is Unix, you can use pipes:

   $ man -k Nm=tls_peer_cert_hash | \  
 sed 's/(.*//; s/,//g; s/\

Re: one-character expansion in shell

2020-05-07 Thread Ingo Schwarze
Hi Philipp,

Philipp Buehler wrote on Wed, May 06, 2020 at 04:03:41PM +0200:
> Am 06.05.2020 15:54 schrieb Ingo Schwarze:

>> Your misunderstandiing is that file names consist of characters.
>> They do not.  They consist of bytes, and to match two bytes,
>> you need two question marks.

> One can hold for the OP; the ksh(1) manpage talks about
> "characters" in 'File name patterns' throughout.
> Just two bytes ;-)

I guess that is because ksh(1) - both the program and the manual
page - predate the idea of multi-byte characters.  The ksh(1) manual
page uses the term "character" troughout when talking about bytes,
not just when talking about globbing.  That becomes clear at various
places, for example:

  [words] which are sequences of characters, are delimited by
  unquoted whitespace characters (space, tab, and newline) or ...
   --> obviously, non-ASCII whitespace is not considered here

  A parameter name is either one of the special single punctuation
  or digit character parameters described below ...
   --> obviously, non-ASCII digits are not considered here

  PS1 [...]   \nnn   The octal character nnn.
   --> obviously, the shell assumes there are at most 512 characters

Even more clearly, the subsection "File name patterns" says:

  alnum   cntrl   lower   space
  These match characters using the macros specified in isalnum(3),
  isalpha(3), and so on.
   --> which explicitly says that "character" refers to single-byte

This is also fairly explicit:

  vi-show8  Prefix characters with the eighth bit set with "M-".
If this option is not set, characters in the range 128-160
are printed as is, which may cause problems.

  string > string  Strings compare greater than based on the
   ASCII value of their characters.

Admittedly, there is a very small number of cases where our
ksh(1) actually does handle UTF-8 multi-byte characters:

 backward-char: [n] ^B, ^X^D
 Moves the cursor backward n characters.

 delete-char-backward: [n] ERASE, ^?, ^H
 Deletes n characters before the cursor.

 delete-char-forward: [n] Delete
 Deletes n characters after the cursor.

 forward-char: [n] ^F, ^XC
 Moves the cursor forward n characters.

There are also cases where it might make sense to handle UTF-8,
but currently characters are just bytes, for example:

 transpose-chars: ^T
 If at the end of line, or if the gmacs option is set, this
 exchanges the two previous characters; otherwise, it exchanges
 the previous and current characters and moves the cursor one
 character to the right.

I admit those few cases where UTF-8 is handled in a best-effort
manner aren't explained in the manual.  They only affect command
line use, not the shell programming language.

Also, the ksh(1) manual is far from alone in tacitly assuming that
characters are single-byte characters.  Consider manual pages like
cat(1), col(1), dd(1), diff(1), dig(1), expr(1), hexdump(1), join(1),
jot(1), patch(1), chdir(2), printf(3), strchr(3), strlcpy(3), etc.

When utilities specifically support multibyte characters, the
respective manual pages usually say so; consider colrm(1), column(1),
cut(1), fmt(1), fold(1), ls(1), mandoc(1), mbtowc(3), wcslen(3),
wprintf(3), etc.

It is unfortunate that the term "character" was first defined as "char",
large bodies of documentation were written, and then it was later
redefined to sometimes mean "wide character" and sometimes "multibyte
character" (which are to different concepts).

I don't have a good solution.  Sometimes, it is possible to explicitly
use the terms "single-byte character", "wide character", and "multi-byte
character", but i'm not convinced it would be a good idea to dig through
all out manual pages and consistently use these three terms everywhere.

In might not become too much of a digression in a very simple page
like strlen(3), but i'm not so sure about a page that is already
long and complicated, like ksh(1).


Re: support

2020-05-07 Thread Ingo Schwarze

Chris Petrik wrote on Wed, May 06, 2020 at 11:57:30AM -0500:

> 0
> P Mississippi
> T Gulfport
> Z 39501
> O Petrik Consulting
> I Chris Petrik
> A 1610 Thornton, Ave
> M
> U
> B 2282650091
> X
> N BSD based consulting in the Mississippi area. We specialize in using
> OpenBSD as our base go-to Operating System for all services requested.

I see weak indications - though admittedly not clear proof -
that this description may not be completely accurate and honest.
The URI you provide does not mention OpenBSD at all as far as i can see
and contains almost no content whatsoever.

Searching your sites with web search engines, this is the only
mention of OpenBSD i managed to find:

  "I have done some changes to my services. Main server still runs
  Debian but it was updated to 10 with DirectAdmin (Too lazy to do
  all the things by hand) My second VPS from Transip was canceled
  and 2 VPS's were purchased.

damon. - OpenBSD 6.6-Stable
bsddev. - FreeBSD Current or version 13

  This will prevent any issues as I like to change things around a lot."

So, before May 2, 2020, you had two machines, both virtual,
and then you got your (first?) OpenBSD machine (and only -stable)?
And now you say "We specialize in using OpenBSD"?

I suggest you resubmit your entry at some point in the future when
it has become clearer that you actually do have experience providing
OpenBSD-based services.


Re: one-character expansion in shell

2020-05-06 Thread Ingo Schwarze
Hi Rudolf,

Rudolf Sykora wrote on Wed, May 06, 2020 at 03:25:09PM +0200:

> is this an expected behaviour?

Yes, that is expected behaviour.

> odin$ ls v?k*
> ls: v?k*: No such file or directory
> odin$ ls v??k*

[ some file names containing two-byte UTF-8 sequences ]

> odin$ locale

The locale is totally irrelevant with respect to file names.
The locale is a user preference.  Different users can set different
locales.  Even the same user can set different locales for different
instances of programs they are running.

By contrast, names of files are system-wide properties.
They are necessarily the same for all users, no matter the locale.

> It seems I have to use double '??' to mach a single character.

Your misunderstandiing is that file names consist of characters.
They do not.  They consist of bytes, and to match two bytes,
you need two question marks.

You can use all kinds of bytes in file names, there are very few
restrictions: e.g. you cannot use a slash in a file name, and you
cannot manually create a file called "." or "..".

However, it is best practice to only use printable non-whitespace
ASCII bytes in file names.  It is well-known that using whitespace
characters in file names poses notorious security hazards.  Using
non-printable or non-ASCII bytes usually causes confusion, so it
certainly isn't recommended either.

That said, people sometimes have to deal with files named by other,
careless or reckless people, so OpenBSD tries to handle file names
in a best-effort manner when they contain unusual bytes.  For
example, when a file name contains byte sequences that can be
interpreted as UTF-8, ls(1) in xterm(1) displays these byte sequences
with the corresponding Unicode glyphs if you have set a UTF-8 locale.
But that doesn't imply filenames suddenly use UTF-8 in any sense.


Re: pkg_add -u: no such dir

2020-05-05 Thread Ingo Schwarze

Groot wrote on Tue, May 05, 2020 at 04:58:34PM +0530:

> I tried updating all applications, only to be greeted with 
> the following message. 

You don't say so explicitly, but let's assume you upgraded to the
latest snapshot.  While that is not the final 6.7 release yet,
the operating system release string as returned by "uname -r"
was already switched to "6.7" (without -beta) in preparation
for release, so your upgraded system already tries to use 6.7
release packages, which do not exist yet.

> doas pkg_add -u 
> no such dir
> list of applications
> I'm sure someone must have noticed by now.
> Only the directories within 
> give 404 Not found error in a browser.

That's expected.

For now, use "pkg_add -u -D snap" as documented here:


Re: /bin/sh echo \n

2020-04-26 Thread Ingo Schwarze

Martijn van Duren wrote on Sun, Apr 26, 2020 at 12:52:38PM +0200:
> On 4/26/20 12:27 PM, Thomas de Grivel wrote:

>> Second I don't see this feature described neither in man sh nor man
>> ksh so is it a known behaviour of ksh ?

> from echo(1):
> echo does not support any of the backslash character sequences mandated
> by XSI.
> from ksh(1):
> See the print command below for a list of other backslash sequences that
> are recognized.
> ...
> By default, certain C escapes are translated.

So Martijn answered this almost exhaustively.

My only point to add is that i consider it intentional that the
sh(1) manual page does not mention the "echo" builtin because "echo"
cannot be used portably in a /bin/sh program (at least not with
variable expansion following it), and the sh(1) manual starts like

   This manual page describes only the parts relevant to a POSIX
   compliant sh.  If portability is a concern, use only those
   features described in this page.

In conclusion, i think there is nothing to fix in the documentation,
neither in echo(1) nor in ksh(1) nor in sh(1).


Re: More than 16 partitions

2020-04-24 Thread Ingo Schwarze
Hi Strahil,

Strahil Nikolov wrote on Thu, Apr 23, 2020 at 11:16:41PM +0300:

> And who the hell needs more than 16 partitions ?

Me, and i'm quite sure many do.  It's certainly not a good idea to
combine any partitions that are separate in a default install because
there are good reasons for all the separations.  Then, on a development
machine, i want separate partitions for src, xenocara, ports and
the related obj partitions.  Then i need a noperm partition for
building releases.  And because i sometimes work on free software
projects outside OpenBSD, i want a partition for source code control
checkouts of other projects.  I certainly don't want to to mix /co/
that into /home/ or /usr/src/.

At this point, here is the bare minimum i typically have:

 01 a /
 02 b swap
 03 c whole disk
 04 d /tmp nodev nosuid
 05 e /var nodev nosuid
 06 f /usr nodev
 07 g /usr/local   nodev wxallowed
 08 h /usr/src nodev nosuid
 09 i /usr/obj nodev nosuid
 10 j /usr/xenocaranodev nosuid
 11 k /usr/xobjnodev nosuid
 12 l /usr/ports   nodev nosuid
 13 m /usr/ports/pobj  nodev nosuid wxallowed
 14 n /co  nodev nosuid
 15 o /co/destdir  nodev noexec noperm
 16 p /homenodev nosuid

So, i'm out of partitions before i even start doing anything even
mildly special.  I don't even have a single spare partition, even
though having that would be quite useful for better keeping track
of unused space on the disk that i might keep around for maybe using
it later.

The limitation to 16 partitions definitely feels painful to me.

> Why not we just port ZFS from FreeBSD, or LVM from Linux

For starters, neither are free software.  Both are encumbered with
very restrictive licenses that prevent using them last time i looked
(CDDL and GPL).  Besides, OpenBSD values code that is small, simple,
and easy to audit, so i'm not sure whether these would qualify even
if they were free.  So trying to port them would be a waste of time.
Trying to port HAMMER from DragonFly might be worthwhile, but a
huge and difficult project, and i'm not sure it is related to the
limitation of the number of partitions.


Re: timegm()

2020-04-24 Thread Ingo Schwarze
Hi Todd,

Todd C. Miller wrote on Wed, Apr 22, 2020 at 09:21:28PM -0600:
> On Thu, 23 Apr 2020 04:21:42 +0200, Ingo Schwarze wrote:

>> Calling timelocal(3) deprecated makes sense to me because it is
>> nothing but a trivial wrapper around mktime(3), and the latter
>> is standardized, while timelocal(3) is not.
>> But i don't quite see why timegm(3) should be marked as deprecated:
>> sure it was never standardized, but i don't see a better portable
>> way to achieve the same.
>> Consequently, i suggest dropping millert's deprecation notice
>> from timegm(3) and instead adding the missing STANDARDS and
>> HISTORY sections.

> That's fine with me.  Those interfaces appeared in SunOS 4.0 according
> to tzcode (which is where we got them from).  They did *not* originate
> in NetBSD.  I've verified that they were present in SunOS 4.1.3U1,
> though that code appears to be derived from tzcode too.
> I would suggest that the HISTORY section be updated accordingly if
> you feel the need to document their origin.
> If you look at the 4.4BSD ctime.c you'll see that Keith actually
> removed timegm() after updating it from tzcode.
> D 5.16 89/03/16 20:34:41 bostic 22 21
> remove offtime, timegm, timeoff
> D 5.15 89/03/12 16:32:29 bostic 21 20
> latest Olson/Harris time package

Thanks for doing that research and also for checking the rest of
the patch.  I tweaked the patch according to your findings and
committed it.

> The reason they were marked as deprecated is that tzcode has a
> comment that "These functions may well disappear in future releases
> of the time conversion package".  However, that hasn't happened in
> at least 30 years so it seems likely that they are here to stay...

Sorry for calling you a muppet even though all you actually did was
quoting the opinion muppets, a single time about two decades
ago.  ;-D

> Note that we also provide timeoff() but don't document it.

I have no strong opinion whether we should document it.
Maybe not?  I never felt a need to use it, and it isn't
standardized.  Are you suggesting that maybe we should?
I wouldn't oppose that either.


Re: timegm()

2020-04-22 Thread Ingo Schwarze

Theo de Raadt wrote on Wed, Apr 22, 2020 at 12:11:56AM -0600:
> William Ahern  wrote:
>> On Tue, Apr 21, 2020 at 02:01:10PM +0200, Otto Moerbeek wrote:
>>> On Tue, Apr 21, 2020 at 10:51:54AM +, Roderick wrote:

 Acording to the man page: "timegm() is a deprecated interface that
 converts [...]"
 O.K., deprecated. And what is the alternative?

>>> The paragraph above it (discussing timelocal()) suggests it's
>>> mktime().

>> There is no alternative to timegm that is thread-safe. timegm is widely
>> supported, including BSDs, glibc, musl; it shouldn't be deprecated, IMNSHO.
>> Solaris even recently reintroduced timegm (with 11.4) after having removed
>> it years ago.

> It is marked deprecated.
> That doesn't mean it is going away.
> It's just a pseudo-legal term by a bunch of muppets.

The particular muppet here appears to be known by the name of millert@ ;-)

revision 1.23
date: 2000/08/22 14:21:23;  author: millert;  state: Exp;  lines: +23 -3;
Quickly describe timelocal() and timegm() and note that they are
deprecated interfaces.

Calling timelocal(3) deprecated makes sense to me because it is
nothing but a trivial wrapper around mktime(3), and the latter
is standardized, while timelocal(3) is not.

But i don't quite see why timegm(3) should be marked as deprecated:
sure it was never standardized, but i don't see a better portable
way to achieve the same.

Consequently, i suggest dropping millert's deprecation notice
from timegm(3) and instead adding the missing STANDARDS and
HISTORY sections.

timegm(3) and timelocal(3) are neither in the final state of the
4.4BSD SCCS repo nor in 386BSD, but first appear here:

That is between NetBSD 1.0 (Oct 94) and 1.1 (Nov 95).

The STANDARDS stuff is easy to verify from C89, C11, and POSIX, the
v5 stuff from TUHS, difftime and mktime from the CSRG history, and
the addition of the four *_r() functions from our own CVS history.

While here, purge the non-standard section name NOTES; the normal
name for such a section is CAVEATS.


Index: ctime.3
RCS file: /cvs/src/lib/libc/time/ctime.3,v
retrieving revision 1.44
diff -u -r1.44 ctime.3
--- ctime.3 14 Sep 2015 13:08:01 -  1.44
+++ ctime.3 23 Apr 2020 02:13:54 -
@@ -201,7 +201,7 @@
 .Fa tm_isdst .
 .Fn timegm
-is a deprecated interface that converts the broken-down time, as returned by
+converts the broken-down time, as returned by
 .Fn gmtime ,
 into a calendar time value with the same encoding as that of the values
 returned by the
@@ -295,12 +295,68 @@
 .Xr tzset 3 ,
 .Xr tzfile 5 ,
 .Xr zic 8
+The functions
+.Fn asctime ,
+.Fn ctime ,
+.Fn difftime ,
+.Fn gmtime ,
+.Fn localtime ,
+.Fn mktime
+conform to
+.St -ansiC .
+The functions
+.Fn asctime_r ,
+.Fn ctime_r ,
+.Fn gmtime_r ,
+.Fn localtime_r
+conform to
+.St -p1003.1-2008 .
+The functions
+.Fn timegm
+.Fn timelocal
+are extensions to these standards.
 .Fn ctime
 function first appeared in
 .At v1 .
+The functions
+.Fn asctime ,
+.Fn gmtime ,
+.Fn localtime
+first appeared in
+.At v5 .
+The functions
+.Fn difftime
+.Fn mktime
+first appeared in
+.Bx 4.3 Reno .
+The functions
+.Fn timegm
+.Fn timelocal
+have been available since
+.Nx 1.1
+.Fn asctime_r ,
+.Fn ctime_r ,
+.Fn gmtime_r ,
+.Fn localtime_r
+.Ox 2.5 .
 The return values
 of the non re-entrant functions
 point to static data;

Re: List a package's dependencies

2020-04-20 Thread Ingo Schwarze
Hi Marc,

Marc Espie wrote on Mon, Apr 20, 2020 at 03:05:36PM +0200:

> Actually, not having recursive depends easily available on an installed
> package base is  somewhat tedu-ish.

Heh.  :-)

> Most specifically, it's not very useful for anything in common usage.  What
> would you want it for ?...  sure it's nice information, but in practice,
> unused dependencies from former ports get gc'd with pkg_delete -a...
> ... and if you're actually tinkering with dependencies, it's generally
> related to the ports tree proper, and there is a plethora of targets in
> there... along with indeed, sqlports which can give you all the info that
> you need, assuming a bit of sql magic.

Those look like good points.

I think you are right that the occasional times i was looking for
lists of recursive dependencies where when i was working on some
port, not when i was merely using a package, so going to the ports
tree and running make(1) didn't cause any real inconvenience.

I think your explanation helps to understand the choice to not
provide this particular knob better.  And yes, i definitely appreciate
that it's a very complex task to keep all the moving parts of the
pkg/dpb system working reliably, including for all the special cases
needed for such a large tree.


Re: List a package's dependencies

2020-04-19 Thread Ingo Schwarze
Hi Chris,

Chris Rawnsley wrote on Sun, Apr 19, 2020 at 01:34:28PM +0100:

> I am looking for a way to show a package's dependencies.

As far as i know, the normal ways to do that are:

  # direct run dependencies only
  cd /usr/ports/mail/mutt; make run-depends-list
  cd /usr/ports/mail/mutt; make show=RUN_DEPENDS

  # direct library package dependencies only
  cd /usr/ports/mail/mutt; make lib-depends-list
  cd /usr/ports/mail/mutt; make show=LIB_DEPENDS

  # direct run and library package dependencies only
  pkg_info -qf mutt | grep ^@depend
  grep -F '|mail/mutt|' /usr/local/share/ports-INDEX | cut -d \| -f 8

  # direct build dependencies only
  grep -F '|mail/mutt|' /usr/local/share/ports-INDEX | cut -d \| -f 9
  cd /usr/ports/mail/mutt; make build-depends-list

  # all run dependencies, recursive
  cd /usr/ports/mail/mutt; make print-run-depends
  cd /usr/ports/mail/mutt; make full-run-depends
  cd /usr/ports/mail/mutt; make show-run-depends
  cd /usr/ports/mail/mutt; make run-dir-depends

  # all shared library dependencies, recursive
  pkg_info -qf mutt | grep ^@wantlib

  # direct run and package library dependencies, and all shared libs recursive
  pkg_info -qS mutt

  # all build dependencies, recursive
  cd /usr/ports/mail/mutt; make print-build-depends
  cd /usr/ports/mail/mutt; make full-build-depends
  cd /usr/ports/mail/mutt; make build-dir-depends

  # all dependencies, recursive
  cd /usr/ports/mail/mutt; make full-all-depends
  cd /usr/ports/mail/mutt; make all-dir-depends

The above list is not complete.  For example, i skipped ways to
inspect test dependencies, and i refrained from explaining
possibilities that use the port "databases/sqlports", which
is very powerful.  Finally, i may have missed some ways this
can be done.

All this is kind of typical for the pkg tools: one question typically
allows several different answers.  There typically isn't one single,
canonical way of doing something.  There typically isn't one unified
output format, but several different ways to represent information
in the output.  Part of that is due to the unavoidable complexity
of the system.  Other parts may be influenced by the fact that
espie@ is not tedu@.

> Does such a command such as this already exist? I guessed that the
> pkg_* tools would have this covered but I was not able to find it
> in the manpages.

Yes, finding stuff in the pkg/ports manual pages sometimes isn't
easy due to their size and complexity - even though they are typically
concise, at times even terse.

> In making the above example, I created a proof of concept shell
> script that demonstrates the desired behaviour.

We certainly don't need yet more ways to do the same, and certainly
not by creating wrappers around what is already there.  Besides,
directly inspecting the contents of /var/db/pkg/ by anything that
is not part of the pkg tools is fragile and not acceptable.

All that said, it might be useful if, in addition to -S, pkg_add(1)
could recursively list run-time dependencies.  That isn't possible
for packages that are not installed, but it should be possible to
implement for installed packages.  The current situation is
arguably not ideal for users since i don't see a way to recursively
get run-time dependencies without either

 * going to /usr/ports/ and running make(1)
 * using databases/sqlports
 * writing your own script recursively calling "pkg_info -qS",
   then postprocessing with sort(1) and uniq(1)


Re: Does Intel driver supports Intel g31?

2020-04-11 Thread Ingo Schwarze

infoomatic wrote on Sat, Apr 11, 2020 at 05:41:44PM +0200:

> I suggest you read on the documentation instead of throwing one-line
> questions to the mailing list.
> The documentation is excellent, just look for the information you need.

So far, so good.


But please do not recommend for use with OpenBSD.

That is a NetBSD site.  OpenBSD and NetBSD are different operating
systems and work differently in several respects.  That includes
significant differences in how the ports trees work.  The software
running on doesn't properly understand the OpenBSD
ports tree, often resulting in incomplete and misleading statements
being presented on that site.

Rather than taking chances and getting hurt using,
people should use the official sources of information, in
particular the following OpenBSD ports:

portslist-7.27  full list of pkgpaths in ports
sqlports-7.27   sqlite database of ports
pkglocatedb-1.5 database of packages for use with locate(1)

See also:


Re: Does Intel driver supports 3d acceleration?

2020-04-11 Thread Ingo Schwarze
Hi Otto,

Otto Moerbeek wrote on Sat, Apr 11, 2020 at 12:16:40PM +0200:
> On Sat, Apr 11, 2020 at 03:52:34PM +0600, Nikita Stepanov wrote:
>> Does Intel driver supports 3d acceleration?

> What prevents you from looking up the man page and reading it?

Lazyness, obviously.  All the more so as i already posted the
link to that very manual page, in a post replying specifically
to him.

Replying to him was clearly a mistake, sorry for that.
I suggest we now stop feeding that obvious troll.


Re: Nvidia driver for OpenBSD?

2020-04-10 Thread Ingo Schwarze

Christopher Turkel wrote on Fri, Apr 10, 2020 at 02:49:56PM -0400:
> On Friday, April 10, 2020, Nikita Stepanov wrote:

>> Subject: Nvidia driver for OpenBSD?

> None exist or are likely to ever exist.

The question from the original poster was so imprecise and lazy
that no one else bothered to answer, but your answer is just plain
wrong, so it has to be corrected.

Here is a better answer, and even that is likely incomplete:

That said, OpenBSD developers typically strongly discourage buying
NVIDIA graphics cards because NVIDIA traditionally doesn't provide
hardware documentation for the graphics cards they produce, so
drivers for NVIDIA graphics cards are typically of vastly lower
quality than for intel(4) and radeon(4) cards.  In particular - but
that's far from the only problem as far as i heard - there is no
drm(4) support for NVIDIA cards.


Re: - certain https URLs downgraded to http in redirection

2020-04-04 Thread Ingo Schwarze
Hi Constantine,

Constantine A. Murenin wrote on Tue, Mar 31, 2020 at 01:24:30PM -0500:

> What you say makes no sense

I wouldn't go that far; i think Aham has a point, even though it
certainly isn't a critical nor an urgent problem.

> for one simple reason: man.cgi (and cvsweb) moved out of
> ages ago, prior to there being any https on (correct me
> if I'm wrong here),

Not sure, maybe.  I don't feel like spending time on trying to find
out, it doesn't seem that important.

> so, there should not be any legitimate organic links that would be
> linking to https towards in the first place;
> as such, there's little reason to change anything here.

Who knows what links people may have put into their web pages at
which times and for which reasons or what they type in their browser
address bars; those are not very pressing questions either.

The reason the redirection wasn't changed yet to avoid redirecting
incoming HTTPs connections to HTTP URIs elsewhere merely is that
the people having the necessary access to the server
are busy and apparently don't consider it a priority to improve
this particular detail.

While i do maintain, i don't have access to, and i'm not sure i even want such access.


Re: Contributing to spamd

2020-04-03 Thread Ingo Schwarze
Hi Aisha,

Aisha Tammy wrote on Fri, Apr 03, 2020 at 08:54:22AM -0400:

>   I have been using spamd for quite a while and have been loving it.
> I've seen that spamd currently only supports ipv4 and have been
> wondering if it was possible to extend it to ipv6. I know that workforce
> is always limited so I wanted to know if there is anyway to contribute
> help towards this :)

The way to contribute to OpenBSD is by sending patches - ideally
small, incremental patches that work and are well tested, but when
you get stuck, you can also send something like: "I hope to do
FOOBAR, and here is what i have so far; the FOO part already seems
to work in my preliminary testing, but i have doubts whether my
approach to the BAR part is ideal.  Feedback is welcome."

> I admit I'm not the most knowledgeable about ipv6 so I was wondering if
> there is any small place to start to contribute to spamd and build up
> from there.
> Hoping for some positive response.

Being able to learn on your own is among the key qualifications
required to contribute to OpenBSD.  Learning by doing is recommended:
First find an issue you would like to fix.  Good judgement of your
own abilities is essential here: don't pick a task so much over
your head that you have no chance of ever getting it done.  Picking
something *slightly* more difficult than what you have experience
with may be OK if you are willing to learn and can tolerate the
frustration that unavoidably comes with the first try likely not
being good enough for commit yet.  Then again, getting used to the
the processes of sending patches, receiving feeback, and improving
and re-sending the patches such that they get ready for commit may
also require some effort, so it is not a bad idea to start with
tasks you are absolutely sure you can easily manage, until you get
used to the processes, then progress to more difficult stuff in order
to learn and grow.

When asking questions, be as specific as possible, ideally showing
specific patches or specific sequences of commands and asking
specific questions about them.

Avoid questions similar to "what should i do" or "where should i
start" or "is there a todo list".  That depends on what you are
interested in and what your abilities are, and you need to know
that yourself, no one else who doesn't know you personally can help
you with that.

Sorry that i can't give you specifics about spamd(8), but your
question wasn't very specific anyway.  In general, seamless IPv6
support is welcome in OpenBSD, but i'm not sure about the requirements
of spamd(8) in particular since i never used it nor worked on it.


Re: reviewing what is available

2020-04-01 Thread Ingo Schwarze
Hi Luke,

Luke A. Call wrote on Wed, Apr 01, 2020 at 01:36:49PM -0600:
> On 04-01 12:47, Chris Bennett wrote:
>> On Wed, Apr 01, 2020 at 07:01:15AM -0600, Diana Eichert wrote:

>>> have you considered looking at native OpenBSD tools?

>> Wow! I had no idea about this.

> I think you know more about obsd than I do, but in case it's useful to
> anyone else:
> I didn't know about egre(4) either, but I am trying to go
> gradually thru the process of seeing "what is there" by browsing to
>, putting a single period (".") in the search field,
> choose a section, click apropos, and methodically reading.

As jmc@ made me aware recently, an equal sign (or even better: Nm=)
is faster than a period because it doesn't need to evaluate a regular
expression for each and every manual page in the database.  ;-)

By the way, you can do that from the command line, too, no need
to access the Internet:

   $ man -s 2 -ak Nm=

then type


and hit the "enter" key.  If you aleady know about the stuff shown
at the top of the screen, just hit the


key once, or as many times as the top of the screen seems familiar.
Even if you decide to study something and move around with arrows
up and down and search with the "/" and "?" keys, hitting the "t"
key again later will get you to next manual page from the place
that you last jumped to with "t".  If you get very confused as to
where you stopped and whether you maybe skipped anything, hit "T"
(= Shift-t) until you see something familiar, then move forward
again with "t" as before.

The "man -s 2 -ak Nm=" feature has been working for a long time, for
multiple -stable releases, but for the ":tNAME" and "t" sugar, you
nead a *really* current -current, as in, from a few minutes ago,
or tomorrow's (amd64) snapshots, or later for slower architectures.


> Lots of good
> stuff and some surprises (for me at least) in there.  If I hadn't
> done that once with debian (years ago), I wouldn't know about touch(1),
> for example, and a bunch of other things.
> Again, you know more than I, so no insult intended.  :)

Re: How to test for FORTIFY_SOURCE?

2020-03-20 Thread Ingo Schwarze
Hi Luke,

Luke A. Call wrote on Wed, Mar 18, 2020 at 12:54:10PM -0600:
> On 03-18 19:22, Ingo Schwarze wrote:
>> Theo de Raadt wrote:

>>> Ingo -- I think using as a "testbed for all possible
>>> man page hierarchies" incorrect.

>> It was never a testbed, but a production service with several parts
>> provided nowhere else (well, at least until FreeBSD followed our
>> lead and started providing something very similar).
>> For example, for DragonFly, Illumos, and NetBSD, semantic searching
>> is neither supported by their native apropos(1) on the command line
>> nor by their own websites.
>> But since you have a point that such services hardly belong
>> on *, they are now on *, where misunderstandings
>> like the one witnessed above are unlikely to happen.

> Providing a simple link from the page to the services
> on * might help those who are used to looking in the old
> location, while avoiding possible "which bsd" confusion (maybe called 
> "Some other systems' manuals", or such).  Especially for those not
> reading this thread.  Just a thought.

Makes sense, done.

Note that in addition to, is now also
up and running, but the latter will only contain release manual
pages for a number of systems (including OpenBSD) but not


Re: groups new

2020-03-18 Thread Ingo Schwarze
Hi Jan,

Jan Prunk wrote on Wed, Mar 18, 2020 at 06:08:26PM +0100:

> 0
> C Slovenia
> P SI
> T Ljubljana
> F Irregular
> O BSD User Group Slovenia
> I Jan Prunk
> M
> U
> N *BSD

I suggest you resubmit when a few meetings have taken place.
So far, i see no evidence of any activity.

The website looks as if it is unchanged since September 6, 2018,
and it says "Website is in a starting phase".

The mailing list seems to have four members and two postings,
both in December 2018 and both posted by the same person.


Re: How to test for FORTIFY_SOURCE?

2020-03-18 Thread Ingo Schwarze

Theo de Raadt wrote on Wed, Mar 18, 2020 at 12:44:03PM -0600:
> Ingo Schwarze  wrote:
>> Jeffrey Walton wrote on Wed, Mar 18, 2020 at 11:55:53AM -0400:

>>> I assumed OpenBSD and NetBSD were collaborating and shared code
>>> and docs in some places.

>> To a limited extent, that is true.

> To a limited extent, it is true that birds and fish are friends.
> In other words, it is untrue.  There isn't collaboration.

I have definitely collaborated with at least these NetBSD developers
in the past:

 * Joerg Sonnenberger (joerg@)
 * Thomas Klausner (wiz@)
 * Christos Zoulas (christos@)

"Collaboration" in the sense that there was consistent working
together on joint projects for months, with Joerg even for years.
Besides, Sevan Janiyan (sevan@) has been one of the most prolific
mandoc release testers for four years now, to the point that i might
call that collaboration.  Eight other NetBSD developers have provided
minor contributions over the years, the overall effect of which
also feels like systematic collaboration to me.

Similar effects exist for FreeBSD (bapt@) and Debian (stapelberg@)
and to a lesser degree for Illumos (Yuri Pankov) and Void Linux (Leah

I even attended a mini-hackathon organized by a NetBSD developer
in the past, and the code both the NetBSD developer and i wrote
there is still part of both OpenBSD and NetBSD.  That is certainly
worth being called collaboration.

> And there isn't sharing.  At best there is freely given stuff which
> is sometimes taken.  I propose not using the word "share" since people
> may believe it is one of the stronger meanings of the word.  At best
> it is the weakest meaning.

It seems true that "freely give" is not as easily misunderstood
as "share".


Re: How to test for FORTIFY_SOURCE?

2020-03-18 Thread Ingo Schwarze
Hi Jeffrey,

Jeffrey Walton wrote on Wed, Mar 18, 2020 at 11:55:53AM -0400:

> I assumed OpenBSD and NetBSD were collaborating and shared code and
> docs in some places.

To a limited extent, that is true.

For example, NetBSD includes mandoc(1) which is predominantly
developed on OpenBSD while OpenBSD includes editline(7) which
is predominantly developed on NetBSD.

But that doesn't mean either system slavishly copies changes
from the other, nor that components both contain work in
exactly the same way.  Developers of both systems use their
own judgement to decide what to merge from the other system,
and when.

So please do use the documentation from the right system even
for those components that are very similar on both, or you will
sooner or later stumble over some subtle difference.


Re: How to test for FORTIFY_SOURCE?

2020-03-18 Thread Ingo Schwarze
Hi Theo,

Theo de Raadt wrote on Wed, Mar 18, 2020 at 09:06:25AM -0600:
> Jeffrey Walton  wrote:

>> What is the purpose of supplying man pages for the wrong operating
>> system?

The purpose is to make it simpler to compare how different systems
work without having to jump back and forth among different sites
using different URI schemes and running different software.  Also,
the man.cgi(8) from the mandoc toolset is way better than the software
running on,,, and, which provide neither semantic searching nor tagging/deep
linking of comparable quality.

Note that now also runs the man.cgi(8) from the
mandoc toolset - after several years hoping to switch to it, they
finally did it.

>> It wastes people's time and breaks search. This search does
>> not produce expected results:

Do not search the web for software documentation.  That's a bad idea
in the first place.  You are likely to end up with documentation for
the wrong version of the software in question, which is exactly
what happened to you here.  Use autoritative documentation for the
system you are interested in, instead.

>> If you really want to confuse folks, maybe OpenSD can supply
>> Windows man pages.

> I'm going to stand up and agree.

You have a point that non-OpenBSD manual pages are better served
from the *portable* mandoc site than from
So i just deleted the non-OpenBSD lines from manpath.conf

For now, comparing different systems can be done here:

That URI is quite ugly, i'll try to figure out whether i can move
that to simply

> Ingo -- I think using as a "testbed for all possible
> man page hierarchies" incorrect.

It was never a testbed, but a production service with several parts
provided nowhere else (well, at least until FreeBSD followed our
lead and started providing something very similar).

For example, for DragonFly, Illumos, and NetBSD, semantic searching
is neither supported by their native apropos(1) on the command line
nor by their own websites.

But since you have a point that such services hardly belong
on *, they are now on *, where misunderstandings
like the one witnessed above are unlikely to happen.


Re: Start point to learn OpenBSD programming

2020-03-16 Thread Ingo Schwarze
Hi Martijn,

Martijn van Duren wrote on Mon, Mar 16, 2020 at 09:24:26PM +0100:
> On 3/16/20 9:22 AM, Ingo Schwarze wrote:
>> Martijn van Duren wrote on Mon, Mar 16, 2020 at 08:52:54AM +0100:

>>> On 3/16/20 8:23 AM, Martin wrote:
>>> If you want reading material find a function you don't understand and
>>> lookup the manpage. If you want to have a more adventurous approach:
>>> $ PAGE=$(ls /usr/share/man/man[23] | sort -R  | head -1); \
>>> man ${PAGE##*.} ${PAGE%.*}

>> That can be simplified:
>>   $ man -l $(ls /usr/share/man/man[23]/*.[23] | sort -R  | head -1)

> Who said I went for simple?

You said so implicitly, in so far as you are doing good work on
OpenBSD.  :)

> I even left a minor bug in there for Martin to find. :-)

Indeed!  Which proves again that while randomization is important,
it is easy to cause subtle heisenbugs with it.  And i consciously
chose to not point it out but silently fix it, to avoid having to
mark my posting as [SPOILERS].


Re: Start point to learn OpenBSD programming

2020-03-16 Thread Ingo Schwarze
Hi Martijn,

Martijn van Duren wrote on Mon, Mar 16, 2020 at 08:52:54AM +0100:
> On 3/16/20 8:23 AM, Martin wrote:

>> The best way for beginner to start with OpenbBSD programming?

> This belongs on misc, so moving it there.
> My usual routine (and probably of a lot of other OpenBSD developers) is:

You forgot two steps:

> 1) Use it
> 2) Get annoyed by something (bug?)

Between steps 2 and 3, read the manual page to make sure your assumptions
about what it is supposed to do are correct.  Often, that will already
reveal they are not: goto 1.

> 3) Dive into /usr/src to see what it actually does
> 4a) Realize I'm wrong in my initial annoyance; goto 1)

After step 4a and before going back to step 1, close the gap in the
manual page and send the patch to tech@; after all, that you even
got to step 4a proves that something a user needs to know wasn't
adequately described in the manual.  Goto 5a.

> 4b) Realize you can't fix the bug and ask for help on bugs@; goto 1)
> 4c) Try to fix the bug and sent a patch to tech@
> 5a) Patch falls in between the cracks (no-one responds) and it's not
> that important to you; goto 1)
> 5b) Patch falls in between the cracks and it's important to you;
> send reminder and goto 1) in the meantime.
> 5c) Realize my interpretation was wrong based on feedback; goto 1)
> 5d) Realize my patch was wrong based on feedback; goto 4b)
> 5e) Patch gets committed; goto 1)
> If you want reading material find a function you don't understand and
> lookup the manpage. If you want to have a more adventurage approach:
> $ PAGE=$(ls /usr/share/man/man[23] | sort -R  | head -1); \
> man ${PAGE##*.} ${PAGE%.*}

That can be simplified:

  $ man -l $(ls /usr/share/man/man[23]/*.[23] | sort -R  | head -1)


Re: Confusing problem with CVS

2020-03-13 Thread Ingo Schwarze
Hi Chris,

Chris Bennett wrote on Fri, Mar 13, 2020 at 08:23:22PM -0400:

> Thanks, that was helpful.
> I did not think of using info cvs. I do use info at times,
> just not that often.

That is quite understandable.  With BSD systems in general, it is
both the normal case and also our goal that the man(1) pages should
contain the authoritative, complete, correct, concise documentation.
But the further you move away from OpenBSD to other operating systems
or into ports land, the more documentation gets scattered across
various non-compatible file formats.

But even in OpenBSD base, there are a few legacy components still
in active use where we don't really continue development and where
the authoritative documentation is not in manual page format, for

 - GNU as(1)
 - GNU cvs(1)
 - gdb(1)
 - GNU info(1) itself
 - and a few others

With LLVM and related tools replacing GCC and GNU binutils on many
platforms, the amount and the importance of info(1) documents is
slowly continuing to decline.


Re: Confusing problem with CVS

2020-03-13 Thread Ingo Schwarze
Hi Chris,

Chris Bennett wrote on Fri, Mar 13, 2020 at 04:47:09PM -0400:

> I am running -current.
> On one server, src was empty. So I did a cvs checkout.
> On another server, src had older files. So I did a cvs up.
> Afterwards, inttypes.h had one size on the checkout, another size on the
> updated src.
> I rm'ed the updated src and did a checkout. Now both files are the same
> size and date.
> What has happened here? I thought that cvs up was the correct procedure.
> cvs -qd$CVSROOT checkout -P src inside of /usr or
> cvs -qd$CVSROOT up -Pd inside of /usr/src.
> Updating only changed some of the file dates

That sounds as if you had sticky tags at least in parts of one of
the trees, but you provide no details, so there is no way to be
sure what exactly happened.
> and did not work correctly.

You provide no evidence whatsoever that there might be a bug,
and my guess is that it is unlikely you encountered one.

It is among the basic ideas of CVS that running "cvs up" across a
whole tree doesn't necessarily update all the subdirectories from
the same server, nor from the same repository, nor to the same
branch.  In addition, "cvs up" commands you ran in the past may
have banned some files from being updated at all in the future.  In
case it isn't obvious, cvs(1) is very different from git(1) in these
respects.  With CVS, you can configure individual subdirectories
and even individual files to behave in custom ways, which git(1)
is incapable of.

It all depends on what the files in the various directories with
the name "CVS" contained, for example the various files called "Root",
"Repository", "Entries", and "Tag".

Because there are so many different scenarios in which what you
describe is the expected behaviour, i can't provide better advice
than this: use the command "info cvs" to learn how cvs(1) is supposed
to work.

In particular, make sure you become familiar with the -A, -C, and -r
options of "cvs up", but i'm not saying that will be sufficient to
avoid all possible surprises.  Also use "/sticky" inside "info cvs"
to look for information about sticky tags; it is mentioned at many
different places.


Re: Wikidata:Property proposal

2020-03-05 Thread Ingo Schwarze

Christophe Poncy wrote on Thu, Mar 05, 2020 at 11:33:23PM +0100:

> There is two property proposals to review on Wikidata, one related to
> NetBSD and the other to OpenBSD.
> Please see:
> Any comments are very welcome! You can also edit the proposal if you
> see any mistake

Thanks for the heads-up, i added an entry to the Talk page.


Re: man to render pure text? (or a pipe in vi macros ?)

2020-03-03 Thread Ingo Schwarze
Hi Marc,

Marc Chantreux wrote on Tue, Mar 03, 2020 at 10:05:41AM +0100:
> Ingo Schwarze wrote:

>>   :map K yw:E /tmp/vi.keyword.$$p!!xargs man   
>> i get:
>>   Error detected while processing function
>>   line   30:
>>   E132: Function call depth is higher than 'maxfuncdepth'

> it's a bug in the :E command, i reported it there:
> thank you for spotting it.

Heh.  I'm a blind squirrel, and look at the nut i just found...

>> Also, the patch that would be required is very small and straightforward. 

> indeed. you made me like reading C code.

>> So, what do people think?  Should i test the patch below in more
>> depth and commit it?  Or do people consider this bloat?

> i'm very naive about performance things but: as you add a condition
> in a loop that is used while reading the input, it will be a little
> bit slower.
> which means penality for everyone to avoid using a very simple pipe on
> rare cases. so i finally think it's not worth ... col -b is an elegant
> solution.

I ran "mandoc /usr/share/man/man1/ksh.1" 100 times, 10 times.
Before the change:

0m07.65s real 0m05.68s user 0m01.52s system
0m07.62s real 0m05.92s user 0m01.47s system
0m07.64s real 0m05.97s user 0m01.49s system
0m07.62s real 0m05.90s user 0m01.42s system
0m07.68s real 0m06.13s user 0m01.51s system
0m07.65s real 0m06.01s user 0m01.46s system
0m07.66s real 0m05.89s user 0m01.50s system
0m07.60s real 0m05.89s user 0m01.54s system
0m07.73s real 0m06.00s user 0m01.38s system
0m07.68s real 0m05.70s user 0m01.47s system
   7.653 +- 0.037 seconds for 100 times ksh(1)
   76.53ms +- 0.37ms for formatting ksh(1)

After the change:

0m07.68s real 0m06.22s user 0m01.34s system
0m07.62s real 0m06.02s user 0m01.42s system
0m07.68s real 0m05.87s user 0m01.46s system
0m07.66s real 0m06.01s user 0m01.41s system
0m07.59s real 0m06.00s user 0m01.41s system
0m07.62s real 0m06.09s user 0m01.20s system
0m07.63s real 0m05.95s user 0m01.44s system
0m07.67s real 0m05.83s user 0m01.48s system
0m07.59s real 0m06.11s user 0m01.46s system
0m07.71s real 0m05.86s user 0m01.45s system
   7.645 +- 0.041 seconds for 100 times ksh(1)
   76.45ms +- 0.41ms for formatting ksh(1)

So the slowdown is

   -8 +- 55 microseconds for formatting ksh(1)

which is consistent with "no change" with a precision of
about 7 permille.

It would no doubt be possible to measure this with more precision,
but i think knowing that there is no measurable performance change
on a one-percent level is good enough.

Also, i'm not surprised that one more "if" per output character
isn't relevant compared to all the other stuff that needs to be
done in the parsers and formatters.

I still do performance testing before changing overall algorithmic
order, but mere "if"s are almost never relevant.  I even mostly
stopped worrying about malloc(3) inside loops; at least in mandoc,
i have rarely seen relevant effects of slowdown.

Premature optimization is evil.


Re: man to render pure text? (or a pipe in vi macros ?)

2020-03-02 Thread Ingo Schwarze
Hi Marc,

Marc Chantreux wrote on Mon, Mar 02, 2020 at 07:07:37PM +0100:
> On Mon, Mar 02, 2020 at 12:06:42PM -0500, Raul Miller wrote:

>> Alternatively, have you tried using any web searches on this topic?

> i have to admit i try to avoid the web for many reasons so i try to
> stick to manpages, FAQ, mailing list archives.

Absolutely.  Using web searches for software documentation is an
awkward and error-prone crutch that should be avoided for many
reasons.  For OpenBSD documentation, it is never needed.

If careful scrutiny of an OpenBSD manual page leaves the impression
that information may be missing from the page, asking on misc@ is
a good idea and often results in an improvement of the manual page.

Only for low-quality software, searching the web may occasionally
be needed.


Re: man to render pure text? (or a pipe in vi macros ?)

2020-03-02 Thread Ingo Schwarze
+++ main.c  2 Mar 2020 17:06:53 -
@@ -158,6 +158,7 @@ main(int argc, char *argv[])
/* Search options. */
memset(, 0, sizeof(conf));
+   conf.output.backspace = -1;
conf_file = NULL;
defpaths = auxpaths = NULL;
@@ -373,6 +374,9 @@ main(int argc, char *argv[])
return mandoc_msg_getrc();
+   if (conf.output.backspace == -1)
+   conf.output.backspace = 1;
/* Parse arguments. */
Index: manconf.h
RCS file: /cvs/src/usr.bin/mandoc/manconf.h,v
retrieving revision 1.7
diff -u -p -r1.7 manconf.h
--- manconf.h   22 Nov 2018 11:30:15 -  1.7
+++ manconf.h   2 Mar 2020 17:06:54 -
@@ -1,6 +1,6 @@
 /*     $OpenBSD: manconf.h,v 1.7 2018/11/22 11:30:15 schwarze Exp $ */
- * Copyright (c) 2011, 2015, 2017, 2018 Ingo Schwarze 
+ * Copyright (c) 2011,2015,2017,2018,2020 Ingo Schwarze 
  * Copyright (c) 2011 Kristaps Dzonsons 
  * Permission to use, copy, modify, and distribute this software for any
@@ -33,6 +33,7 @@ structmanoutput {
char *tag;
+   int   backspace;
int   fragment;
int   mdoc;
int   noval;
Index: mandoc.1
RCS file: /cvs/src/usr.bin/mandoc/mandoc.1,v
retrieving revision 1.166
diff -u -p -r1.166 mandoc.1
--- mandoc.115 Feb 2020 15:28:01 -  1.166
+++ mandoc.12 Mar 2020 17:06:55 -
@@ -284,6 +284,13 @@ The following
 .Fl O
 arguments are accepted:
 .Bl -tag -width Ds
+.It Cm format Ns = Ns Cm none
+No back-spaced encoding is used, neither for bold face and underlining
+nor for character overstrikes.  Only the last character of each
+overstrike group is printed.
+This has the same effect as piping the output through
+.Xr col 1
+.Fl bx .
 .It Cm indent Ns = Ns Ar indent
 The left margin for normal text is set to
 .Ar indent
Index: manpath.c
RCS file: /cvs/src/usr.bin/mandoc/manpath.c,v
retrieving revision 1.28
diff -u -p -r1.28 manpath.c
--- manpath.c   10 Feb 2020 14:42:03 -  1.28
+++ manpath.c   2 Mar 2020 17:06:57 -
@@ -1,6 +1,6 @@
 /* $OpenBSD: manpath.c,v 1.28 2020/02/10 14:42:03 schwarze Exp $ */
- * Copyright (c) 2011,2014,2015,2017-2019 Ingo Schwarze 
+ * Copyright (c) 2011,2014,2015,2017-2020 Ingo Schwarze 
  * Copyright (c) 2011 Kristaps Dzonsons 
  * Permission to use, copy, modify, and distribute this software for any
@@ -226,7 +226,7 @@ manconf_output(struct manoutput *conf, c
const char *const toks[] = {
"includes", "man", "paper", "style", "indent", "width",
-   "tag", "fragment", "mdoc", "noval", "toc"
+   "format", "tag", "fragment", "mdoc", "noval", "toc"
const size_t ntoks = sizeof(toks) / sizeof(toks[0]);
@@ -247,11 +247,11 @@ manconf_output(struct manoutput *conf, c
-   if (tok < 6 && *cp == '\0') {
+   if (tok < 7 && *cp == '\0') {
mandoc_msg(MANDOCERR_BADVAL_MISS, 0, 0, "-O %s=?", toks[tok]);
return -1;
-   if (tok > 6 && tok < ntoks && *cp != '\0') {
+   if (tok > 7 && tok < ntoks && *cp != '\0') {
mandoc_msg(MANDOCERR_BADVAL, 0, 0, "-O %s=%s", toks[tok], cp);
return -1;
@@ -308,22 +308,43 @@ manconf_output(struct manoutput *conf, c
"-O width=%s is %s", cp, errstr);
return -1;
case 6:
+   switch (conf->backspace) {
+   case 0:
+   oldval = mandoc_strdup("none");
+   break;
+   case 1:
+   oldval = mandoc_strdup("backspace");
+   break;
+   default:
+   if (strcmp(cp, "none") == 0) {
+   conf->backspace = 0;
+   return 0;
+   } else if (strcmp(cp, "backspace") == 0) {
+   conf->backspace = 1;
+   return 0;
+   }
+   mandoc_msg(MANDOCERR_BADVAL_BAD, 0, 0,
+   "-O format=%s", cp);
+   return -1;
+   }
+   break;
+   case 7:
if (conf->tag != NULL) {
oldval = mandoc_strdup(conf->tag);

Re: Web documentation available offline by default?

2020-03-01 Thread Ingo Schwarze
Hi Ottavio,

Ottavio Caruso wrote on Fri, Feb 28, 2020 at 11:27:30AM +:

> Warning: beginner here.

That's OK, as long as you don't feel offended when not every idea
is instantly acted on.  ;-)  (Actually, that applies to experienced
users as well - and even to developers.)

> What about having good old plain text obsd-faq.txt
>  mirrored in
> base system?

That would be inconvenient.  It helps the release(8) process that
the base system - - is a stand-alone
repository.  Reacharound to the www repository doesn't strike me
as desirable.  Remember that the release(8) process is also followed
for snapshot builds, which are done often on multiple architectures.
Keeping that process as simple as possible and requiring as few
dependencies as possible really helps development and avoids
annoying distractions for developers.

Besides, the FAQ only applies to -stable and not to -current, so
installing it on a -current system would be badly misleading.
And we certainly don't want the release(8) process to work differently
for -current and -stable: -current is where most of the testing for
-stable gets done, so it should better be as similar as possible or
we would be in for surprises at release time, or even worse, for
surprises after release.

> Or maybe it's there but I could't find it:
> oc@OpenBSD:~$ find /usr/share/ -iname *faq.txt*
> oc@OpenBSD:~$

No, it isn't there.  But you can easily find it elsewhere
and download it to any place where you need it.


Re: Web documentation available offline by default?

2020-02-27 Thread Ingo Schwarze
Hi Frank,

Frank Beuth wrote on Fri, Feb 28, 2020 at 04:22:27AM +:

> Is the web documentation (FAQ etc) included in the base system by 
> default anywhere,

No it isn't.

I offered some years ago to translate the FAQ from HTML to mdoc(7)
and to include it in /usr/share/man/faq/ such that it would become
available for both -current and -stable both online and offline
without additional maintenance effort just like any other documentation
and such that it would automatically be included in apropos(1)
searches, but the proposal was rejected because the developers who
actually maintain the content of the FAQ consider it easier to
maintain in HTML than in mdoc(7) format.

We don't want to lose the valued contributions of those developers
who actually spend all the work maintaining the FAQ or make their
work any harder than it is now.

> or do we have to pull it from CVS manually?

That would be one simple option, yes.


  1   2   3   4   5   6   7   8   9   >