Re: Support Update

[Ingo Schwarze]

Hello once more,

Ingo Schwarze wrote on Sat, Jan 06, 2024 at 03:16:49PM +0100:
> Kihaguru Gathura  wrote
> on Tue, Jan 02, 2024 at 03:53:21PM +0300:
 
>> 0
>> C Kenya
>> P
>> T Nairobi
>> Z P.O. Box 30164-00100
>> O IFINAX Ltd
>> I Kihaguru Njenga Gathura
>> A Bishops Road
>> M info@ifinax. net

> As far as i can see, this is the only line you want to change,
> but the new version of the line is malformed: it must not contain
> angle brackets.
> 
> It is not clear to me whether you want
> 
>   M i...@ifinax.net
> 
> or
> 
>   M i...@pqscript.com
> 
> or even something else?

Apart from the HTTP issues reported earlier, i see issues with your SMTP
configuration as well:

   $ date 
  Sat Jan  6 15:21:00 CET 2024
   $ host -t any pqscript.com 
  Host pqscript.com not found: 3(NXDOMAIN)

This is not good because a domain must have at least SOA and MX records
to be usable for SMTP.

   $ host -t soa ifinax.net 
  ifinax.net has SOA record ns1.safaricombusiness.co.ke. \
  EnterpriseISPSystems.Safaricom.co.ke. 2023121202 3600 1800 1209600 86400
   $ host -t mx ifinax.net ns1.safaricombusiness.co.ke
  Using domain server:
  Name: ns1.safaricombusiness.co.ke
  Address: 41.203.208.129#53
  Aliases: 

  ifinax.net mail is handled by 0 rat-03.safaricombusiness.co.ke.
  ifinax.net mail is handled by 0 rat-04.safaricombusiness.co.ke.
  ifinax.net mail is handled by 0 rat-01.safaricombusiness.co.ke.
  ifinax.net mail is handled by 0 rat-02.safaricombusiness.co.ke.

   $ telnet rat-03.safaricombusiness.co.ke smtp
  Trying 41.203.208.141...
  Connected to rat-03.safaricombusiness.co.ke.
  Escape character is '^]'.
  220 thk-tes-rat05.safaricombusiness.co.ke ESMTP
  MAIL From:
  250 sender  ok
  RCPT To:
  550 #5.1.0 Address rejected.
  QUIT
  221 thk-tes-rat05.safaricombusiness.co.ke
  Connection closed by foreign host.

The identical problem occurs when i relay the mail via the official
outgoing mailserver of the Karlsruhe Institute of Technology:

  Reporting-MTA: dns; smarthost.kit.edu
  Action: failed
  Final-Recipient: rfc822;i...@ifinax.net
  Status: 5.0.0
  Remote-MTA: dns; rat-02.safaricombusiness.co.ke
  Diagnostic-Code: smtp; 550 #5.1.0 Address rejected.

So please fix your mail server first, and then tell me which email
address you want listed after that.

Yours,
  Ingo

>> U
> 
> While we are sorting this out, can we please also add a working
> WWW URI?  I mean, a "Ltd" company almost certainly has a website
> nowadays, and listing that would be very helpful for users.
> 
> However, this does not look good:
> 
>$ date
>   Sat Jan  6 15:01:57 CET 2024
>$ printf "GET / HTTP/1.0\r\n\r\n" | nc ifinax.net http 
>   HTTP/1.0 302 Found
>   Connection: close
>   Content-Length: 486
>   Content-Type: text/html
>   Date: Sat, 06 Jan 2024 14:02:15 GMT
>   Location: https://ifinax.com/
>   Server: OpenBSD httpd
> 
>   
>   [ ... snip ... ]
> 
>$ printf "GET / HTTP/1.0\r\n\r\n" | nc -cvD ifinax.com https 
>   Connection to ifinax.com (41.90.23.242) 443 port [tcp/https] succeeded!
>   TLS handshake negotiated TLSv1.3/TLS_AES_256_GCM_SHA384 with host ifinax.com
>   Peer name: ifinax.com
>   Subject: /CN=ifinax.com
>   Issuer: /C=US/O=Let's Encrypt/CN=R3
>   Valid From: Fri Nov  3 08:43:56 2023
>   Valid Until: Thu Feb  1 08:43:55 2024
>   Cert Hash: 
> SHA256:aa6ea558a0d1e76067225762f3dbd8982cf5cbc73f1c66b9cc47111db05f65b0
>   OCSP URL: http://r3.o.lencr.org
>$ echo $?
>   0
> 
> It appears the TLS TCP connection to the https port works, but then
> the web server immediately closes the connection instead of waiting
> for HTTP requests.
> 
> Can you fix the server such that we can add
> 
>   U https://ifinax.com/
> 
> or should a different URI be listed?
> 
> Until these issues are worked out, i refrain from touching the existing
> entry for Kihaguru Njenga Gathura, for now.
> 
>> B +254 7 0697 0697
>> X
>> N OpenBSD consulting. Speciality in web applications
>> development with OpenBSD-httpd web server, PostgreSQL DBMS, FastCGI
>> protocol and C programming language.

Re: Support Update

[Ingo Schwarze]

Hello,

Kihaguru Gathura  wrote
on Tue, Jan 02, 2024 at 03:53:21PM +0300:

> 0
> C Kenya
> P
> T Nairobi
> Z P.O. Box 30164-00100
> O IFINAX Ltd
> I Kihaguru Njenga Gathura
> A Bishops Road
> M info@ifinax. net

As far as i can see, this is the only line you want to change,
but the new version of the line is malformed: it must not contain
angle brackets.

It is not clear to me whether you want

  M i...@ifinax.net

or

  M i...@pqscript.com

or even something else?

> U

While we are sorting this out, can we please also add a working
WWW URI?  I mean, a "Ltd" company almost certainly has a website
nowadays, and listing that would be very helpful for users.

However, this does not look good:

   $ date
  Sat Jan  6 15:01:57 CET 2024
   $ printf "GET / HTTP/1.0\r\n\r\n" | nc ifinax.net http 
  HTTP/1.0 302 Found
  Connection: close
  Content-Length: 486
  Content-Type: text/html
  Date: Sat, 06 Jan 2024 14:02:15 GMT
  Location: https://ifinax.com/
  Server: OpenBSD httpd

  
  [ ... snip ... ]

   $ printf "GET / HTTP/1.0\r\n\r\n" | nc -cvD ifinax.com https 
  Connection to ifinax.com (41.90.23.242) 443 port [tcp/https] succeeded!
  TLS handshake negotiated TLSv1.3/TLS_AES_256_GCM_SHA384 with host ifinax.com
  Peer name: ifinax.com
  Subject: /CN=ifinax.com
  Issuer: /C=US/O=Let's Encrypt/CN=R3
  Valid From: Fri Nov  3 08:43:56 2023
  Valid Until: Thu Feb  1 08:43:55 2024
  Cert Hash: 
SHA256:aa6ea558a0d1e76067225762f3dbd8982cf5cbc73f1c66b9cc47111db05f65b0
  OCSP URL: http://r3.o.lencr.org
   $ echo $?
  0

It appears the TLS TCP connection to the https port works, but then
the web server immediately closes the connection instead of waiting
for HTTP requests.

Can you fix the server such that we can add

  U https://ifinax.com/

or should a different URI be listed?

Until these issues are worked out, i refrain from touching the existing
entry for Kihaguru Njenga Gathura, for now.

Yours,
  Ingo

> B +254 7 0697 0697
> X
> N OpenBSD consulting. Speciality in web applications
> development with OpenBSD-httpd web server, PostgreSQL DBMS, FastCGI
> protocol and C programming language.

Re: self-hosted man.openbsd.org script?

[Ingo Schwarze]

Hi Mihai,

Mihai Popescu wrote on Thu, Dec 28, 2023 at 01:32:34AM +0200:

> [ removed elaborate instruction about going html from almost txt with
> man pages ]
> 
> All this to jump in html boat? Or I got it wrong?
> Are old man pages deprecated?

Manual pages are not restricted to a specific output format.

THE traditional output format, as far as such a thing exists, is
black markings on dead trees.  That output format later evolved into
PostScript format and still later into PDF format.  Let's call all
these output modes "typeset output".

Another very old output format is video terminal (CRT) output.
That's still used a lot, though mostly via virtual terminals nowadays
rather than on CRTs.  But all that is clearly younger than typeset
output mode.

It has already been explained why nowdays (meaning: during the
last three decades) it has become convenient to also be able to
access information remotely via the WWW.  The simplest format to
facilitate that has always been HTML.

Even more recently (as in: during the last decade) source code
management platforms have become popular that require documentation
in Markdown format.  So that's just another output mode for manual
pages, see for example

  https://github.com/Tairokiya/rfind
  (even though using manual page format isn't widespread on that
   particular platform yet, and this example is of poor quality
   in several respects)

or

  https://codeberg.org/fobser/gelatod
  (even though the software used by Codeberg, Forgejo, is currently
   haunted by a bug that prevents correct rendering of the
   standard-conforming Markdown (specifically, CommonMark) code
   generated from manual pages, as you can see - but that bug is
   already fixed and will be gone from the next Forgejo release)


So, if the output format is *not* what defines manual pages, then is it
that defines them?

 1. The idea of having one self-contained document ("manual page")
for each interface (specifically, CLI command in sections 1 and 8,
system call in section 2, API function in section 3, kernel driver
in section 4, configuration file in section 5, domain specific
language in section 7, kernel function in section 9)

 2. Each of these documents being complete but concise, i.e. not
mixing in explanations of required prior knowledge about the
foundations the interface is built on, nor containing tutorial-
style instructions

 3. A common structure consisting of
 - a one-line description (name section)
 - an informal (i.e. non-BNF), human readable syntax display 
   (synopsis section)
 - a description of the arguments and behaviour (description section)
 - various standardized auxiliary sections like "return values",
   "environment", "files", "exit status", "errors", "see also",
   "standards" and so on, to help quickly locate information
   that often needs to be looked up

 4. Universal tygographic conventions helping readability of the
page for anyone familiar with other manual pages, no matter
who wrote the particular page currently being looked at

Using HTML output format for reading manual pages allows taking full
advantage of these concepts just like any other output format does.
So there is really no need to bash HTML as a manual page output
format.  Also remeber that HTML output format may be particularly
convenient for people having specific accessibility requirements,
for example blind people.


Maybe what you had in mind is that some software authors abuse HTML as
an *input* format for documentation, that they write documentation for
their software directly in HTML format (instead of writing manual pages,
which can then trivially be convented to HTML if desired, and additionally
to many other formats).  *Maintaining* documentation in HTML format is
indeed a very bad idea.  That usually results in documentation that is
disorganized, sprawling rather than concise, hinders locating information,
is riddled with idiosyncratic formatting choices, and next to impossible
to convert to any other format.

Yours,
  Ingo

Re: self-hosted man.openbsd.org script?

[Ingo Schwarze]

Hi Paul,

Paul Pace wrote on Sun, Dec 24, 2023 at 05:25:55AM -0800:

> I have this vague memory of reading someone who posted a script, IIRC, 
> to convert the system's man pages to HTML, or similar, into somewhere 
> under /var/www and the pages worked just like the highly useful 
> man.openbsd.org, and not like the plain text pages that everyone always 
> posts to their websites.
> 
> Does someone happen to know where that is?

I don't know about any such "script" and believe using a script for it
would be a bad idea - a dirty hack at best.

Converting a whole tree of manual pages to a different format
sounds like the job for the tradition catman(8) utility program
that Christoph Robitschko first implemented in 1993.  NetBSD
and FreeBSD contain implementations by various other authors.

OpenBSD does not contain the catman(8) utility because it is rarely
needed by ordinary users and we tend to only include code in the base
system that is useful for many people.

However, the portable mandoc distribution does contain a version
that i wrote together with Michael Stapelberg (of the Debian project)
in 2017:

  https://mandoc.bsd.lv/
  https://mandoc.bsd.lv/man/catman.8.html

For your purpose, you may want to replace to line

options.fragment = 1;

in mandocd.c by something like

{ char style[] = "/usr/share/misc/mandoc.css";
options.style = style; }

before compiling such that you get complete HTML code including
, , , and  elements.

Be careful to not clobber the system mandoc(1) installation by blindly
running "make install".  Instead, just manually installing the
binary "mandocd" anywhere in the $PATH is enough.  Installing
the "catman" binary in not necessary but won't hurt either.

Also note that viewing the results with a monster browser like
firefox or chrome may require some tweaking with respect to unveil(2),
see the respective files below /usr/local/share/doc/pkg-readmes/.

I freely admit all this is not particularly user-friendly but more
geared towards the needs of server admins.  For example, the
server manpages.debian.org is essentially using something similar
to this method.  For them, it's critical that this implementation
of catman(8) is much more efficient than the NetBSD and FreeBSD
implementations: it saves lots of time because it does *not* fork
and exec a new parser/formatter process for every manual page
but instead merely reinitialized and resuses the same parser and
formatter process over and over again, which is *much* faster.
With the huge amount of manual pages Debian has to format very
often, their server would not be able to keep up without that
optimization.

Yours,
  Ingo

Re: Font size and character encoding.

[Ingo Schwarze]

Hi Michael,

Michael Hekeler wrote on Tue, Nov 21, 2023 at 08:18:41AM +0100:
> Somebody asked:

>> How to increase font size in console?
>> How to set non-UTF character encoding for tty session on OpenBSD 7.4?

> apropos font -a cons

Heh.  When kristaps@ introduced complex search expressions into
apropos(1) twelve years ago, it seemed neat, and i use it regularly,
yet i see evidence that other people use it relatively rarely.  Nice too
see such evidence occasionally; it's certainly helpful in particular to
keep noise down when searching, and your reply was more instructive than
just posting the result...  :-)

Yours,
  Ingo

Re: Claws Mail and new call for eu locale

[Ingo Schwarze]

Hi,

Daniele B. wrote on Wed, Nov 15, 2023 at 06:17:21PM +0100:

> I just came accross the last little problem regarding the locale of my
> system: in Claws Mail the date in message pane is displayed in %x
> format (result=mm/dd/year) to adapt to the current locale. 
> 
> I started to change locale to my system in all the possible ways
> without luck. If I set it_IT I got yes the right language but the same
> result for the date (in the message pane).
> 
> In the end going in Claws Mail display settings the option allows me
> to specify the parameters for the date format. "man strftime" I found
> something useful (an year/mm/dd), although not exactly a simple
> dd/mm/year format yet.
> 
> Dispite these details and knowing that en_US.UTF-8 with "C" locale
> profile is reccomnded to us, I take the time to gently ask about
> the support for any european date locale profile and any feedback
> about any eventual work-in-progress?

Even if someone would provide libc patches to provide LC_* support
other than LC_CTYPE, i would veto them, even if they were correct and
very simple (they cannot be simple, though).  Reliable and predictable
output is much more important than such quibbles.  The C library is
totally the wrong place for any such functionality.

Yours,
  Ingo

Re: Typo in faq4.html

[Ingo Schwarze]

Hi Robin,

robin@tilde.institute wrote on Sat, Nov 04, 2023 at 01:18:47PM +:

> In faq4.html, the link to OpenBSD's firmware directory is not working.
> Indeed it is http://firmware.openbsd.org instead of 
> http://firmware.openbsd.org/firmware/ as shown in fw_update(8)'s 
> manpage.

Thank you for reporting the dead link and for mentioning that the
manual page provides a working link.

> Here is a proposed diff.

Committed with minimal tweaks.

It is online now at:

  https://www.openbsd.org/faq/faq4.html#WifiOnly

Yours,
  Ingo


> Index: faq4.html
> ===
> RCS file: /cvs/www/faq/faq4.html,v
> retrieving revision 1.555
> diff -u -p -r1.555 faq4.html
> --- faq4.html 16 Oct 2023 12:52:20 -  1.555
> +++ faq4.html 4 Nov 2023 13:02:43 -
> @@ -512,7 +512,7 @@ a bootable install image with the necess
>  If you don't have an existing OpenBSD system with internet access, use
>  another computer to download the appropriate file from
>  
> -http://firmware.openbsd.org;>firmware.openbsd.org and put
> + href="http://firmware.openbsd.org/firmware/;>firmware.openbsd.org/firmware/
>  and put
>  it on a USB drive that's readable by OpenBSD.
>  Then, on the OpenBSD machine,
>  https://man.openbsd.org/mount;>mount(8) the drive and use

Re: Chinese Support

[Ingo Schwarze]

Hi,

ykla wrote on Sun, Oct 29, 2023 at 08:47:08PM +0800:

> I've tested Chinese input methods and interfaces in Chinese
> without any problems, and I've written some Chinese tutorials
> about OpenBSD. If you're interested, check out book.bsdcn.org.

Interesting - even though i must admit i cannot read that because
i understand neither Chinese characters nor Chinese language(s).

Be sure to watch the ports in questions for issues in the future,
too, and maybe, if you have time, watch out when such ports can be
updated or improved.  It appears there is a shortage of MAINTAINERs
for ports in the /usr/ports/chinese/ category: as far as i can see
right now, only one developer is listed as a MAINTAINER in there,
and only for two of these ports, so people who are able to help
with porting work there are certainly welcome.

Another region that may be worth watching from the corner of the eye
is CJK UTF-8 character support in the base system.  In particular,
that includes Perl because we build the CJK character support in our
C library from the version of the Unicode character database that
is distributed with Perl.  The most glaring bugs with CJK support
are likely to be found quickly because there are several developers
who actively use the Japanese language.  But if something subtle
goes wrong that mostly impacts Chinese and/or Korean, there might
be a higher risk of it falling through the cracks undetected.

Then there is documentation.  While the OpenBSD project does
not have the massive resources that would be required to maintain
translated documentation, the *tools*, for example mandoc(1), aim to
be usable with non-English documentation.  If i understand correctly,
translating manual pages to Japanese is not done very often and
often not considered as very important even by native speakers of the
Japanese language, but in those cases where people want to do it, the
tools should not hinder it.  The same might possibly apply to Chinese,
and there might be additional aspects specific to Chinese that i'm
unaware of.  So bug reports related to writing or maintaining Chinese
documentation are certainly welcome, too.

Yours,
  Ingo

Re: Default rdomain for CLI commands

[Ingo Schwarze]

Hi Claudio,

if you received no feedback, i think you should just go ahead and commit
your manual page diff, it seems like an improvement based on what is
discussed in this thread (i did not test, nor inspect the code).

There may be more potential defects in the manual page login.conf(5).
For example, it doesn't appear to say what it means when the "Default"
column is empty in a given line of the table.  Also, section 5
file format manual pages should state as clearly as possible which
programs (section 1 and 8) and/or functions (section 3) use the file
format, and login.conf(5) feels somewhat fuzzy to me in that respect.
But such potential more fundamental issues should not stand in the
way of fixing a detail that is outright misleading.

Yours,
  Ingo


On 24 Oct 2023, at 18:51, Claudio Jeker  wrote:

> Because I think login.conf(5) is wrong. The default rtable is not 0. If
> rtable is not set the current rtable is not modified by login_cap(3).

Index: login.conf.5
===
RCS file: /cvs/src/share/man/man5/login.conf.5,v
retrieving revision 1.70
diff -u -p -r1.70 login.conf.5
--- login.conf.531 Mar 2022 17:27:23 -1.70
+++ login.conf.524 Oct 2023 08:41:21 -
@@ -284,7 +284,7 @@ Initial priority (nice) level.
 Require home directory to login.
 .\"
 .Pp
-.It rtable Ta number Ta Dv 0 Ta
+.It rtable Ta number Ta "" Ta
 Rtable to be set for the class.
 .\"
 .Pp

Re: Chinese Support

[Ingo Schwarze]

Hi,

Lucretia wrote on Sun, Oct 29, 2023 at 08:48:59AM +:

> I remember reading somewhere in the project statement that OpenBSD
> aims to support as many platforms as possible.

https://www.openbsd.org/goals.html

Somewhere in the middle of the list of goals.

The priority of that goal is lower than in NetBSD, and the "feasible"
is interpreted in a stricter way.  Feasible requires that at least
some developers have access to fully working hardware, that regularly
building *the whole system* on that hardware does not cause too
much pain (cross-compiling is occasionally used for bringing a new
platform up, but never for keeping an old platform alive), and it
happened several times in the past that support for an old platform
was abandoned because it got in the way of more modern development:
security, maintainability, simplicity, and being a good general-purpose
development platform matters more than running on each and every
obscure hardware.


> But it seems there is anti-Chinese sentiment concerning hardware.

That sounds like an unfounded rumour to me, see for example:

  https://www.openbsd.org/loongson.html
  "The latest supported OpenBSD/loongson release is OpenBSD 7.4."

There is also this on goals.html:

  Be as politics-free as possible; solutions should be decided on
  the basis of technical merit. 

That doesn't mean every decision in OpenBSD must always be 100%
free of any political component; such a goal would seem strenuous
and artificial and probable not even be possible to reach.  On top
of that, every individual developer is of course free to express
their political opinions, and such opinions should not be construed
as "an opinion of the project."

Note that "we should support more Chinese hardware" would look
like a non-technical, purely politicial goal that would seem
inappropriate to me in view of goals.html.

If there is hardware that a developer wants to work on, i don't see
why it should matter whether it was produced in the PR of China,
in Taiwan, in the U.S., or in Dronning Maud land.


> Are there any Chinese developers actively working on the project?

That is a completely irrelevant question.  For many developers, i know
where they live (at least approximately, unless they moved recently,
which caused me to perform an incomplete website update just last
week).  But i don't care what the nationality of a developer is, and
you probably know that making assumptions about nationality based on
where somebody lives or what their name is is a bad idea.

Living in the (People's Republic of) China might cause some practical
problems for developers that developers living in some other countries
don't need to worry about, but so what.  There was a point in the past
where developers living in the United States of America faced political
restrictions regarding which work on OpenBSD they could do at home,
and some travelled abroad for doing some particular kinds of work.

Yours,
  Ingo

Re: Donations

[Ingo Schwarze]

Hi,

Theo de Raadt wrote on Thu, Oct 26, 2023 at 12:14:43PM -0600:
> Joel Carnat  wrote:
>> Le 26 oct. 2023 à 16:38, Ingo Schwarze  a écrit :

>>> The advice is extremely simple:
>>> 
>>> If you can, donate directly to the OpenBSD project because that means
>>> 1. the donation can be used for any purpose, including all purposes
>>>that can be funded by the foundation and some that can't
>>> 2. it causes less overhead, less paperwork, less bookkeeping effort,
>>>hence fewer distractions of developers from actual development
>>> 
>>> Use the Foundation only if *you* have a specific reason why your
>>> specific donation can only be made through the Foundation and not
>>> directly.  If you don't know, then it seems to me you have no specific
>>> reason, so donating directly is better.

>> Maybe it should be written this way on the donations.html page
>> of the web site. Having the reference to "PayPal recurring" for the
>> Fondation coming first made me assume this was the preferred way
>> to donate.
>> 
>> But if I understand you properly, using the other PayPal links
>> should rather be used, right?

> Sorry Ingo, that's incorrect.

Oops, sorry for sending outdated and/or misleading information.

In that case, a change to donations.html probably isn't needed.

Yours,
  Ingo

> In my view it is better to donate via the OpenBSD Foundation, and then
> use their not-for-profit procedures.
> 
> The direct donations can be considered 'fast cash'.  I'm thrilled there
> is a bit of fast cash available so I can immediately solve some problems
> with urgency -- without reaching out to the OpenBSD Foundation and
> waiting for their approval process.  But for most things (hackathons,
> hardware, other major project costs) I believe the transparency they
> supply is a good thing.

Re: Donations

[Ingo Schwarze]

Hi Maria,

Maria Morisot wrote on Thu, Oct 26, 2023 at 03:10:46PM +0600:

> I see there are two types of donation receivers, the project and the
> foundation.  What is the difference between how the money is spent
> between the two.

How the money is *spent* is not not the main difference between
the two.  Well, strictly speaking, since the Foundation needs to
have Bylaws and yada yada yada, there are a few formal restriction
on how Foundation money can be spent, but as for any foundation,
this Foundation is designed in such a way that such minor formal
restrictions do not cause any significant trouble in practice.

So people who want to donate need not worry about the differences
in *spending*.  From a practical point of view, the difference between
the two is entirely about needs of the *donator*.

> The foundation from what it looks like goes to paying the bills
> for the infrastructure, how about donations to the project.
> 
> I've already many times over stated my willingness to donate time;

You cannot really donate time to OpenBSD, in the way you would sell
your working time to an employer, giving the time to the employer
and the employer then telling you what to do.  Managing employees
requires the *employer* to do some work of their own, for example
directing the employees what to do and making sure they don't
suffer harm while working.  The OpenBSD project is not prepared
to do any such employer's work.

What you can do is donate *products* of your work, like you would sell
products while working in a self-employed manner, except that you have
neither customers nor revenue.  The most common and most welcome way of
doing that is by submitting patches.  There is a fine legal distinction
related to that: with OpenBSD, in contrast to some other free software
projects, you do not actually donate your submitted patches to OpenBSD
like you would, for example, have to donate them to the FSF when
contributing code to the GNU project, by transfering your (economic
part of your) Copyright to the FSF.  Instead, you merely publish your
patches under a free license, retaining all your Copyright yourself,
and OpenBSD is then free to include and redistribute your work.
There is also a merely terminological distinction: we do not call
submissions of patches "donations."

> I am also an artist and a poet.  Perhaps I could work on an OpenBSD
> related poetry chapbook.  I remember you used to have songs for
> every release.

Commission of art and poetry for the OpenBSD project works by
invitation only, and i don't know how or on which grounds such
invitations are decided.  The process certainly isn't public.
It never mattered to me because i'm neither an artist nor a poet.  :)

> I want to donate money but I just want to see where it goes
> so I can tailor my choice of which.

The advice is extremely simple:

If you can, donate directly to the OpenBSD project because that means
 1. the donation can be used for any purpose, including all purposes
that can be funded by the foundation and some that can't
 2. it causes less overhead, less paperwork, less bookkeeping effort,
hence fewer distractions of developers from actual development

Use the Foundation only if *you* have a specific reason why your
specific donation can only be made through the Foundation and not
directly.  If you don't know, then it seems to me you have no specific
reason, so donating directly is better.

Yours,
  Ingo

Re: my first patch

[Ingo Schwarze]

Hi Maria,

Maria Morisot wrote on Wed, Oct 25, 2023 at 09:44:17AM +0600:

> because the compiler said to.

Never trust a linter blindly.

A linter is a tool to automate searching for some kinds of issues.
For every candidate, you still need to engage your brains to figure out

 - whether it's an actual problem or a false positive;
   all linters have a non-zero rate of false positives,
   of varying frequencies
 - what the importance and priority is
 - what the best fix is, in general and in particular;
   even if the linter presents some specific advice, that may still
   be wrong in the particular case, or even in general
 - what the risks and costs of attempting a fix are

> more than happy to be a code janitor.

We don't want code janitors here.  Having those is dangerous.
It too easily happens that a change is considered "trivial janitorial
work", the janitor is too inexperienced to recognize that it is
actually wrong or even dangerous, the reviewer is sloppy and spends
little time on it because it is just "trivial janitorial work",
and on top of that, also because the volume of such seemingly
simple changes becomes too massive for proper review, and too tiring.
And boom, things go sideways, and nobody notices.

Every change, large or small, complicated or seemingly simple, needs
to be developed or properly reviewed by at least one developer fully
understanding the matter.  Large, mechanical diffs that are sometimes
typical for janitorial work elsewhere are only accepted round here
from developers who are known for their particular experience and
diligence.  In that sense, janitorial work must clear a *higher*
bar here than ordinary commits.

> I just need someone to steer me in a direction.

Finding something that interests you, that you can already improve in
some way right now, or that you want to learn about is an essential
part of the job.  No one else can do that for you.

I have sometimes tried to suggest specific tasks to people who asked
for work.  But it's a bad idea after all because unless i know
someone very well, it's hard to judge what they want and what they
can do.  The end result often is that i spend more time trying to
coach them than it would have taken to complete the task myself -
which i didn't have time for in the first place because there are
just way too many open tasks.  And the success rate of coaching
people is *massively* lower than the success rate of doing own work.

A good beginner typically has a success rate of maybe 20-30% of the
patches they send in to finally get committed after some iterations of
taking advice and sending improvements.  Beginners with phantastically
high success rates on the order of 50-70% occasionally pop up, but they
are rare.  The majority of people one tries to coach give up before
producing anything good enough for commit.
For comparison, for doing random work across the tree, developers
who are no longer beginners typically have success rates of about
50-70%; within their specialist domain, if any, typically aound 90-98%.
Consequently, the success rates for coaching are typically by roughly a
factor of ten lower than for own work, and often require more working
time per successful commit on top of that.  All these numbers are
personal estimates from anecdotal observation, i did not attempt
empirical reaseach into these matters.

> I'll keep plugging away at my own fancy

Not such a bad idea actually.

If you are energetic and curious, it's hard to believe you aren't
already aware of at least some quirks that irk you.  If you watch
the mailing lists, you will see plenty of potential problems that
others report.  Even if you judge many of them too hard for your
current knowledge and experience level, if you are intelligent,
you are likely able to determine root causes and develop fixes or
improvements for some others.

In any case, don't be pessimistic.  Having time and motivation at your
disposal is not a bad starting point for learning and for doing work
that interests you.  Being aware of personal weaknesses - anybody
has some, so generally nobody ought to regard them as roadblocks -
and using your personal strengths to your profit and contentment
is also a good idea.

Good luck and have fun,
  Ingo

Re: support new

[Ingo Schwarze]

Hi Wesley,

Wesley MOUEDINE ASSABY wrote on Tue, Oct 24, 2023 at 02:06:47PM +0400:

> 0
> C France
> P REUNION
> T Sainte Clotilde
> Z 97490
> O Consultant
> I Wesley Mouedine Assaby
> M wes...@mouedine.net  
> U https://www.mouedine.net
> N OpenBSD consulting, services like mailserver, web hosting, firewall and
> vpn.

Committed with s/vpn/VPN/, the spelling familiar from OpenBSD manual
pages.  I removed all information from your old entry that you no longer
included in your new entry.

The new entry is now online here, please check:

  https://www.openbsd.org/support.html#France

Yours,
  Ingo

Re: job request

[Ingo Schwarze]

Hi,

Magenta Octopus wrote on Thu, Oct 19, 2023 at 04:57:11PM +:

> Someone give me a job because I like your project.

Round here, the following are considered critical skills:

1. Being able to decide yourself what interests you.
2. Finding tasks that are worth doing.
3. Judging yourself whether your skills are sufficient
   to attempt working on any particular task you discover.
4. Reading code, listening to advice, and learning on the job.

To help with item 2, watching the OpenBSD mailing lists makes sense
because potential issues are often mentioned there.  Using the system
yourself also makes sense because you might discover issues that way.

To save management overhead, OpenBSD does not maintain a global
bugtracker.  TODO lists only exists for a few sub-projects, for
example

  https://portroach.openbsd.org/
  https://cvsweb.bsd.lv/mandoc/TODO

and there may be a few more.  Be aware that picking entries from
any TODO list makes it even more important to get the items 2 and 3
above right.

Starting with small bugfixes in code and/or documentation is usually
a good idea.  Java ports also exist for OpenBSD, but unless i'm quite
mistaken, those ports are rather complicated beasts; i certainly
don't know anything about them.

Good luck and have fun,
  Ingo

Re: Understanding -current as 7.4 is released

[Ingo Schwarze]

Hi Ronald,

Ronald Dahlgren wrote on Thu, Oct 05, 2023 at 12:45:56PM -0400:

> I’ve been running -current for several months now. Recently I started
> using “-D snap” when updating packages with pkg_add.

If you install a snapshot right now, what you actually get is
extremely close to what will be released as 7.4-release, though
there is no guarantee that it will be identical.  A small number
of bugs may still get fixed before release, if they are important
enough to justify adding additional work to the release process.

Also be aware that no security fixes will be released for 7.4-stable
before 7.4-release is officially released.  That means if you
run 7.4-release before it is officially released, you need to pay
attention to any security issues that might affect you - but that's
just the same that always applies when running -current.

> I ask the list to help me understand what, if anything, I need to
> do with my machines that run snapshots when 7.4 is released.

If you want to continue running -current, then you can run

  # sysupgrade -s

once post-release snapshots become available, or equivalently
manually upgrade to such a snaphot.

> Will I need to perform the upgrade procedures differently?

Except for potentially needing the -s flag as shown above above, no.
That flag may be needed because probably, your machines currently think
they are running 7.4-release, so sysupgrade(8) without arguments will
wait for 7.5 to appear.

> Is the release just a blessed snapshot and everything will continue
> to work as-is?

Mostly, yes.  It receives more testing than ordinary snapshots
and we are extra careful to avoid breaking stuff right before it.

The command "sysctl -n kern.version" tells you what a machine
is currently running:

OpenBSD X.Y-beta   = ongoing development *before* X.Y
OpenBSD X.Y with no suffix = release
OpenBSD X.Y-stable = stable branch based on the X.Y release
OpenBSD X.Y-current= ongoing development *after* X.Y

Yours,
  Ingo

Re: Registration

[Ingo Schwarze]

Hi Matti,

Matti Viljamaa wrote on Thu, Oct 05, 2023 at 03:05:37PM +0300:

> I mailed the MARC admins though.

I would like to kindly ask you to not cause extra work for people
who are providing a free public service.

> That is extremely bad design, because it's
> in essence a data mining resource for ad bots.

No.  In essence, that's a service that has been highly useful for
many *BSD projects and many other free software projects for a
very long time.

Yours,
  Ingo

Re: Registration

[Ingo Schwarze]

Hi Matti,

Matti Viljamaa wrote on Thu, Oct 05, 2023 at 02:46:54PM +0300:

> I got an answer to the query though in another mail.

Ah, OK.

> However, now I am concerned that I didn't want my email visible there.
> How can I delete that message?

You cannot.  When you post information to a public mailing list,
that information typically remains publicly visible for an indefinite
time.  That applies to most public mailing lists and is not specific
to OpenBSD.

Yours,
  Ingo

Re: Registration

[Ingo Schwarze]

Hi Matti,

Matti Viljamaa wrote on Thu, Oct 05, 2023 at 10:26:57AM +0300:

> I think I sent an user group registration request some time ago.
> I have not heard anything since.

The following search makes it seem likely that maybe you only intended
to send some information but actually didn't:

  https://marc.info/?a=16964913341=1

Perhaps resend your information to this list now?

Yours,
  Ingo

Re: Asked ChatGPT 4 about contributing to OpenBSD, this was its reply

[Ingo Schwarze]

Christoff Humphries wrote on Wed, Sep 27, 2023 at 01:21:42PM +:

> Asked ChatGPT 4 about contributing to OpenBSD, this was its reply

That's both totally pointless and completely off topic here.

Gimme a break, ChatGPT is a fucking language model, so it aims for
very little except grammatical correctness of its responses.

As expected, parts of the reply are pilfered from official,
authoritative resources, parts are common sense truisms of
varying relevance, and parts are totally misleading rubbish
that may all the same sound convincing to the ignorant.

Without prior knowledge, you have no idea which is which.
With prior knowledge, you have no need for any of it.

Re: groups new

[Ingo Schwarze]

Hi Matti,

Matti wrote on Sun, Sep 17, 2023 at 04:14:55PM +0100:

> 0
> C Finland
> P Uusimaa
> T Helsinki
> F None
> O Finnish OpenBSD Users Group
> I None
> M membership.f...@gmail.com
> U None
> N *BSD

so far, i failed to find any evidence that such a group actually exists.
Can anybody provide pointers to such evidence?

Thanks,
  Ingo

Re: undocumented command switches -OR- fix documentation fully

[Ingo Schwarze]

I'm aware that i'm replying to an obvious troll.
Just clarifying what's going on here for bystanders
who might feel confused.

> CVSROOT:/cvs
> Module name:src
> Changes by: mill...@cvs.openbsd.org 2023/09/20 10:57:12
> 
> Modified files:
> usr.bin/awk: main.c
> 
> Log message:
> Support --version option like upstream awk but don't document it.
> 
> Upstream awk has supported --version for a long time but does not
> support -V like our awk does.  Both options are supported by gawk.

This is perfectly in line with OpenBSD project goals.

Usually, we do not support long options at all because their
very existence violates POSIX and because, if a programs needs
more options than there are letters in the alphabet, that usually
means the program was seriously misdesigned.

In some cases, some long options that are synonymous with short
options are so widely used that supporting them *for compatibility
purposes only* makes the life easier for some people, for example
for our porting team.  In those cases, supporting them without
cluttering up the documentation is a perfectly sane approach, in
particular when the option is as useless as -V in the first place.
Note that most OpenBSD programs, for good reasons, do not provide
an option to print any version number in the first place.

In some rare cases, practical considerations make it seem worthwhile
to make an exception and provide a long option - usually popularized by
GNU in open defiance of POSIX - that does not have a short equivalent.
In such cases, we do usually document the long option.  But that's not
the case here.

None of these are hard rules, common sense and good judgement is
always needed, but i certainly agree with what Todd did in this case.

So everybody, please refrain from insulting Todd who is just doing
some good work here, for free, and for everybody's benefit.

Now, let's please stop this thread and discuss something relevant.

Yours,
  Ingo

Re: Does openBSD come with a web browser?

[Ingo Schwarze]

Hi,

David wrote on Wed, Sep 13, 2023 at 07:23:18AM +1000:
> On Mon, 2023-09-11 at 23:21 -0700, Eric Demer wrote:

>> whether there's one that comes _already_ installed.

All the software that is part of the OpenBSD base system is
documented on the site https://man.openbsd.org/ .

Consequently, given that

  https://man.openbsd.org/?query=browser=1

redirects to

  https://man.openbsd.org/man1/viewres.1  "graphical class browser for Xt"

you can quite safely conclude from that authoritative source that the
current OpenBSD base system does not include a web browser.

[Note to self: i have to make the URI syntax of that site more
 user-friendly, maybe something like
   https://man.openbsd.org/-k/browser
 Sigh, so much interesting work to do all over the place.]

By the way, OpenBSD is arguably the system that requires the least
amount of web searching.  It is almost always faster to look only at
 1. the manual pages
 2. the FAQ, https://www.openbsd.org/faq/
 3. and /usr/local/share/doc/pkg-readmes/

with the extra benefit of getting authoritative, and only
authoritative, information.

> $ grep _flags /etc/rc.conf | cut -d '_' -f 1

Not very good advice, that command only produces a list of some
daemon programs that come with the base system, but a web browser
is typically not a daemon, however devilish it may look.

Notably, four of the base system programs that i occasionally use
for browsing the web do not show up in that list:

  https://man.openbsd.org/ftp.1
  https://man.openbsd.org/telnet.1
  https://man.openbsd.org/nc.1
  https://man.openbsd.org/openssl.1

> There will always be `Terms' involved with any level of social
> interaction.

Maybe, even though i rarely think in terms of "terms" when interacting
with my friends.  The only - admittedly rather strained - idea i manage
to come up with for bringing a discussion of "terms" back on topic is
pointing out how infrequently OpenBSD terms of use change:

  https://cvsweb.openbsd.org/src/share/misc/license.template

Three versions in twenty years.
Neither of the two changes actually changed any part of the conditions.
The first change fixed a typo in a comment.
The second changed the placeholder for the Copyright year from CCYY to .
Oh, and the total length of the "terms" is 25 lines, 192 words, 1123 bytes,
including historical information, instructions for developers how to
apply the terms to their code, and a lengthy warranty disclaimer.

The actual terms consist of 3 lines, 33 words, 207 bytes.
So much for "terms" and for changing them.

Yours,
  Ingo

Re: Netstat output

[Ingo Schwarze]

Updated diff based of feedback from jmc@: +conciseness -duplication

Ingo Schwarze wrote on Tue, Sep 12, 2023 at 08:36:07PM +0200:
> David Gwynne wrote on Mon, Sep 11, 2023 at 06:52:56AM +1000:
>> On 7 Sep 2023, at 08:00, Steven Shockley wrote:

>>> When running netstat -I [interface], what do the "fails" and "errs"
>>> columns mean?  When my firewall is under network load, the output
>>> interface fails and total errs increases.

>> fails are the sum of qdrops and errs. qdrops are when the network
>> stack drops packets getting packets on or off the driver, and errs
>> are problems the driver has with packets. netstat -eI foo0 shows the
>> errors on their own, netstat -dI foo0 shows the drops on their own.
>> 
>> if it's qdrops then it's a software performance/configuration
>> problem. if it's errs then it's something in the driver reporting
>> errors. if the driver provides kstats then you might be able to
>> figure out if it's a dodgy cable or something like that.

> Let's make sure this information does not get lost again.
> 
> David, are you OK with the following patch?
> 
> Rationale:
>  * The "either" is just wrong.  The SYNOPSIS explicitly says that
>-I/-i and -w can be combined, and it works, too.
>  * When documenting -I, saying "used with wait" is wrong, too,
>but in the opposite way.  Using -I without -w works quite well.


Index: netstat.1
===
RCS file: /cvs/src/usr.bin/netstat/netstat.1,v
retrieving revision 1.98
diff -u -r1.98 netstat.1
--- netstat.1   4 Jan 2023 19:12:34 -   1.98
+++ netstat.1   12 Sep 2023 21:01:32 -
@@ -143,21 +143,24 @@
 .Fl w
 is specified as well.
 .It Fl d
-With either the interface display (options
+With the interface display (options
 .Fl I
 or
 .Fl i )
 or an interval (option
 .Fl w ) ,
-show only the number of dropped packets.
+show only the numbers of packets dropped by the network stack
+.Pq queue drops ,
+which usually result from software performance or configuration problems.
 .It Fl e
-With either the interface display (options
+With the interface display (options
 .Fl I
 or
 .Fl i )
 or an interval (option
 .Fl w ) ,
-show only the number of errors on the interface.
+show only the numbers of errors detected by the interface driver.
+Errors can, for example, result from hardware problems.
 .It Fl F
 When showing routes, only show routes whose gateway are in the
 same address family as the destination.
@@ -190,9 +193,14 @@
 .It Fl I Ar interface
 Show information about the specified
 .Ar interface ;
-used with a
-.Ar wait
-interval as described below.
+can optionally be combined with a
+.Fl w Ar wait
+interval.
+By default, the sums of all failures are shown, including both
+interface driver errors as reported by
+.Fl e
+and queue drops as reported by
+.Fl d .
 .It Fl i
 Show the state of interfaces which have been auto-configured
 (interfaces statically configured into a system but not

Re: Netstat output

[Ingo Schwarze]

Hi David,

David Gwynne wrote on Mon, Sep 11, 2023 at 06:52:56AM +1000:
> On 7 Sep 2023, at 08:00, Steven Shockley wrote:

>> When running netstat -I [interface], what do the "fails" and "errs"
>> columns mean?  When my firewall is under network load, the output
>> interface fails and total errs increases.

> fails are the sum of qdrops and errs. qdrops are when the network
> stack drops packets getting packets on or off the driver, and errs
> are problems the driver has with packets. netstat -eI foo0 shows the
> errors on their own, netstat -dI foo0 shows the drops on their own.
> 
> if it's qdrops then it's a software performance/configuration
> problem. if it's errs then it's something in the driver reporting
> errors. if the driver provides kstats then you might be able to
> figure out if it's a dodgy cable or something like that.

Let's make sure this information does not get lost again.

David, are you OK with the following patch?

Rationale:
 * The "either" is just wrong.  The SYNOPSIS explicitly says that
   -I/-i and -w can be combined, and it works, too.
 * When documenting -I, saying "used with wait" is wrong, too,
   but in the opposite way.  Using -I without -w works quite well.

Yours,
  Ingo


Index: netstat.1
===
RCS file: /cvs/src/usr.bin/netstat/netstat.1,v
retrieving revision 1.98
diff -u -r1.98 netstat.1
--- netstat.1   4 Jan 2023 19:12:34 -   1.98
+++ netstat.1   12 Sep 2023 18:26:28 -
@@ -143,21 +143,27 @@
 .Fl w
 is specified as well.
 .It Fl d
-With either the interface display (options
+With the interface display (options
 .Fl I
 or
 .Fl i )
 or an interval (option
 .Fl w ) ,
-show only the number of dropped packets.
+show only the numbers of packets that were dropped by the network stack
+.Pq queue drops ,
+but do not show errors detected by the interface driver.
+Queue drops usually result from
+software performance or configuration problems.
 .It Fl e
-With either the interface display (options
+With the interface display (options
 .Fl I
 or
 .Fl i )
 or an interval (option
 .Fl w ) ,
-show only the number of errors on the interface.
+show only the numbers of errors detected by the interface driver,
+but do not show queue drops.
+Errors can for example result from hardware problems.
 .It Fl F
 When showing routes, only show routes whose gateway are in the
 same address family as the destination.
@@ -190,9 +196,14 @@
 .It Fl I Ar interface
 Show information about the specified
 .Ar interface ;
-used with a
-.Ar wait
-interval as described below.
+can optionally be combined with a
+.Fl w Ar wait
+interval.
+By default, the sums of all failures are shown, including both
+interface driver errors as reported by
+.Fl e
+and queue drops as reported by
+.Fl d .
 .It Fl i
 Show the state of interfaces which have been auto-configured
 (interfaces statically configured into a system but not

Re: "OpenBSD Doc" App idea

[Ingo Schwarze]

Hi Daniele,

Daniele B. wrote on Thu, Sep 07, 2023 at 10:47:47PM +0200:

>> I don't know if Android has a similar feature, but at least on iOS you
>> can save a particular website to your home as a webapp from Safari.

> Thanks for the answer Shokara. My initiative was to call for the
> development in the community of a serious app, with commands directory

I'm not quite sure what you mean by "commands directory", but we
certainly provide a directory of commands:

  https://man.openbsd.org/?query=.=1=1

> and full-text search,

OpenBSD does not provide full-text search for its documentation
because full-text search is less powerful and more noisy than
the semantic search we do provide.  For details, see

  https://man.openbsd.org/man1/apropos.1
  https://man.openbsd.org/man.cgi.8

in particular

  https://man.openbsd.org/man1/apropos.1#Macro_Keys
  https://man.openbsd.org/man.cgi.8#HTML_search_interface

If you really want full-text search very badly, you can turn to NetBSD.
Last time i looked, they provided full-text search but not semantic
search.

On OpenBSD, you can of course use

   $ grep -R regexp /usr/share/man

but that will always spew lots of noise and only very rarely
any additional useful results in addition to what

   $ man -k any~regexp

provides.

> working offline

That's a pretty bad idea.  The information on man.openbsd.org
is automatically updated every night; an offline copy would almost
instantly become outdated.

Yours,
  Ingo

Re: "OpenBSD Doc" App idea

[Ingo Schwarze]

Hi Daniele,

Daniele B. wrote on Thu, Sep 07, 2023 at 06:08:06PM +0200:

> I simply opened my Google Play and I tried to search Unix
> and related terms, etc etc.

I had to look up what "Google Play" means, but now your question
is specific enough to allow an authoritative answer:

Providing apps to the "Google Play" app store falls outside the
scope of the OpenBSD project.

In particular, there is no interest in providing an "OpenBSD Doc"
app on Google Play, nor can i see any need for such an app.

To access OpenBSD docs on your Android device, simply use

  https://man.openbsd.org/

and report any adaptive design issues you might encounter.

Yours,
  Ingo

-- 
> Sorry to have awaked you,

I may have looked asleep, but i was merely writing documentation.  =:c)
#slackers

Re: "OpenBSD Doc" App idea

[Ingo Schwarze]

Hi Daniele,

Daniele B. wrote on Thu, Sep 07, 2023 at 04:27:18PM +0200:

> Just pushing myself over any device limit..

Huh?  What does that mean?

> I just searched the App Stores for "Unix" and related ones
> and wondering if we can hope to have an "OpenBSD Doc"
> app beside a "FreeBSD Doc" app anytime soon?

I'm usually interested in anything related to BSD documentation,
but it seems pretty unclear to me what you are talking about here.
What is the meaning of the term "app store"?

The "app store" for OpenBSD is documented in the manual pages pkg_add(1)
and packages(7), but you do not need any of that for reading OpenBSD
documentation nor for reading third-party documentation on OpenBSD.

The "app" you use on OpenBSD for reading documentation is standardized
by POSIX, called man(1), and on OpenBSD, it provides many extensions to
the standard.  Alternatively, at points in time when you do not have
access to any OpenBSD system, you can also read OpenBSD documentation
here, without needing any "app" whatsoever, in plain HTML5+CSS format:

  https://man.openbsd.org/

Now *if* you are talking about mobile devices, effort has been spent
on giving https://man.openbsd.org/ an adaptive design.  In case there
are still any respects in which it isn't mobile-friendly, reports
are quite welcome.  Again, no "app store" needed for all i know...

In case you are talking about Android mobile devices - which,
admittedly, is a wild guess on my part - the Termux system already
includes the OpenBSD version of man(1) by default, and it has been
doing so for more than a decade now.  In that sense, Android already
has an OpenBSD documentation app.  For more information, see:

  https://termux.dev/

In case you are talking about Apple devices running macOS, newer
versions of that system now also use the OpenBSD implementation as
the formatting engine in their man(1) program - though last time i
heard something about that, it didn't appear to be quite stable yet
but hastily stitched together and rather buggy, as usual with Unix
software on macOS in general.

> Anyone's offer? Yes I'm talking to you.. ;D

I feel very confused by your request, and i fear i don't really
understand what you are asking for.

Yours,
  Ingo

Re: Supporting the OpenBSD Project through a Registered Charity

[Ingo Schwarze]

Hello Katherine,

Katherine Mcmillan wrote on Tue, Aug 29, 2023 at 11:43:21AM +:

> I'm wondering if there are any registered charities (in Canada,
> or frankly, any country!) dedicated to promoting/supporting OpenBSD?

I think you severely underestimate the complexity of charity law here.
You claim that Canadian law distinguishes two classes of organizations
that could broadly be regarded as charities, namely, "non-profits"
and "recognized charities".  I cannot say whether that is accurate,
but both the number of such classes and how they are defined vary
widely from country to country.  For example, in Germany, there are
three classes rather than two classes - namely, organizations "for
public interests", "for charity", and "for state-recognized religions".
The goal of "supporting the development of free software" in itself
would not fall into any of these categories, nor would the goal of
"promoting the use of free software".  An organization similar to
the OpenBSD Foundation might still have a chance to get recognized
as "in the public interest" in Gemany if it argues that its main
goals are "research in computer science" and "education", but getting
that status would involve proving that in written form and submitting
documents as evidence to the appropriate German authorities.  I know
more than one of the Directors of the OpenBSD Foundation personally,
and even without asking them, i feel quite confident in saying that i
consider it unlikely that they would want to spend any work on that -
not even cosidering that very likely, it would be necessary to adapt
the Bylaws of the foundation to better agree with German law, which
in turn might possibly provoke new conflicts with Canadian law.

The above complexities are why most large charities set up their
own charitable organization for (almost) every country they operate
in.  There are much more than a hundred countries in the world.
That's more than OpenBSD has developers.

Note that one goal in setting up the OpenBSD Foundation was to shield
developers from being distracted from the work they want to do, and
instead be able to simply point people to asking non-technical questions
about funding to the Directors of the OpenBSD foundation.

Consequently, i think it would be more productive for you to ask the
Directors of the OpenBSD Foundation in private whether they think
there is any problem in the area your are talking about, and whether
they think you can help solving it, rather than starting a public
discussion.  Be aware that, if the answer should happen to be "no" -
i honestly don't know whether it will - that would be good news.
Not having a problem is always good, isn't it?  There are so many
other things in the context of OpenBSD one could work on.

By the way, in March 2022, you said you were interested in contributing
code to the OpenBSD project, and i provided specific advice regarding
your questions to you, because people working on the code are always
welcome.  Did you make any progress with anything you planned or
with anything i suggested in my private mail to you dated 20 Mar 2022
21:34:11 +0100 ?  I'm sorry if i missed your reply, that sometimes
happens with all the mail flying around...

Yours,
  Ingo

Re: Why does `pkg_info -m` show quirks?

[Ingo Schwarze]

Hi,

Stuart Henderson wrote on Fri, Aug 18, 2023 at 05:52:07PM -:
> On 2023-08-18, l...@ena.re  wrote:

>> Also, what is the reason the quirks package does not have a man page?

Usually, there is no manual page documenting a package as a whole.

>> I believe it should have one, just like any other program.

The quirks package certainly isn't a program.
Right now, i fail to see any evidence that it even *contains* any program.

>> Is this something that is desired?

The following is certainly not a good syllogism:
  "There is no manual page documenting this package"
=> "We need a manual page documenting this package"

Even the folliwing, weaker syllogism may occasionally be false:
  "This package contains no manual page"
=> "We should write a manual page to include in the package"

Is information about the quirks package missing from the manual pages?
Maybe, it doesn't seem unlikely to me, but i'm far from sure.

>> If so, I would gladly model one after the package description.

What a terrible idea.  Most of that information is already contained
in the manual page sthen@ mentioned:

> packages(7) - overview of the binary package system

I think what packages(7) says is also easier to understand than
what the quirks package description says.

> not sure what such a manpage would be named.

Given that manual pages are named after programs, functions, devices,
or file formats,

   $ pkg_info -L quirks

tells me that a manual page to be included in the quirks package
could be named:

  OpenBSD::Quirks(3p)

   - that one would document the Perl API of the OpenBSD::Quirks
 Perl package, similar to e.g. OpenBSD::PackingElement(3p)
 or OpenBSD::State(3p)

or

  update.db(5)

   - that one would document the file format of the file
 /usr/local/share/update.db and explain how that file
 is used, similar to mandoc.db(5) or locate(1) --
 by the way, it does look like we are missing a
 locate.database(5) manual page

> it is already described here though:
> $ man -k any=quirks
> packages(7) - overview of the binary package system

Right, any information about the quirks package that doesn't
belong into OpenBSD::Quirks(3p) or update.db(5) probably
belongs into packages(7) or pkg_add(1).

Yours,
  Ingo

Re: My /usr cleaning campaign..

[Ingo Schwarze]

Hi Daniele,

if you *really* want user customization as massive as what you
keep talking about, OpenBSD is likely the wrong system for you.
More than any other system, OpenBSD is optimized for sane defaults,
with the goal that users need to customize as little as possible.
Providing lots of configuration options for everything is not among
the project goals.  If you are looking for a system where user
configurability is among the central goals, you might want to look
at Gentoo Linux or a similar system.

If you *really* want to run on hardware so tiny that you worry about
100 MB of disk space below /usr/local/, again, OpenBSD is likely
the wrong system for you in 2023 (i did run an OpenBSD firewall on
24 MB of RAM and 200 MB of disk grand total in 2002, but this is no
longer 2002).  Sure, OpenBSD still comes with a smaller footprint
than many other general purpose systems - but if you want to go *that*
tiny, you might want to look at Alpine Linux, which is optimized for
extremely small hardware, or at similar systems.

Daniele B. wrote on Sun, Aug 13, 2023 at 09:13:54PM +0200:

> Indeed, I point you out prbs in the hope to help

Right now, you are certainly not helping anything.  Rather, you are
distracting developers.  What you are pointing out are not "problems"
but a pair of feet looking similar to swiss cheese after extensive
use of a shotgun, and you keep talking about plans to apply the
same treatment to your knees and your belly as well.

By now, it is abundantly clear you lack the basic skills you would
need to deviate from the default OpenBSD configuration even in simple
ways, let alone to identify problems in OpenBSD (which do exist).

Yours,
  Ingo

-- 
Ingo Schwarze 
http://www.openbsd.org/   
http://mandoc.bsd.lv/ 

Re: Possible off-by-one bug in usr.sbin/rad/engine.c

[Ingo Schwarze]

Hi Alejandro,

Alejandro Colomar wrote on Sat, Dec 31, 2022 at 05:56:27PM +0100:

> I've started auditing the OpenBSD source code after the discussion on 
> arc4random_uniform(3) and my suggestion of arc4random_range() on the glibc 
> mailing list.
> 
> I found some cases where it seems like there's an off-by-one bug, which
> would be solved by providing arc4random_range().  I'll show here one,
> to confirm that it's a bug, and if you confirm it, I'll continue fixing
> similar bugs around the OpenBSD tree.
> 
> Here's the first one I found, which I hope is fixed by my patch:
> 
> 
> diff --git a/usr.sbin/rad/engine.c b/usr.sbin/rad/engine.c
> index ceb11d574e3..a61ea3835a6 100644
> --- a/usr.sbin/rad/engine.c
> +++ b/usr.sbin/rad/engine.c
> @@ -641,8 +641,7 @@ iface_timeout(int fd, short events, void *arg)
>  struct imsg_send_ra  send_ra;
>  struct timeval   tv;
> 
> -   tv.tv_sec = MIN_RTR_ADV_INTERVAL +
> -   arc4random_uniform(MAX_RTR_ADV_INTERVAL - MIN_RTR_ADV_INTERVAL);
> +   tv.tv_sec = arc4random_range(MIN_RTR_ADV_INTERVAL, 
> MAX_RTR_ADV_INTERVAL);
>  tv.tv_usec = arc4random_uniform(100);

Currently, the code puts a number in the range [200, 600) in tv_sec
and a random number of microseconds into tv_usec,
i.e. the timeout will be greater than or equal to 200 seconds
and strictly less than 600 seconds with a uniform distribution.

Isn't that exactly what is intended?

>  log_debug("%s new timeout in %lld", __func__, tv.tv_sec);
> 
> 
> If I'm correct, it should have been 'min + (max - min + 1)' instead
> of 'min + (max - min)'.  Please confirm.

With your change, the timeout could go up to 600.99, i.e. almost 601
seconds.  I don't know the protocol and can't say whether the change
would matter, but naively, exceeding the MAX_ feels surprising to me.

Really, this doesn't look like a bug to me...

Yours,
  Ingo

Re: [RFC v1 1/2] Add arc4random_range(min, max)

[Ingo Schwarze]

Hi Alexandro,

i fail to see the point.  We do not usually add extra functions
if the same effect can be be attained with one-liners.  There is
significant value in keeping the API as small as possible, it
makes the API easier to learn and it makes programming mistakes
less likely.  On top of that, code using the one-liner is usually
easier to read than code involving yet another wrapper.

On top of that, consider that arc4random_uniform(upper_bound)
produces a number in [0, upper_bound), *not* in [0, upper_bound].
Consistency of an API is similarly important as smallness.
So introducing a variant that produces [min, max] rather than
[min, max) looks like a non-starter to me.  You are setting a
giant trap provoking off-by-one errors!

Some additional comments follow in-line, even though i doubt they
matter much: i think that nothing should be added, and you did not
provide any rationale why this might be needed.


Alejandro Colomar wrote on Sat, Dec 31, 2022 at 07:18:55PM +0100:

> diff --git a/include/stdlib.h b/include/stdlib.h
> index ab8a2ae90c3..16b7dc43afc 100644
> --- a/include/stdlib.h
> +++ b/include/stdlib.h
> @@ -313,6 +313,7 @@ u_quad_t strtouq(const char *__restrict, char 
> **__restrict, int);
>  
>  uint32_t arc4random(void);
>  uint32_t arc4random_uniform(uint32_t);
> +uint32_t arc4random_uniform(uint32_t, uint32_t);

Uh oh.  That looks doubleplusungood.

> --- a/lib/libc/crypt/arc4random.3
> +++ b/lib/libc/crypt/arc4random.3
> @@ -46,6 +46,8 @@
[...]
> @@ -95,16 +97,47 @@
>  In the worst case, this function may consume multiple iterations
>  to ensure uniformity; see the source code to understand the problem
>  and solution.
> +.Pp
> +.Fn arc4random_range
> +is similar to
> +.Fn arc4random_uniform ,

I very strongly object to this description.  I is an outright lie!
arc4random_uniform -> upper_bound)  *exclusive*
arc4random_range   -> upper_bound]  *inclusive*

> +and will return a single 32-bit value,

The word "will" is unwelcome in manual pages, unless you have
some exceptional justification why it is needed in a particular case.

> +uniformly distributed,
> +within the inclusive range
> +.Pf [ Fa min ,
> +.Fa max ].
> +If the arguments are reversed,
> +that is,
> +if
> +.Fa max
> +<
> +.Fa min ,
> +it will return a single 32-bit value,
> +uniformly distributed,
> +outside of the exclusive range
> +.Pf ( Fa max ,
> +.Fa min ).

Is this ever needed in practice?
It sounds complicated and confusing.
We should not add API specifications just because we can,
espially not in libc.

>  .Sh RETURN VALUES
>  These functions are always successful, and no return value is
>  reserved to indicate an error.
> +.Sh CAVEATS
> +.Fn arc4random_range
> +doesn't produce correct output when
> +.Fa max
> +==
> +.Fa min
> +- 1.

Looks like a landmark symptom of bad API design: setting a trap for
the unwary with no good reason.  We should not provide bad API
functions and then document their shortcomings.

>  .Sh SEE ALSO
>  .Xr rand 3 ,
>  .Xr rand48 3 ,
>  .Xr random 3
>  .Sh HISTORY
>  These functions first appeared in
> -.Ox 2.1 .
> +.Ox 2.1 ,
> +except
> +.Fn arc4random_range ,
> +which appeared in
> +.Ox XXX .
>  .Pp
>  The original version of this random number generator used the
>  RC4 (also known as ARC4) algorithm.
> diff --git a/lib/libc/crypt/arc4random_uniform.c 
> b/lib/libc/crypt/arc4random_uniform.c
> index a18b5b12381..40957910b96 100644
> --- a/lib/libc/crypt/arc4random_uniform.c
> +++ b/lib/libc/crypt/arc4random_uniform.c
> @@ -2,6 +2,7 @@
>  
>  /*
>   * Copyright (c) 2008, Damien Miller 
> + * Copyright (c) 2022, Alejandro Colomar 

Adding a Copyright notice is inappropriate in most parts of OpenBSD
except for the main authors of the file.  Merely adding something
that is Copyright-worthy is not enough.  Besides, i suspect your
patch reaches the Copyright threshold only due to the comment -
the function itself is likely trivial even according to the low
threshold of Copyright law.

Yours,
  Ingo

>   *
>   * Permission to use, copy, modify, and distribute this software for any
>   * purpose with or without fee is hereby granted, provided that the above
> @@ -55,3 +56,14 @@ arc4random_uniform(uint32_t upper_bound)
>   return r % upper_bound;
>  }
>  DEF_WEAK(arc4random_uniform);
> +
> +/*
> + * Calculate a uniformly-distributed random number in the range [min, max],
> + * avoiding bias.
> + */
> +uint32_t
> +arc4random_range(uint32_t min, uint32_t max)
> +{
> + return arc4random_uniform(max - min + 1) + min;
> +}
> +DEF_WEAK(arc4random_range);
[...]

Re: Geomant - Would you review my first C project ?

[Ingo Schwarze]

Hi Jason,

jkinne...@yahoo.ca wrote on Tue, Aug 16, 2022 at 12:04:20AM +:

> As long as learning C came up, does anyone from the OpenBSD community 
> have an opinion on whether this training for writing secure C would be
> worthwhile for someone with mid-level skills?
> https://www.sei.cmu.edu/education-outreach/courses/course.cfm?courseCode=V35

This isn't perfectly on topic, but i doubt you will find overwhelming
enthusiam for the purchase of a "professional certificate" on an
OpenBSD list.

I know several people inside OpenBSD and a number outside whom i
would trust to be able to code to good security standards, but if
somebody presented me with a certificate, that would more likely
inspire significant doubt than any kind of confidence in me, no
matter how reputable the organization issuing the certificate...

Apart from that, the media and methods that help people to learn differ
from person to person, but regarding the topics of this particular
course, it looks like you get about the same range of topics, and
maybe even more, in any case for significantly less money, from buying
Dowd/McDonald/Schuh, "The Art of Software Security Assessment" and
studying that, and then applying it to a real code base.  Of course,
you will need *lots* of practical experience in addition, which
you can neither get from taking a course nor from reading a book,
but only from practical work.

Mid-level is a rather fuzzy term, but some might say these topics are
good to get acquainted with even for beginners, and yet a mid-level
programmer seems unlikely to master them.

Yours,
  Ingo

Re: new group

[Ingo Schwarze]

Hello Ashish,

ashish rai wrote on Wed, Aug 10, 2022 at 08:27:43PM +0530:

> 0
> C INDIA
> P Uttar Pradesh
> T Varanasi
> F Irregular

To list a new group, there should be at least some evidence that
the group has been holding regular meetings lately.  In this case,
so far, i fail to see any evidence that the group exists.

Note the the intention to found a group is *not* sufficient for
adding a listing.

> O OpenBSD INDIA
> I Ashish Kumar Rai
> M raiashis...@gmail.com
> U https://www.linkedin.com/in/raiashish20/

That isn't the website of a BSD user group.

A personal website where you post a notice that you are personally
in search of a job is not appropriate for a listing as a BSD user
group.

I think i would hesitate to put *any* link to *any* page
on linkedin.com onto openbsd.org because linkedin.com is
notorious for not showing information to users that are not
logged in.

The whole point of advertising a user group is to show the
information to anybody - and not only to users of linkedin.com.
Consequently, such information sould be utterly misplaced on that
site.

Yours,
  Ingo

Re: support new

[Ingo Schwarze]

Hello Jiri,

Jiri Navratil wrote on Sat, Jul 30, 2022 at 07:54:53PM +0200:

> could someone guide me please, what I have to improve in my request
> and/or on my web page to be approved for
> https://www.openbsd.org/support.html ?

Your request is just fine.

You provide all the relevant information in your support.dat record
and you have a website making it clear that you provide OpenBSD-related
services.

Having more details about your skills and experiences on the website,
and maybe have the website provide examples of successfully completed
projects, might be helpful to convince potential customers you are
the right person for their job, but it is not required for a listing.

I'm sorry i let this request slip for so long.
But now i finally committed it about half an hour ago.

Please have a look at

  https://www.openbsd.org/support.html

now to confirm that your data is indeed correct.

> 0
> C Czech Republic
> P
> T Prague
> Z 15800
> O JIRI NAVRATIL (R)

> A Kacirkova 1016/19
> I Jiri Navratil

For these two lines, i used the correct accents.
The UTF-8 encoding is now the default in HTML5,
and i think using it in such a page that is clearly geared
to various national audiences makes some sense, even though
many entries still use US-ASCII only for historical reasons.

Yours,
  Ingo

> M j...@navratil.cz
> U https://nocloud.cz/
> B +420 777 224 245
> X
> N OpenBSD/Linux installation, maintenance and support. Providing on-premise 
> solutions with OpenBSD on physical HW. Teaching Unix operating systems at 
> University of Ostrava with OpenBSD as the Unix-like operating system.

Re: documentation

[Ingo Schwarze]

Hi,

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

  https://www.openbsd.org/faq/index.html

and

  https://www.openbsd.org/faq/pf/index.html .

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

  https://man.openbsd.org/pf.conf.5

which is much shorter than

  https://www.openbsd.org/faq/pf/index.html

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.

Yours,
  Ingo

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

[Ingo Schwarze]

Hi,

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://git.launchpad.net/~ubuntu-kernel-test/ ... 

The official website is https://cvsweb.openbsd.org/src/sys/ .

This is an unofficial clone, usually having the same content (no
guarantee, though):  https://github.com/openbsd

>> Or directly the url of kernel configuration files
>> (eg. https://github.com/KaOSx/core/blob/master/linux/config)?

> OpenBSD's kernel configs are under 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/(machine 
> arch)/conf/GENERIC(.MP) and 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/conf/GENERIC(.MP). See 
> also https://man.openbsd.org/config.8.

These URIs are correct.

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

Alternatively, you can use anonymous CVS:

  https://www.openbsd.org/anoncvs.html

>> 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.

Yours,
  Ingo

-- 
Ingo Schwarze 
http://www.openbsd.org/   
http://mandoc.bsd.lv/ 

Re: rc.daily missing diff markers

[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.

Yours,
  Ingo

Re: rc.daily missing diff markers

[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
To: r...@usta.de
Subject: hera.usta.de 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.

Yours,
  Ingo

Re: support update

[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 dun...@appliedopenbsd.com
> U https://AppliedOpenBSD.com
> 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.

Yours,
  Ingo


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 @@
 0
 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
 M dun...@appliedopenbsd.com
-U https://AppliedOpenBSD.com/
+U https://AppliedOpenBSD.com
 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
 0

Re: HW raid adapter - Adaptec 8405 SGL

[Ingo Schwarze]

Hi,

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:
> https://nickh.org/warstories/adaptec.html

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:

  https://marc.info/?l=openbsd-misc=110384546229848  (2004-12-23)
... then follow the thread to ...
  https://marc.info/?l=openbsd-misc=110417903607462
  https://marc.info/?l=openbsd-misc=110521055729466
...

If finally ends here:

  https://marc.info/?l=openbsd-misc=110540361502637  (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:

  https://marc.info/?l=openbsd-misc=80290020263  (2005-03-26)
  https://marc.info/?l=openbsd-misc=80845207030  (2005-03-26)
(Same problems under Linux as under OpenBSD)
...
  https://marc.info/?l=openbsd-misc=111938104307414  (2005-06-21)
(Full summary of all the problems)

  https://marc.info/?l=openbsd-misc=112749851526934  (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:

  https://marc.info/?l=openbsd-misc=125779509813346  (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.

Yours,
  Ingo

Re: Is fw_update documentation outdated?

[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
  /usr/src/bin/cat/cat.c:
$OpenBSD: cat.c,v 1.32 2021/10/24 21:24:21 deraadt Exp $
   $ what /bin/cat
  /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!

Yours,
  Ingo

P.S.
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?

[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 https://man.openbsd.org/fw_update)

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 https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ 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.

Yours,
  Ingo


> 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

[Ingo Schwarze]

Hi,

tetrahe...@danwin1210.de 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,
  Ingo

Re: Missing action list in lesskey man page

[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
documented.

>> - '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

[Ingo Schwarze]

Hi,

jwinnie@tilde.institute 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.

Yours,
  Ingo

Re: MANPATH resets output paper setting

[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 bsd.lv, 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.

Yours,
  Ingo

Re: MANPATH resets output paper setting

[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 bsd.lv, 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..."

Yours,
  Ingo


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
file.

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

Modified Files:
--
mandoc:
manpath.c

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);
 
 
 void
-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

[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.

Yours,
  Ingo

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

[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
unlimited.

Yours,
  Ingo

Re: Snapshot generation stalled?

[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 hostserver.de to spline.de and then to 
> cdn.openbsd.org 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?

https://www.openbsd.org/hackathons.html

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.

Yours,
  Ingo

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

[Ingo Schwarze]

Hi,

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
excessive.

Yours,
  Ingo

Re: support update

[Ingo Schwarze]

Hi,

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 dun...@appliedopenbsd.com
> U https://AppliedOpenBSD.com/
> B +61 3 7065 5840
> N Proactively secure web application development using the BCHS (OpenBSD, C, 
> httpd, SQLite) software stack.

Committed.
  Ingo

Re: Submitting Patches

[Ingo Schwarze]

Hi Ben,

b...@0x1bi.net 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 https://www.openbsd.org/mail.html .

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.

Yours,
  Ingo

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

[Ingo Schwarze]

Hi,

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. 
  [...]
  FILES
  [...]
  /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
  /usr/bin/login

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

Yours,
  Ingo

Re: groups new

[Ingo Schwarze]

Hi Stefan,

committed!

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.

Yours,
  Ingo

P.S.
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 s...@uugrn.org
> U https://uugrn.org
> N *BSD

Re: groups new

[Ingo Schwarze]

Hi Stefan,

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

> U https://uugrn.org

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

 $ w3m -dump_source https://uugrn.org
Redirection loop detected (https://uugrn.org/)




302 Found
[...]


302 Found

OpenBSD httpd



Could you please check?

Yours,
  Ingo

Re: new support

[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.

Yours,
  Ingo


bi...@apisoft.pl 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 bi...@apisoft.pl
> U https://www.apisoft.pl/
> 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

[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
says:

  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
  [...]
  DIAGNOSTICS
  [...]
  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.

Yours,
  Ingo

Re: displaying and typing czech letters

[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!".

Yours,
  Ingo

Re: support and consulting: new entry request

[Ingo Schwarze]

Hi Navan,

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

> The TLS certificate is invalid for https://obsd.solutions/.
> It's for some mcafee.com names. 

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

Serial Number:
05:d8:3c:dd:c3:1f:f3:15:6c:4f:96:db:14:a2:cd:43
Issuer: C=US, O=Cloudflare, Inc., CN=Cloudflare Inc ECC CA-3
Subject: C=US, ST=California, L=San Francisco, O=Cloudflare, Inc.,
 CN=sni.cloudflaressl.com
X509v3 extensions:
X509v3 Subject Alternative Name: 
DNS:sni.cloudflaressl.com,
DNS:obsd.solutions, DNS:*.obsd.solutions

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

I see nothing involving mcafee.com in there.

Yours,
  Ingo

Re: Localization of date(1) and XFCE

[Ingo Schwarze]

Hi,

Jan Stary wrote on Tue, Jun 22, 2021 at 11:24:15AM +0200:
> On Jun 20 18:58:31, ffuen...@texto-plano.xyz 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
>> https://docs.xfce.org/xfce/xfce4-panel/4.16/clock so how do I make date to
>> work with my language.
>> 
>> This is my locale:
>> 
>> LANG=es_CL.UTF-8
>> LC_COLLATE="es_CL.UTF-8"
>> LC_CTYPE="es_CL.UTF-8"
>> LC_MONETARY="es_CL.UTF-8"
>> LC_NUMERIC="es_CL.UTF-8"
>> LC_TIME="es_CL.UTF-8"
>> LC_MESSAGES="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
  [...]
  CAVEATS
 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
  [...]
  CAVEATS
 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.

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

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

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

 LC_NUMERIC
 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
 points.

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

 LC_CTYPE
 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),
 wctob(3)

Yours,
  Ingo

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

[Ingo Schwarze]

Hi,

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.

Yours,
  Ingo

Re: MANPAGER

[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:

  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/man.html
  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
  documentation.

> '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.

Yours,
  Ingo

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

[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.  :-)

Yours,
  Ingo

Re: Website - Missing kstat man page

[Ingo Schwarze]

Hi,

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 https://www.openbsd.org/68.html,
>> I noticed URL link on the webpage for kstat(1) generates
>> a "No results found." message when pointing to its man page:
>> 
>> https://man.openbsd.org/kstat
>> 
>> 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.

Yours,
  Ingo


> 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]: 
> https://github.com/openbsd/src/blob/a09091e54b85e8cd86ccf4763998e3800065d5dc/usr.bin/kstat/kstat.1
> [2]: 
> https://raw.githubusercontent.com/openbsd/src/a09091e54b85e8cd86ccf4763998e3800065d5dc/usr.bin/kstat/kstat.1
> 
> (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
> https://static.chown.me/private/misc/kstat.html

Re: OpenSMTPD-extras manual

[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?

Try:

   $ 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
distributions.

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.

Yours,
  Ingo

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

[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.

Yours,
  Ingo

Re: support new

[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.

Yours,
  Ingo

Re: support new

[Ingo Schwarze]

Hi,

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 cont...@amglabs.net
> U https://www.amglabs.net/
> 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.

Yours,
  Ingo

Re: support new

[Ingo Schwarze]

Hi,

supo...@mdfsoftware.com.br wrote on Sun, Nov 29, 2020 at 01:40:18PM -0300:

> 0
> C Brazil
> P Ceará
> T FORTALEZA
> Z 60410442
> O MDFSoftware
> I Oliveira Filho, D. A.
> A Av. Eduardo Girão 355
> M supo...@mdfsoftware.com.br
> U http://www.mdfsoftware.com.br/
> 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.

Yours,
  Ingo

Re: development best practices

[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.

Yours,
  Ingo

Re: support new

[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 www.openbsd.org 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
explanation.

Yours,
  Ingo

Re: support new

[Ingo Schwarze]

Hi,

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.

Yours,
  Ingo


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 e...@tuta.io
> U
> B
> X
> N OpenBSD consulting and support. Experienced in OpenBSD httpd,
> relayd and Packet Filter (PF).

Re: groups new

[Ingo Schwarze]

Hi,

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

> 0
> C ITALY
> P Cosenza
> T San Marco Argentano
> F Irregular
> O OpenBSD CpnetServer
> I Ernesto Bellomusto
> M open...@cpnetserver.net
> U node51.net
> 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.

Yours,
  Ingo

Re: support new

[Ingo Schwarze]

Hi,

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

> 0
> C ITALY
> P Cosenza
> T San Marco Argentano
> Z 87018
> O Computer Planet
> I Ernesto Bellomusto
> A P.zza Giuseppe Garibaldi, 7
> M open...@cpnetserver.net
> U http://www.node51.net/ 

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.

https://cpnetserver.net/ only returns a security warning
("The certificate is not trusted because it is self-signed.")

http://cpnetserver.net/ 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.

Yours,
  Ingo

> 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

[Ingo Schwarze]

Hi,

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 bsd.lv server,
which serves the mailing lists in two distinct domains:

 - @mandoc.bsd.lv
 - @manpages.bsd.lv

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.

Yours,
  Ingo


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

Re: du man page

[Ingo Schwarze]

Hi,

a...@sdf.org wrote on Wed, Oct 21, 2020 at 11:44:01AM +:

> In du(1) it reads:
> 
> [...]
> EXAMPLES
>  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.

Yours,
  Ingo


CVSROOT:/cvs
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:
 .Pp
-.Dl $ du -sh * .??* | sort -h
+.Dl $ du -had 1 | sort -h
 .Sh SEE ALSO
 .Xr df 1 ,
 .Xr fts_open 3 ,

Re: Using ports and updates to the release

[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

  https://www.openbsd.org/faq/faq15.html# about packages
  https://www.openbsd.org/faq/ports/ports.html  # 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.

Yours,
  Ingo

Re: time_t

[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.

https://man.openbsd.org/time.3#HISTORY

  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.

Yours,
  Ingo

Re: time_t

[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.

http://www.openbsd.org/lyrics.html#55

> 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!!!).

https://man.openbsd.org/mktime.3#RETURN_VALUES
https://man.openbsd.org/time.3#RETURN_VALUES

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

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html

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.

Yours,
  Ingo

Re: OpenBSD fakeroot

[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:
>> 
>>   https://manpages.debian.org/buster/fakeroot/fakeroot.1.en.html
>> 
>> 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:
>> 
>>   https://man.openbsd.org/mount.8#noperm

> 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
kern.audio.record, 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...

Yours,
  Ingo

Re: OpenBSD fakeroot

[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:

  https://manpages.debian.org/buster/fakeroot/fakeroot.1.en.html

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.

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

  https://man.openbsd.org/mount.8#noperm

Yours,
  Ingo

Re: support new

[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 https://openbsd.amsterdam/
>>> 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 openbsd.amsterdam is.

Yours,
  Ingo

Re: support new

[Ingo Schwarze]

Hi,

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 service@openbsd.amsterdam
> U https://openbsd.amsterdam/
> B
> X
> N Hosting OpenBSD VMs on dedicated vmm(4)/vmd(8) servers.

Committed, thanks.
  Ingo

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

[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.

Yours,
  Ingo

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

[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

  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html

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

Yours,
  Ingo

Re: home printer

[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.

Yours,
  Ingo

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

[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

Done.

> 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.

Yours,
  Ingo

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

[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?

Yours,
  Ingo

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

[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?
  Ingo


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

[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.

Yours,
  Ingo

Re: fido library

[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
  ./regress/usr.bin/ssh/misc/kexfuzz/Makefile
  LDADD+= -lfido2 -lcbor -lusbhid
  ./regress/usr.bin/ssh/unittests/Makefile.inc
  LDADD+= -lfido2 -lcbor -lusbhid
  ./usr.bin/ssh/ssh-sk-helper/Makefile

   $ 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)

  NAME
 ssh-sk-helper  OpenSSH helper for FIDO authenticator support

  SYNOPSIS
 ssh-sk-helper [-v]

  DESCRIPTION

Yours,
  Ingo

Re: exFAT support

[Ingo Schwarze]

Hi John,

jo...@armadilloaerospace.com 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.

Yours,
  Ingo

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

[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.

Yours,
  Ingo

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

[Ingo Schwarze]

Hi,

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.

Yours,
  Ingo

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

[Ingo Schwarze]

Hi,

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
>> man.openbsd.org

> 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.

Yours,
  Ingo

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

[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
>> man.openbsd.org

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

  https://man.openbsd.org/ports-current/got.1

> 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 man.openbsd.org

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.

Yours,
  Ingo

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

[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
man.openbsd.org and mandoc.bsd.lv, 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
nowadays.

> 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.

Yours,
  Ingo