Re: MANPAGER

2021-06-04 Thread Ingo Schwarze
Hi Heinrich,

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

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

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

  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)

2021-01-26 Thread Ingo Schwarze
Hi Faraz,

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

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

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

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

All the best for you!

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

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

Yours,
  Ingo



Re: Website - Missing kstat man page

2021-01-03 Thread 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

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

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

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

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?

2020-12-12 Thread Ingo Schwarze
Hi Aisha,

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

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

I freely admit i didn't look at that.

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

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

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

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

> (if they exist?)

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

Yours,
  Ingo



Re: support new

2020-12-09 Thread Ingo Schwarze
Hi Janne,

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

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

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

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

Anyway, i just added the entry.

Yours,
  Ingo



Re: support new

2020-12-09 Thread 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

2020-11-29 Thread 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

2020-11-28 Thread Ingo Schwarze
Hi Bjoern,

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

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

It really depends on the case at hand.

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

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

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

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

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

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

Yours,
  Ingo



Re: support new

2020-11-17 Thread Ingo Schwarze
Hi Emre,

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

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

That won't happen.

> I believe I am entitled

You are not entitled to anything.  The server 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

2020-11-16 Thread 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

2020-11-01 Thread 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

2020-11-01 Thread 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

2020-10-27 Thread 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

2020-10-21 Thread 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

2020-10-11 Thread Ingo Schwarze
Hi Ed,

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

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

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

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

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

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

For details, see

  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

2020-10-05 Thread Ingo Schwarze
Hi Peter,

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

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

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

2020-10-05 Thread Ingo Schwarze
Hi Rodrick,

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

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

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

2020-10-03 Thread Ingo Schwarze
Hi Richard,

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

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

>> You are not really explaining what it is that you actually
>> want to do...
>> 
>> So i'm guessing a bit:
>> 
>>   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

2020-10-03 Thread Ingo Schwarze
Hi Richard,

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

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

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

So i'm guessing a bit:

  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

2020-10-01 Thread Ingo Schwarze
Hi Ottavio,

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

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

2020-10-01 Thread 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

2020-09-22 Thread Ingo Schwarze
Hi Demi,

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

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

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

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

Exactly, so this is not likely to go anywhere.

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

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

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

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

Yours,
  Ingo



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

2020-09-18 Thread Ingo Schwarze
Hi Ottavio,

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

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

>From sh(1), second paragraph:

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

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

  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

2020-09-17 Thread Ingo Schwarze
Hi Carson,

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

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

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

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

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

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

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

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

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

Yours,
  Ingo



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

2020-09-14 Thread Ingo Schwarze
Hi Theo,

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

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

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

2020-09-14 Thread Ingo Schwarze
Hi Brian,

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

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

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

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

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

Yours,
  Ingo



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

2020-09-14 Thread Ingo Schwarze
Hi Theo,

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

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

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

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

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

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


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

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

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

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


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


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

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

Opinions, concerns, tests, OKs?
  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

2020-09-14 Thread Ingo Schwarze
Hi Todd,

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

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

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

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

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

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

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

Yours,
  Ingo



Re: fido library

2020-08-26 Thread Ingo Schwarze
Hi Mihai,

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

   $ cd /usr/src/
   $ find . -name 'Makefile*' -exec grep lfido {} \; -print
  LDADD+= -lfido2 -lcbor -lusbhid
  ./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

2020-08-06 Thread 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

2020-07-14 Thread Ingo Schwarze
Hi Ottavio,

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

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

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

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

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

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

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

Yours,
  Ingo



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

2020-07-14 Thread 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?

2020-06-27 Thread 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?

2020-06-27 Thread Ingo Schwarze
Hi Marc,

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

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

>> Doing that would be very annoying and painful, and very few people
>> would want it.  It would also substantially degrade the clarity at
>> 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?

2020-05-21 Thread Ingo Schwarze
Hi David,

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

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

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

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

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

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

Sure.  That's exactly the same way as i'm maintaining machines like
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



Re: OpenBSD sysupgrade rocks

2020-05-20 Thread Ingo Schwarze
Hi Chris,

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

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

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

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

I disagree.

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

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

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

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

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

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

  https://www.openbsd.org/papers/eurobsdcon2014-mandoc-slides.pdf

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

Yours,
  Ingo



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

2020-05-20 Thread Ingo Schwarze
Hi Andras,

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

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

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

Good, i'll just wait for your results.

> In general: man pages are reference material

Yes.

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

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

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

> often not meant to be read cover to cover,

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

> definitely doesn't hold your hand)

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

  https://man.openbsd.org/httpd.conf#EXAMPLES

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

  https://man.openbsd.org/true

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

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

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

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

Yours,
  Ingo



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

2020-05-18 Thread Ingo Schwarze
Hi Andras,

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

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

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

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

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

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

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

> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/fsck_ffs/SMM.doc/

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

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

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

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

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

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

> For example, I first learnt vi a few years ago, back
> when I was first learning Unix, with these files:
> https://cvsweb.openbsd.org/src/usr.bin/vi/docs/tutorial/

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

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

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

Yours,
  Ingo



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

2020-05-17 Thread Ingo Schwarze
Hi Alex,

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

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

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

Thanks for the suggestion,
  Ingo


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



Re: TOFU/cert pinning in libtls

2020-05-10 Thread Ingo Schwarze
Hi Lucas,

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

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

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

For example, as tedu@ pointed out:

   $ man -k Xr=tls_conn_version | sed 's/,.*//'
  tls_config_verify
  tls_init
  tls_ocsp_process_response
  tls_read

It would be theoretically possible to do this:

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

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

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

without having to explain a special case for Xr.

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

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

Also, this is Unix, you can use pipes:

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

Re: one-character expansion in shell

2020-05-07 Thread Ingo Schwarze
Hi Philipp,

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

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

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

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

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

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

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

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

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

This is also fairly explicit:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yours,
  Ingo



Re: support

2020-05-07 Thread Ingo Schwarze
Hi,

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

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

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

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

  https://blog.cpettington.com/blog/setups

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

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

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

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

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

Yours,
  Ingo



Re: one-character expansion in shell

2020-05-06 Thread Ingo Schwarze
Hi Rudolf,

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

> is this an expected behaviour?

Yes, that is expected behaviour.

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

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

> odin$ locale

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

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

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

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

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

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

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

Yours,
  Ingo



Re: pkg_add -u: no such dir

2020-05-05 Thread Ingo Schwarze
Hi,

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

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

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

> doas pkg_add -u 
> https://ftp.OpenBSD.org/pub/OpenBSD/6.7/packages/amd64/: no such dir
> list of applications
> 
> I'm sure someone must have noticed by now.
> Only the directories within https://ftp.OpenBSD.org/pub/OpenBSD/6.7/ 
> give 404 Not found error in a browser.

That's expected.

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

  https://man.openbsd.org/pkg_add.1#snap

Yours,
  Ingo



Re: /bin/sh echo \n

2020-04-26 Thread Ingo Schwarze
Hi,

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

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

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

So Martijn answered this almost exhaustively.

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

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

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

Yours,
  Ingo



Re: More than 16 partitions

2020-04-24 Thread Ingo Schwarze
Hi Strahil,

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

> And who the hell needs more than 16 partitions ?

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

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

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

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

The limitation to 16 partitions definitely feels painful to me.

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

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

Yours,
  Ingo



Re: timegm()

2020-04-24 Thread Ingo Schwarze
Hi Todd,

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

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

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

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

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

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

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

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

Yours,
  Ingo



Re: timegm()

2020-04-22 Thread Ingo Schwarze
Hi,

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

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

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

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

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

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

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

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

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

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

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

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/time/localtime.c?rev=1.1=text/x-cvsweb-markup/

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

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

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

OK?
  Ingo


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



Re: List a package's dependencies

2020-04-20 Thread Ingo Schwarze
Hi Marc,

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

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

Heh.  :-)

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

Those look like good points.

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

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

Yours,
  Ingo



Re: List a package's dependencies

2020-04-19 Thread Ingo Schwarze
Hi Chris,

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Yours,
  Ingo



Re: Does Intel driver supports Intel g31?

2020-04-11 Thread Ingo Schwarze
Hi,

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

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

So far, so good.

> https://openports.se/

But please do not recommend openports.se for use with OpenBSD.

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

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

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

See also:  https://man.openbsd.org/pkg_locate.1

Yours,
  Ingo



Re: Does Intel driver supports 3d acceleration?

2020-04-11 Thread Ingo Schwarze
Hi Otto,

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

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

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

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

Yours,
  Ingo



Re: Nvidia driver for OpenBSD?

2020-04-10 Thread Ingo Schwarze
Hi,

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

>> Subject: Nvidia driver for OpenBSD?

> None exist or are likely to ever exist.

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

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

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

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

Yours,
  Ingo



Re: openbsd.org - certain https URLs downgraded to http in redirection

2020-04-04 Thread Ingo Schwarze
Hi Constantine,

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

> What you say makes no sense

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

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

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

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

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

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

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

Yours,
  Ingo



Re: Contributing to spamd

2020-04-03 Thread Ingo Schwarze
Hi Aisha,

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

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

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

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

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

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

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

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

Yours,
  Ingo



Re: reviewing what is available

2020-04-01 Thread Ingo Schwarze
Hi Luke,

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

>>> have you considered looking at native OpenBSD tools?
>>> https://man.openbsd.org/egre.4

>> Wow! I had no idea about this.

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

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


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

   $ man -s 2 -ak Nm=

then type

   :tNAME

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

  t

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

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

Enjoy,
  Ingo


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



Re: How to test for FORTIFY_SOURCE?

2020-03-20 Thread Ingo Schwarze
Hi Luke,

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

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

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

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

Makes sense, done.

Note that in addition to man.openbsd.org, man.bsd.lv is now also
up and running, but the latter will only contain release manual
pages for a number of systems (including OpenBSD) but not
OpenBSD-current.

Yours,
  Ingo



Re: groups new

2020-03-18 Thread Ingo Schwarze
Hi Jan,

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

> 0
> C Slovenia
> P SI
> T Ljubljana
> F Irregular
> O BSD User Group Slovenia
> I Jan Prunk
> M b...@groups.io
> U https://bsdug.wordpress.com
> N *BSD

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

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

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

Yours,
  Ingo



Re: How to test for FORTIFY_SOURCE?

2020-03-18 Thread Ingo Schwarze
Hi,

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

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

>> To a limited extent, that is true.

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

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

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

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

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

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

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

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

Yours,
  Ingo



Re: How to test for FORTIFY_SOURCE?

2020-03-18 Thread Ingo Schwarze
Hi Jeffrey,

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

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

To a limited extent, that is true.

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

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

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

Yours,
  Ingo



Re: How to test for FORTIFY_SOURCE?

2020-03-18 Thread Ingo Schwarze
Hi Theo,

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

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

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

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

>> It wastes people's time and breaks search. This search does
>> not produce expected results:
>> https://www.google.com/search?q=FORTIFY_SOURCE+site%3Aopenbsd.org.

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

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

> I'm going to stand up and agree.

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

For now, comparing different systems can be done here:

  https://mandoc.bsd.lv/cgi-bin/man.cgi/

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

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

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

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

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

Yours,
  Ingo



Re: Start point to learn OpenBSD programming

2020-03-16 Thread Ingo Schwarze
Hi Martijn,

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

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

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

> Who said I went for simple?

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

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

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

Yours,
  Ingo



Re: Start point to learn OpenBSD programming

2020-03-16 Thread Ingo Schwarze
Hi Martijn,

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

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

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

You forgot two steps:

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

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

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

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

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

That can be simplified:

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

;-)
  Ingo



Re: Confusing problem with CVS

2020-03-13 Thread Ingo Schwarze
Hi Chris,

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

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

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

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

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

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

Yours,
  Ingo



Re: Confusing problem with CVS

2020-03-13 Thread Ingo Schwarze
Hi Chris,

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

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

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

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

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

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

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

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

Yours,
  Ingo



Re: Wikidata:Property proposal

2020-03-05 Thread Ingo Schwarze
Hi,

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

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

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

Yours,
  Ingo



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

2020-03-03 Thread Ingo Schwarze
Hi Marc,

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

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

> it's a bug in the :E command, i reported it there:
> 
> https://github.com/vim/vim/issues/5723
> 
> thank you for spotting it.

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

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

> indeed. you made me like reading C code.

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

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

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

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

After the change:

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

So the slowdown is

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

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

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

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

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

Premature optimization is evil.

Yours,
  Ingo



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

2020-03-02 Thread Ingo Schwarze
Hi Marc,

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

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

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

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

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

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

Yours,
  Ingo



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

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

Re: Web documentation available offline by default?

2020-03-01 Thread Ingo Schwarze
Hi Ottavio,

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

> Warning: beginner here.

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

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

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

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

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

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

Yours,
  Ingo



Re: Web documentation available offline by default?

2020-02-27 Thread Ingo Schwarze
Hi Frank,

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

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

No it isn't.

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

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

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

That would be one simple option, yes.

Yours,
  Ingo



Re: setxkbmap cannot completely set compose key

2020-02-19 Thread Ingo Schwarze
Hi,

Xianwen Chen wrote on Wed, Feb 19, 2020 at 10:37:58AM +:

> I run OpenBSD 6.6 amd64.

I'm trying to reproduce on OpenBSD-current.

> The window manager is fvwm

I'm using that, too.

> with stock configuration.

Well, my configuration is much less bloated than the default (125
rather than 491 lines).  But that shouldn't make a difference.

> I am not able to completely set compose key by
> 
> $ setxkbmap -layout us -variant dvp -option compose:ralt

Just to make sure it worked, could you please show the output of:

   $ setxkbmap -query

> What I meant by *not completely* is that I am able to use _right alt_
> as the compose key on for example Firefox. However, on xterm, I am not
> able to use the compose key.

It certainly works for me.

What exactly do you mean by "not able to use"?
If, while xterm is in focus, you press and relese the compose key,
then press and release the first key, then press and release the
second key, then press and release some latin letter key, what
exactly happens after each step?

Guessing blindly, the problem might be that while firefox finds a font
to display the character, xterm does not.  Or that you have changed
your xterm configuration in some way that disables UTF-8 (it is on
by default).  Can you please retry in xterm with a different character
that can be displayed in xterm out of the box, say U+00E5 LATIN
SMALL LETTER A WITH RING ABOVE?  What happens if you type and release
ralt, then a, then a, then x?

If none of the above lets you solve your problem yet, what does the
following command say:

  $ xterm -report-xres

In an xterm started that way, does the compose key work?
Both with the character you want and with U+00E5 A RING?

Yours,
  Ingo



Re: Unable to kill a python process

2020-02-13 Thread Ingo Schwarze
Hi,

Xianwen Chen wrote on Thu, Feb 13, 2020 at 09:31:45PM +:
> Maurice wrote:

>> you could try kill -1 8926

> Thank you. I just tried it. It did not kill the process.

Small wonder, you already already dropped a nuke on it (-9 = -KILL)
and even that didn't make the zombie go away.

You certainly can't kill a zombie by merely hanging up on it
on the phone (-1 = -HUP ;-).

Yours,
  Ingo



Re: Unable to kill a python process

2020-02-13 Thread Ingo Schwarze
Hi,

Xianwen Chen wrote on Thu, Feb 13, 2020 at 08:10:17PM +:

> I am not able to kill a python process.
> $ pgrep python
> showed a PID of 8926
> However, I am not able to kill the process.
> $ kill -9 8926
> # kill -9 8926
> Running as root did not help.

Sounds like a zombie.  Seriously, i'm not joking.

> How can I kill this process?

You can't, a zombie is already dead.

Here is how i reproduced:

   $ sh
   $ echo $$
  39747
   $ python3
  Python 3.7.6 (default, Jan  1 2020, 13:51:25) 
  [Clang 8.0.1 (tags/RELEASE_801/final)] on openbsd6
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

Now, from a different terminal:

   $ kill -STOP 39747  # Block the reaper. (Seriously, i'm not joking.)
   $ pgrep python
 61181
   $ kill 61181
   $ ps axu -p 61181 
  USER   PID %CPU %MEM VSZ RSS TT STAT STARTEDTIME COMMAND
  schwarze 61181  0.0  0.0   0   0 pb Z-   0:00.00 (python3.7)

The "STAT: Z" tells you it's a zombie.  It is already dead, but
still haunting the operating system.  You cannot kill(2) it; or
more precisely, killing it again won't make it any more dead than
it already is.

(Unless you pierce its heart with a woodden stick.  Sorry, now i was
joking.)

Just let the parent process reap it.  A well-behaved parent process
will do so by wait(2)ing for its children to die.  My earlier -STOP
signal prevented the parent shell from doing its job, so lets allow
that shell to get back to work:

   $ kill -CONT 39747
   $ ps axu -p 61181  
  USER   PID %CPU %MEM VSZ RSS TT STAT STARTEDTIME COMMAND
   $ 

So, now we got rid of the zombie by allowing the parent shell to
reap it.

If the parent process is ill-mannered and does not wait(2) on its
children, just kill the parent.  In that case, the parent deserves
the punishment.

Read the following manual page to understand why dying processes
don't vanish instantly but instead linger around until wait(2)ed
for by their parent:

  https://man.openbsd.org/wait.2

And see this manual page for what parents can do if they do not
need information about dying children:

  https://man.openbsd.org/sigaction.2#SA_NOCLDWAIT

Either way, don't create children if you aren't prepared to handle
the responsibility that comes with them - or you might end up being
haunted by zombies.

Yours,
  Ingo



Re: FreeBSD daemon(8)-like command for OpenBSD

2020-01-31 Thread Ingo Schwarze
Hi Patrick,

Patrick Kristiansen wrote on Fri, Jan 31, 2020 at 10:17:35AM +0100:

> Trying to learn some valuable lessons from our interaction, could you
> give some examples of what you mean by 'simpler approach' in this
> context?

Three examples:

  https://learnbchs.org/

  https://man.openbsd.org/man.cgi  --
  this one written from scratch without any framework

  https://man.openbsd.org/bgplg

> Do you mostly do systems programming?

  https://mandoc.bsd.lv/press.html

and also see my various CV abstracts for BSDCan.

Yours,
  Ingo



Re: FreeBSD daemon(8)-like command for OpenBSD

2020-01-31 Thread Ingo Schwarze
Hi Andrew,

Andrew Easton wrote on Fri, Jan 31, 2020 at 11:39:45AM +0100:

> In the spirit of not demanding to much time from my contemporaries I
> am especially greatful for pointers to conceptual documentation

This is the closest thing, i guess:

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

In general, to save time, the OpenBSD projects maintains only concise
reference documentation, not introductory documents or tutorials.

> and to implementation documentation.

For the kernel in general, see section 9 in man(1).

For userland programs, implementation documentation does not exist
in general, though there are are a few rare exceptions, see for
example the manual pages "For programmers:" listed
on https://mandoc.bsd.lv/ and some very rare text files scattered
around the source tree - but be careful, some of these can be
seriously outdated.

In general, our recommendation is RTFS (read the fantastic source
code).

Specifically, i'm not convinced that implementation documentation
exists for pledge(2) or unveil(2), but i may have missed something.

> [[ I have the suspicion that being a good programmer crucially depends
> on having conceptual understanding. Maybe it also depends on practice.]]

Many of us develop their conceptual understanding from reading source
code and from practice.

> Concretely:
> Just to start off easy, how can I find conceptual documentation on
> what an operating system "process" is in OpenBSD

While various details about how the kernel manages processes are no
doubt OS-specific, the conceptual ideas are probably more or less
common to all Unix implementations.  For the basics, standard text
books may be useful, as found on https://www.openbsd.org/books.html ,
for example Kirk's classic "Design and Implementation of the 4.4BSD
Operating System".

> and how deeply a libc
> is tied into that by design? As far as I am aware a process has the
> "current working directory" associated with it, in order to be able to
> resolve relative paths and is also where "environment variables" are
> stored.  These remind me of dynamic bindings, at least in spirit. I am
> only aware of plain C having lexical bindings, in contrast to this.

For such details, our recommendation generally is "read the source".

Start from the section 2 and 3 manual pages of the functions you
are interested in.  Then, if you need more details about how it's
implemented, read the libc code.  Then, if you need even more
details, read the code handling the syscalls in the kernel, of
those syscalls that are used in the libc implementation.

As opposed to the mess you are maybe used to from glibc, OpenBSD
code is generally very concise and readable.

Yours,
  Ingo



Re: FreeBSD daemon(8)-like command for OpenBSD

2020-01-30 Thread Ingo Schwarze
Hi Patrick,

Patrick Kristiansen wrote on Thu, Jan 30, 2020 at 10:23:52PM +0100:
> On Thu, Jan 30, 2020, at 21:10, Ingo Schwarze wrote:
>> Patrick Kristiansen wrote on Thu, Jan 30, 2020 at 09:05:11PM +0100:

>>> The process I need to run is written in Clojure and thus runs on the
>>> Java Virtual Machine.  Do you have any suggestions on how to best go
>>> about making it "daemon-like"?

>> No, i'm sorry i have no advice on that.  I would certainly not run
>> soemthing like that under any circumstances, on any machine, and even
>> less so on any machine connected to the Internet.

> Out of genuine curiosity, and not to be inflammatory, are you saying
> that running any internet-facing service/process/program is inadvisible
> under all circumstances if not written to the standards of a daemon
> shipping with OpenBSD and with the facilities (pledge, unveil, etc.)
> available in OpenBSD?

No, i didn't intend to say that.

I do think that automatically restarting crashy daemons is a terrible
idea and hence the OpenBSD base system intentionally provides no
support for that.  I also said that i personally doubt the wisdom
of constructing a wrapper to run a program as a daemon that is not
designed as a daemon but simply using stdout and stderr and so on.

But in what you quote above, i tried to be careful to only say
that *I*, personally, would not run a Java Virtual Machine and
cannot provide advice on that.

In general, size and complexity tend to hurt security, but i know
too little about Java to say how relevant that general rule of thumb
is to the question of running a daemon using a Java Virtual Machine.
For example, Perl 5 is also a fairly large and complex system, but
it still supports writing daemons that are secure enough for many
purposes, when used properly - even though i'd probably prefer a
simpler approach when i have a choice.

I believe some Java infrastructure and programs exist in the ports
tree, but i can't help you with that.

Yours,
  Ingo



Re: FreeBSD daemon(8)-like command for OpenBSD

2020-01-30 Thread Ingo Schwarze
Hi Patrick,

Patrick Kristiansen wrote on Thu, Jan 30, 2020 at 09:05:11PM +0100:

> The process I need to run is written in Clojure and thus runs on the
> Java Virtual Machine.  Do you have any suggestions on how to best go
> about making it "daemon-like"?

No, i'm sorry i have no advice on that.  I would certainly not run
soemthing like that under any circumstances, on any machine, and even
less so on any machine connected to the Internet.

Yours,
  Ingo



Re: FreeBSD daemon(8)-like command for OpenBSD

2020-01-30 Thread Ingo Schwarze
Hi Patrick,

Patrick Kristiansen wrote on Tue, Jan 28, 2020 at 09:29:20AM +0100:

> But another use for daemon(8) is for its ability to detach the child
> process from the controlling terminal and furthermore redirect its
> stdout/stderr to syslog. Is there some mechanism to do that from the
> shell? Perhaps a combination of nohup and starting a background job?

That doesn't strike me as a particularly bright idea either.

Properly starting up a daemon process requires several steps,
often involving unveil(2), pledge(2), chroot(2), prviledge
dropping, sometimes fork+exec for privilege separation,
and so on.  Typically, these steps need to be intermixed in
exactly the right order with option parsing, environment
parsing, parsing of configuration files and various kinds
of initialization.

Writing wrappers usually just doesn't work, and it seems doubtful
to me whether daemon(8) is up to what is usually needed.

Some sh(1) code quickly hacked together may be good enough for
testing purposes, but i doubt that you want to use such a hack
for a real daemon that you are planning to run in production on 
the Internet.

Yours,
  Ingo



Re: FreeBSD daemon(8)-like command for OpenBSD

2020-01-27 Thread Ingo Schwarze
Hi Patrick,

Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100:

> Is there something like the FreeBSD daemon(8) command for OpenBSD,
> which can run a process in the background and restart it if it
> crashes?

Absolutely not, we are strongly convinced this is an utterly stupid
idea and a serious security risk.

If a daemon crashes, it has a bug.  Many bugs that cause crashes
are also exploitable.  So if a daemon crashes, you first have to
understand why it crashed, fix or at least mitigate the bug, and
can only restart it afterwards.

Restarting it automatically is an irresponsible thing to do.

If a daemon keeps crashing so frequently that you can only run it
in production with automatic restarts, then running it at all is
irresponsible in the first place.

Yours,
  Ingo



Re: pkg_info(1) man page possible error

2020-01-24 Thread Ingo Schwarze
Hi Andrew,

Andrew Easton wrote on Fri, Jan 24, 2020 at 11:17:20PM +0100:

> I am running OpenBSD in a virtualbox because I am taking a deeper look
> into it.
> 
> I was looking for a list of ports packages

Depending what you really need, try

  $ doas pkg_add portslist
  $ less /usr/local/share/ports-INDEX

  $ doas pkg_add sqlports
  $ sqlite3 /usr/local/share/sqlports

  https://cvsweb.openbsd.org/ports/

> and read the man page pkg_info(1).
> 
> That man page it states, 
> "When browsing through uninstalled packages, running pkg_info -I *.tgz
> will report a summary line for each package [...]"
> 
> Note the capital eye 'I'.
> 
> It says so in the VMs man page as well as at
> https://man.openbsd.org/pkg_info
> (All Sections ; All Architectures ; OpenBSD-current)
> (Timestamp: approx. Fri 24 Jan 2020 10:05:00 PM UTC)
> 
> 
> When I run the command
> 
> # pkg_info -I *.tgz
> 
> I get the result
> 
> Invalid spec: *.tgz
> Invalid spec: *.tgz
> #
> 

Well, that's less a question about pkg_info(1) but more about
the sh(1).  In the https://man.openbsd.org/sh.1#Expansion section,
look for the paragraph beginning with

  After field splitting, the shell matches filename patterns.

So the above command only makes sense in a directory where you
do actually have some packages with file names that match the glob(7)
pattern "*.tgz", for example:

  schwarze@isnote $ cd /usr/ports/packages/amd64/all/
  schwarze@isnote $ ls groff*
  groff-1.22.3p9.tgz  groff-1.22.4p2.tgz  groff-git-1.22.4p3.tgz
  groff-1.22.4.tgzgroff-1.22.4p3.tgz
  schwarze@isnote $ pkg_info -D unsigned -I *.tgz | grep groff
  gpresent-2.3p0.tgz  make presentations with groff and PDF
  gpresent-2.5.tgzmake presentations with groff and PDF
  groff-1.22.3p9.tgz  GNU troff typesetter
  groff-1.22.4.tgzGNU troff typesetter
  groff-1.22.4p2.tgz  GNU troff typesetter
  groff-1.22.4p3.tgz  GNU troff typesetter
  groff-git-1.22.4p3.tgz GNU troff typesetter
  ja-groff-1.10_0.99p2.tgz japanese groff

> If I run 
> # pkg_info -l *.tgz # NOTE the little ell instead of capital eye

Using -l in this way doesn't really make sense.
Look at

  $ man -O tag=l pkg_info  # or
  https://man.openbsd.org/pkg_info.1#l

for what -l does.  You don't want to give "*.tgz" as an option
argument to -l.

> If I run
> # pkg_info -I
> 
> I get the result
> pkg_info: Missing package name(s)
> Usage: <...>

Yes.  It pays off to read manual pages and error messages closely,
at least on OpenBSD.

pkg_info(1) says:

  -I  Show the index entry for each package.

So with -I, you need to say for which package(s) you want to see
index entries.

> Searching for "openbsd pkg_info -I" with duckduckgo

Don't search the web for OpenBSD documentation that way.
Yes, for Linux, it's sometimes hard to get any help without
searching the web indiscriminately.  But for OpenBSD, everything
is supposed to be explained in the manual page of the program
you are trying to use, so look there.

Random stuff from the web is likely to just confuse you even
more.

> What other information can I provide to clarify where the problem lies?
> (It may be the man page, pkg_info, "layer 8" or a combination of these
> three factors.)

The information you provided was pretty good, i hope i could help.

Yours,
  Ingo



Re: less --no-init and multiline $PS1

2020-01-19 Thread Ingo Schwarze
Hi,

Richard Ulmer wrote on Sun, Jan 19, 2020 at 12:44:37PM +0100:

> when using a $PS1, which has more than one line,

I consider multi-line $PS1 bloat that should not be supported,
in particular not when it complicates basic userland programs or
requires additions to their user interfaces.

On those grounds, i suggest to dismiss the patch.

Yours,
  Ingo



Re: Question about "Game of Trees"

2020-01-14 Thread Ingo Schwarze
Hi David,

Raymond, David wrote on Mon, Jan 13, 2020 at 05:37:55PM -0700:

> Quick question: Can got (Game of Trees) be used on an existing git
> repository or does it require a fresh start?

Yes, that is among the chief design goals.

Quoting from http://gameoftrees.org/ :

  It will always remain possible to work with both Got and Git on
  the same repository.

and:

  Git can be used for any functionality which has not yet been
  implemented in Got.

I'm certainly not the only person having git repositories (in my
case, created with git, but you can also use got to create them)
that i'm sometimes using git(1) on and sometimes got(1).  It just
works.

Yours,
  Ingo



Re: Awaiting a diff

2020-01-10 Thread Ingo Schwarze
Hi,

Consus wrote on Fri, Jan 10, 2020 at 12:52:44PM +0300:
> On 20:06 Thu 09 Jan, Marc Espie wrote:

>> It's been that way for ages. But no-one volunteered
>> to work on this.

> Anyone even knows about this? Aside from OpenBSD developers (who
> have their plates full already) how an average person can find out
> that there is rusty piece of code that should be taken care of?

I believe it was said before, but it appears to be easily forgotten:
Maintaining TODO lists consumes time.  For a small system that you do
a lot of work on, the time required for the maintenance of a TODO
list is not prohibitive; that's why

  https://cvsweb.bsd.lv/mandoc/TODO

exists.  But for a large sytem (like OpenBSD as a whole), maintaining
a high-quality TODO list is much harder, in particular for a person
who doesn't know the details of all the parts inside out.  And those
few developers who do know (almost) all the parts inside out are
those who can least afford to take on yet another job.

Besides, the usefulness of public TODO lists is usually vastly
overestimated.  I have some actual data on that.  The above TODO
list concerns the implementation of a POSIX.1 utility that, as of
today, is included and used by default in eight operating systems
(OpenBSD, Alpine Linux, Void Linux, Unleashed, Termux, FreeBSD,
NetBSD, illumos), included by default in two more (DragonFly BSD,
Minix 3) and available as an optional package for ten more (Debian,
Ubuntu, NixOS, Gentoo, Fedora, Arch, Slackware, Crux, openSUSE,
MacOS).  So it does have a substantial user base.  The TODO list
has been available online and continuously maintained for more than
nine years now, since May 2010.  Since October 2013, see below for
a complete list of committed patches that were sent in by developers
other than Kristaps and myself.  The metric that i can easily extract
from this data is contributors times releases: if a contributor
sent patches during multiple release cycles, they are counted
multiple times, but if a contributor sent multiple patches for the
same release (which were never more than a handful from anyone)
that's counted as just one contribution, simply because i don't
have more fine-grained data easily available.

There were 34 such contributions for 11 releases during these six
years, i.e. on average three outside contributors per release or
about five per year.  The vast majority came from developers
already working on other free software projects:

 * 22 from (non-mandoc) OpenBSD developers (that's 65%, btw.!)
 * 3 from FreeBSD developers
 * 1 from NetBSD developers
 * 1 from Debian Linux developers
 * 1 from Void Linux developers
 * 1 from Alpine Linux developers
 * 2 from Crux Linux developers
 * and only 3 from other people

As far as i remember, all of these went like "i noticed this bug,
here is a patch to fix it" or "i had the idea that this feature
addition might be useful, do you like this patch?"  I can't remeber
a single case that went like "i looked at your TODO list and decided
to resolve this item, here is the patch".  Not one in ten years as
far as i can remember.

In conclusion, i'm keeping the TODO list purely for myself.  Myself,
i do regularly look at it and decide to tackle an item to shorten
the list.  The only reason for making it public is such that users
can distinguish between known and unknown issues in case they find
some.  Experience shows that it is neither needed nor indeed useful
for encouraging contributions.

As stsp@ and espie@ already said, that's probably because for people
who are able to contribute, it's easy to find the issues they want
to fix all by themselves, without any help from me.

Yours,
  Ingo


1.12.3 Dec 13 (2)
 * Franco Fichtner for a patch to add a minor missing feature.
 * Tsugutomo ENAMI for a patch to add a minor missing feature.
1.13.1 Aug 14 (0)
1.13.2 Dec 14 (7)
 * Anthony Bentley (OpenBSD), Baptiste Daroussin (FreeBSD), Daniel
   Dickman, Doug Hogan, Jason McIntyre, Theo de Raadt (OpenBSD),
   and Martin Natano (OpenBSD) for source code patches.
1.13.3 Mar 15 (3)
 * Anthony Bentley, Daniel Dickman, and Ted Unangst (OpenBSD)
   for source code patches and bug reports.
1.13.4 Jul 16 (7)
 * Anthony Bentley (OpenBSD) for unifying mandoc.css, two nice
   patches for man.cgi(8), some documentation patches, some bug
   reports, and various useful discussions.
 * Todd Miller (OpenBSD) for lots of help with process group and
   signal handling, a few patches, some bug reports and some useful
   discussions.
 * Svyatoslav Mishyn (Crux Linux) for some patches, several bug
   reports, and extensive release testing.
 * Leah Neukirchen (Void Linux) for a number of compatibility
   patches and suggestions and several bug reports.
 * Christos Zoulas (NetBSD) for a bug fix patch and some useful
   suggestions for cleanup.
 * Florian Obser (OpenBSD) for a bugfix patch and some bug reports.
 * Michael McConville (OpenBSD) for some simple cleanup patches.
1.14.1 Feb 17 (3)
 * Michael Stapelberg 

Re: Awaiting a diff [was: Re: File systems...]

2020-01-09 Thread Ingo Schwarze
Hi Janne,

Janne Johansson wrote on Thu, Jan 09, 2020 at 09:49:43AM +0100:
> Den tors 9 jan. 2020 kl 02:11 skrev Ingo Schwarze :

>> Are you aware that even Bob Beck@ is seriously scared of some
>> parts of our file system code, and of touching some parts of it?
>> Yes, this Bob Beck, who isn't really all that easily scared:
>>
>>   https://www.youtube.com/watch?v=GnBbhXBDmwU
>>
>> One of our most senior developers, regularly and continuously
>> contributing since 1997, and among those who understand our
>> file system code best.

> And here I thought you would post thib@s talk literally named
> "Things that makes Bob scream" from the f2k9/Slackathon conf:
> 
> https://www.youtube.com/watch?v=HTD9Gow1wTU

Cool, i wasn't even aware of thib@'s talk back then.  That was the
very first year i ever took part in a hackathon, and it wasn't that
one.  But yeah, that talk certainly relates to the point i was
trying to make.  Not my area of work really, but as far as i
understand, some things mentioned in the talk have changed a lot,
while others didn't at all, and Bob certainly still has plenty of
opportunity for screaming.  Loudly.  Even though that talk was
certainly hilarious, file systems still aren't a laughing matter.

Thanks for the link,
  Ingo



Re: Awaiting a diff [was: Re: File systems...]

2020-01-08 Thread Ingo Schwarze
Hi Stuart,

Stuart Longland wrote on Thu, Jan 09, 2020 at 09:07:38AM +1000:
> Somebody wrote:

>> - If we could clean-room implement a BSD-licensed
>> EXT3/EXT4/BTRFS/XFS/JFS/whatever, following style(8), would there be
>> interest in supporting that in OpenBSD?

> I'm hoping it will be more than one person assisting in this,
> and yes, I include myself in that group.

schwarze@cvs $ grep -Fi longland /cvs/CVSROOT/ChangeLog*   
schwarze@cvs $

And https://stuartl.longlandclan.id.au/ lists a single free software
project, about 190 commits of Python code, with one single contributor.


I'm sorry that i have to use somewhat strong wording here, i'm
generally trying to help making our lists as friendly as possible,
but in this case, a clear answer is really required.

There is few code that is as difficult as a file system.
There is few code that is as closely entangled with the hardest
parts of there kernel like file system code.
There is few code where touching it is as dangerous as touching
file system code.
There are few areas of the system where people get as upset
when you break it as with file systems.  You literally make people
lose their personal data, and when they realize something went wrong,
it's usually too late, the data is usually already gone for good.

You are certainly welcome to contribute if you want to: start with
sending samll bugfix patches.  Progress to small feature additions
or small cleanup patches in areas that are not too dangerous.
Then grow.  Anything beyond that is impossible to predict.

For a newbie, there is really no point in dreaming about
implementing or changing file systems.

You need to learn what you are capable of and then convince others
of your abilities *by getting good patches committed*.  Idle talk
announcing bizarre dreams doesn't really help anyone.

Are you aware that even Bob Beck@ is seriously scared of some
parts of our file system code, and of touching some parts of it?
Yes, this Bob Beck, who isn't really all that easily scared:

  https://www.youtube.com/watch?v=GnBbhXBDmwU

One of our most senior developers, regularly and continuously
contributing since 1997, and among those who understand our
file system code best.  Most recently, he was among the main
driving forces behind unveil(2).


Becoming able to approximately judge the difficulty and size of
tasks relative to your own abilities is extremely important when
you want to contribute to free software.

Even if you had, let's say, a whole year to spend full-time, you
would not really be making any sense right now.  So, could we drop
this thread, please?

Yours,
  Ingo



Re: Openrsync manpage - EXAMPLES and SEE ALSO

2020-01-04 Thread Ingo Schwarze
Hello Aham,

Aham Brahmasmi wrote on Wed, Jan 01, 2020 at 02:27:59PM +0100:

> I was under the (now incorrect) impression that the rsync{d}.5 links
> were related to configuration files for rsync{d}, hence my query. I now
> understand that they are rsync protocol descriptions.

No one provided an opinion whether the protocol manuals are accurate
and worth installing, so i simply deleted the two .Xrs for now,
see the commit below.

Thanks for reporting the dead links,
  Ingo


CVSROOT:/cvs
Module name:src
Changes by: schwa...@cvs.openbsd.org2020/01/04 04:53:53

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

Log message:
Delete .Xrs to rsync(5) and rsyncd(5).
If somebody wants to install these two manual pages describing the
protocols, it is easy to put these two links back.
Dead links reported by .
OK jmc@ florian@


Index: rsync.1
===
RCS file: /cvs/src/usr.bin/rsync/rsync.1,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- rsync.1 9 Aug 2019 05:28:01 -   1.19
+++ rsync.1 4 Jan 2020 11:53:53 -   1.20
@@ -1,4 +1,4 @@
-.\"$OpenBSD: rsync.1,v 1.19 2019/08/09 05:28:01 claudio Exp $
+.\"$OpenBSD: rsync.1,v 1.20 2020/01/04 11:53:53 schwarze Exp $
 .\"
 .\" Copyright (c) 2019 Kristaps Dzonsons 
 .\"
@@ -14,7 +14,7 @@
 .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 .\"
-.Dd $Mdocdate: August 9 2019 $
+.Dd $Mdocdate: January 4 2020 $
 .Dt OPENRSYNC 1
 .Os
 .Sh NAME
@@ -252,9 +252,7 @@
 .Dl % rsync -t bar baz ../dest
 .\" .Sh DIAGNOSTICS
 .Sh SEE ALSO
-.Xr ssh 1 ,
-.Xr rsync 5 ,
-.Xr rsyncd 5
+.Xr ssh 1
 .Sh STANDARDS
 .Nm
 is compatible with rsync protocol version 27



Re: Going back to release from current installation p

2019-12-30 Thread Ingo Schwarze
Hi,

n...@web.de wrote on Sun, Dec 29, 2019 at 08:40:40PM +0100:

> thanks for your answers.  There is not really such big of a problem
> with going back to -current.

Usually, downgrading an OpenBSD installation simply doesn't work at all.
As you saw, it typically breaks in one way or another, so don't do it.

> There just seems to be a bug with the current version of rspamd's
> milter.

When you see a bug in -current, going back to -stable is never a good
idea.  Instead, help to identify the bug and get it fixed.  That's the
whole point of running -current, after all.

> Where it bounces alot of messages "warning: milter
> unix:public/rspamd_proxy.sock: can't read SMFIC_BODYEOB reply packet
> header: Undefined error: 0".
> This problem seems to only exist with the package in current and not
> in release.

The maintainer of the mail/rspamd port is likely to overlook this
report in this thread (given that it is on misc@ and given the
Subject:).  Besides, this report is extremely brief, i'm not
convinced it contains sufficient information to understand the
problem.  But since i don't use spamd, i'm not sure.

The latest commit to the mail/rspamd port was on 2019/12/29 21:35:02.
Make sure you have a package built with that commit, and if the
problem persists, post a report to ports@ with as much detail as
you can.  You may also Cc: the maintainer in case of regressions,
in this case sthen@.

Yours,
  Ingo



Re: Going back to release from current installation p

2019-12-29 Thread Ingo Schwarze
Hi,

n...@web.de wrote on Sun, Dec 29, 2019 at 10:41:47AM +0100:

> I have done the mistake to go back to release from current.
> I thought I'd just reinstall installed packages.
> But it doesn't work that way.
> I do receive error messages like the following for rspamd:
> 
> pkg_add: Unknown element: @so lib/rspamd/librspamd-actrie.so
> in /var/db/pkg/rspamd-2.2/+CONTENTS,
> 
> This error message is the response to me doing: "pkg_add -r".
> 
> The same happens on deletion. Is there a way to fix this ?

None of this is supported, but if you simply upgrade to the newest
-current snapshot using the normal process, then run "pkg_add -u"
after that, your machine will likely be back in working order.
That may not always work, but i see no particular reason why it
should break at the current point in time.

If it is a mission-critical machine where errors might have dire
consequences, if there is a risk that you damaged more than you
said here, or if you simply want to make really sure all is fine,
simply follow the supported and recommended process and reinstall
from scratch.

Yours,
  Ingo



mdoc(7) syntax and semantics, was: axe(4) ...

2019-12-25 Thread Ingo Schwarze
Hi,

zeurk...@volny.cz wrote on Wed, Dec 25, 2019 at 08:48:36AM +0100:
> "Ingo Schwarze"  wrote:

>> The arguments of .Vt almost never need quoting, not even if there
>> are other macros before or after it on the same input line.

> *shrugs* To me, there is a real difference between "struct blaat" and
> "struct" "blaat" (the latter would imply two separate types), but
> obviously YMDV :)

If you want to get technically pedantic, there is a difference
between both on a macro line: the former constitutes one macro
argument, the latter two macro arguments.  But traditionally, most
roff macros just treat every argument as a word, and traditionally,
a text processor like roff just prints consecutive words with a
space in between, no matter the output mode (ASCII, UTF-8, PostScript,
HTML, ...) or the font or markup.  So there is no visible difference
in any output mode, except for macros doing something special, like
.Fa and .Fn inserting commas.

For many macros, the mandoc(1) parser even takes advantage of the
equivalence by joining arguments:

  $ echo '.Em "two words"' | mandoc -mdoc -T tree -O noval
  Em (elem) *1:2
  two words (text) 1:5
  $ echo '.Em two words' | mandoc -mdoc -T tree -O noval
  Em (elem) *1:2
  two words (text) 1:5

Since it doesn't make a significant difference, i didn't spend much
time to make sure this is always done where it could be, for example:

  $ echo '.Vt "two words"' | mandoc -mdoc -T tree -O noval 
  Vt (elem) *1:2
  two words (text) 1:5
  $ echo '.Vt two words' | mandoc -mdoc -T tree -O noval   
  Vt (elem) *1:2
  two (text) 1:5
  words (text) 1:9

So for .Vt, the parser does not currently join arguments, even though
it wouldn't be wrong to do so (consider that two types in practice
cannot appear side by side, *something*, at least punctuation or a
conjunction, will always intervene in practice if it's really two
types and not a type with a qualifier or a keyword+tag type).

But authors are not expected to worry about such subtleties, the
language is supposed to just work.  That .Fa and .Fn do care is a
historic accident that i probably wouldn't repeat when designing
the language from scratch, but fixing it now would cause serious
incompatibility, so we have to live with the quotes for these two.

> In fact, it's an old peeve of mine that even when quoting the arguments,
> the underlining in the output is not applied to the spaces.

Hmm.  Groff implements both word-by-word underlining (.ul) - which
is more common - but also continuous underlining (.cu).  Then again,
the nroff formatter prints "\fI " as just a space, not as an
underlined space, and the mdoc macros implement .Em and similar
macros in terms of \fI for nroff output mode, not in terms of .ul
or .cu.  I don't think we can redefine the rules for groff to
underline spaces after \fI, that would change existing documents
too much, including those that are not manual pages.  So the only
option would be to change the implementation of the mdoc macros to
underline in-word spaces but not spaces between words.  That sounds
complicated and currently, i have no idea how to do that.

It doesn't sound important enough to justify a major rewrite of the
macro set...

>> The usual way to quote punctuation is by prepending a zero-width
>> space, so if you really wanted to talk about a command called ";",
>> you would write: .Ic \&;

> Me'll give that some thought, although me'll already argue that ";" is
> (to me) a little more readable.

You may find it nicer, but it doesn't work:

   $ echo '.Fl x ";"' | mandoc -mdoc
  [...]
  -x;

   $ echo '.Fl x \&;' | mandoc -mdoc 
  [...]
  -x -;

Quoting punctuation with "" only affects argument parsing.  The macro
still sees a bare semicolon and treats it as punctuation, not as text,
like it would when the semicolon were escaped with \&.

>> But such a command would be weirdly named indeed, and appending
>> an internal command to a variable name would make no sense either.

> Well, what do you suggest? Just include C syntax elements as plain text?

Fot syntax elements that are mere punctuation, yes.  Usually,
punctuation is not marked up in mdoc(7), not even when it has a
syntactic meaning in the language being documented.

>> If "scaahp" is a global variable, the best way to mention it is
>> simply
>>
>>  .Vt struct blaat scaahp ;

> Except that scaahp is not a type, not a syntax element, but a variable:
> we have Va for that.

>> as documented in the mdoc(7) manual:
>>
>> https://man.openbsd.org/mdoc.7#Vt_2

> Interesting. It would appear that both and Va and Vt have the capacity
> for conflating type and variable names.

Yes, by historic accident.

> Unless me's seriously mistaken: the whole point of mdoc(7) i

Re: axe(4) success with 'Delock Gigabit USB 2.0 Ethernet Adapter, "ASIX chipset"' (w/ manual patch)

2019-12-24 Thread Ingo Schwarze
Hi,

just FYI:

zeurk...@volny.cz wrote on Tue, Dec 17, 2019 at 08:10:10PM +0100:
> jmc@ wrote:

>> Dq produces "", so use either Dq or "".

> Medoes it for consistency with cases like:
> 
> .Vt "struct blaat" Va scaahp Ns Ic ";"
> 
> where the quotes are part of the invocation syntax.

Not really.

The arguments of .Vt almost never need quoting, not even if there
are other macros before or after it on the same input line.

The usual way to quote punctuation is by prepending a zero-width
space, so if you really wanted to talk about a command called ";",
you would write:   .Ic \&;
But such a command would be weirdly named indeed, and appending
an internal command to a variable name would make no sense either.

If "scaahp" is a global variable, the best way to mention it is
simply

  .Vt struct blaat scaahp ;

as documented in the mdoc(7) manual:

  https://man.openbsd.org/mdoc.7#Vt_2

Note that the trailing semicolon is just punctuation, so it is
actually important to *not* escape or quote it.

The forms

  .Va struct blaat scaahp ;
  .Vt struct blaat Va scaahp ;

are also acceptable albeit less common.
No quoting or escaping either way...


Quoting with "" *is* needed in cases where it matters that two words
are kept together in a single macro argument even though there is
a space character between them in the source:

  .Sh SYNOPSIS
  .Ft double
  .Fn sin "double x"

But that certainly isn't needed for .Vt.  Relatively few macros
care, most prominently .Fa and .Fn.

Yours,
  Ingo



Re: doas(1) adjustable timeout length

2019-12-24 Thread Ingo Schwarze
Hi,

Hiltjo Posthuma wrote on Fri, Dec 20, 2019 at 12:40:14AM +0100:
> On Thu, Dec 19, 2019 at 02:03:19PM -0700, andrej wrote:

>> On the note of accurate documentation; how about adding the actually
>> defined timeout for persist rather than the "some time"?

> Sometimes there is a reason implementation details are not specificly
> documented,

Correct.

> but I don't know if thats the case here.

If i understand correctly, it is.

This option is only provided for convenience in interactive use.
It shouldn't matter for the user what the exact timeout is.
The user will simply enter the password once more when asked.

On the other hand, Ted might decide at some time in the future
that a slightly different timeout yields a better balance of
convenience and security.  When there is no public promise how
long exactly the timeout is, changing it is less disruptive.

So, i'm not convinced we want the patch quoted below.

Yours,
  Ingo


> diff --git usr.bin/doas/doas.conf.5 usr.bin/doas/doas.conf.5
> index b5cacde22cd..b541aef966c 100644
> --- usr.bin/doas/doas.conf.5
> +++ usr.bin/doas/doas.conf.5
> @@ -47,7 +47,7 @@ Options are:
>  The user is not required to enter a password.
>  .It Ic persist
>  After the user successfully authenticates, do not ask for a password
> -again for some time.
> +again for 5 minutes for the session.
>  .It Ic keepenv
>  Environment variables other than those listed in
>  .Xr doas 1



Re: Readv and writev failing across ethernet

2019-12-24 Thread Ingo Schwarze
Hi Theo,

Theo de Raadt wrote on Mon, Dec 23, 2019 at 11:11:41AM -0700:
> Ingo Schwarze  wrote:

>> +.Pp
>> +The driver of the device that is being read from
>> +may return additional errors.
>> +Such device-specific errors may be documented
>> +in the section 4 manual pages of the respective drivers.

> I'm unhappy with the wording "the driver of the device".  It is overly
> precise and inaccurate.  Additional errors may come from drivers, but
> also from subsystems like netinet, net, scsi, etc.  So neither driver
> nor device applies -- additional errors can percolate upwards from a
> vast list of underlying code.

I see.  So we should refrain from trying to list sources of errors.

> I also worry that programmers won't know what action to take for
> specific errors.  Some may feel they must expect all error values and
> handle them in different ways (some to be ignored, others as fatal).
> What is the correct strategy for handling potentially arbitrary errors?

A good rule of thumb is: treat unexpected errors in the same way as the
most severe errors that are expected.  Usually, that doesn't require
additional code, and i expect that in most cases, it will be a secure
course of action.  (Though in exceptional cases, it may be better to
treat unexpected errors as even worse than the most serious expected
errors, but that can only be decided on a case-by-case basis.)

> This text is leading people to expect anything, that this is the new
> normal, and it is worrisome.

That conclusion from that argument would be to avoid explicitly
drawing attention to the fact that additional errors can occur
and simply use a wording that can less easily be misconstrued as
introducing a complete list.

Even without saying "additional errors may occur", programmers will
usually (hopefully) expect that because experience teaches that
most listings of error conditions in documentation are not exhaustive,
in particular when they don't expliciutly claim to be exhaustive.

> It is sad that so many extra errnos have been exposed over the years.
> 
> Many low-level errors should have been abstracted into existing
> higher-level catagories, if the effect and disposition are the same, then
> map the internal condition to the same errno.
> 
> Or the low-level error should not exist in the first place, the lower
> level code is simply being sloppy, and the abstraction is incomplete.

I agree that proliferation of error codes can be distracting,
confusing, and annoying, but with the above rule of thumb, the
practical problem is usually manageable.

So, here is a proposal to merely avoid explicitly claiming completeness
for system calls that take file descriptors (using the hint from
guenther@ that this is a useful criterion).

The second chunk in read.2 merely removes a gratuitious and potentially
confusing wording difference.

Yours,
  Ingo


Index: read.2
===
RCS file: /cvs/src/lib/libc/sys/read.2,v
retrieving revision 1.36
diff -u -r1.36 read.2
--- read.2  30 Sep 2016 10:53:11 -  1.36
+++ read.2  24 Dec 2019 13:28:29 -
@@ -143,7 +143,7 @@
 .Fn pread ,
 and
 .Fn preadv
-will succeed unless:
+will fail if:
 .Bl -tag -width Er
 .It Bq Er EBADF
 .Fa d
@@ -210,7 +210,7 @@
 .Fn readv
 and
 .Fn preadv
-may return one of the following errors:
+may return the following errors:
 .Bl -tag -width Er
 .It Bq Er EINVAL
 .Fa iovcnt
Index: symlink.2
===
RCS file: /cvs/src/lib/libc/sys/symlink.2,v
retrieving revision 1.20
diff -u -r1.20 symlink.2
--- symlink.2   10 Sep 2015 17:55:21 -  1.20
+++ symlink.2   24 Dec 2019 13:28:30 -
@@ -87,7 +87,7 @@
 .Sh RETURN VALUES
 .Rv -std
 .Sh ERRORS
-The symbolic link succeeds unless:
+The symbolic link will fail if:
 .Bl -tag -width Er
 .It Bq Er ENOTDIR
 A component of the
Index: truncate.2
===
RCS file: /cvs/src/lib/libc/sys/truncate.2,v
retrieving revision 1.19
diff -u -r1.19 truncate.2
--- truncate.2  28 Feb 2016 14:38:25 -  1.19
+++ truncate.2  24 Dec 2019 13:28:30 -
@@ -64,7 +64,7 @@
 .Fn truncate
 and
 .Fn ftruncate
-will succeed unless:
+will fail if:
 .Bl -tag -width Er
 .It Bq Er EINVAL
 The



Re: Readv and writev failing across ethernet

2019-12-23 Thread Ingo Schwarze
Hi,

Theo de Raadt wrote on Sun, Dec 22, 2019 at 05:34:45PM -0700:
> Philip Guenther  wrote:
>> Somebody wrote:

>>> The man pages for readv and writev don't document the possibility of
>>> such errors.

>> IMO, weird errnos from devices should be documented in the manpage for the
>> device.  Consider the termios(4) manpage, for example.

> I agree on that.  Otherwise the information-flood is too much.
> 
> But I think some of our manual pages are a bit weak indicating there
> are other errors not listed:

Is the following good enough?

Or are you saying that *all* section 2 and 3 manual pages should be
reworded to say:  "FOOBAR may for example fail if:"?

Yours,
  Ingo


Index: read.2
===
RCS file: /cvs/src/lib/libc/sys/read.2,v
retrieving revision 1.36
diff -u -r1.36 read.2
--- read.2  30 Sep 2016 10:53:11 -  1.36
+++ read.2  23 Dec 2019 13:58:41 -
@@ -228,6 +228,11 @@
 .Fa iov
 points outside the process's allocated address space.
 .El
+.Pp
+The driver of the device that is being read from
+may return additional errors.
+Such device-specific errors may be documented
+in the section 4 manual pages of the respective drivers.
 .Sh SEE ALSO
 .Xr dup 2 ,
 .Xr fcntl 2 ,
Index: write.2
===
RCS file: /cvs/src/lib/libc/sys/write.2,v
retrieving revision 1.42
diff -u -r1.42 write.2
--- write.2 6 Sep 2019 19:25:08 -   1.42
+++ write.2 23 Dec 2019 13:58:41 -
@@ -286,6 +286,11 @@
 .It Bq Er ENOBUFS
 The system lacked sufficient buffer space or a queue was full.
 .El
+.Pp
+The driver of the device that is being written to
+may return additional errors.
+Such device-specific errors may be documented
+in the section 4 manual pages of the respective drivers.
 .Sh SEE ALSO
 .Xr fcntl 2 ,
 .Xr lseek 2 ,



Re: What do you use to generate invoices on OpenBSD?

2019-12-21 Thread Ingo Schwarze
Hi Mikolaj,

Mikolaj Kucharski wrote on Sat, Dec 21, 2019 at 11:57:07PM +:

> Do you generate invoices on OpenBSD?

Yes.

> What do you recommend? If you have
> experience in more than one app, why did you chose one over the other?
> If you use something open-source on other OS, let me know as well. If
> you use some own written app, for generating invoices, I'm also
> interested to hear, just to get an idea, which way people decide to go.

I use print/texlive with \documentclass{dinbrief}.  KISS.

The textproc/groff port would work just as well, except that i'm
not sure there is an equivalent to the dinbrief class, so one
would have to set dimensions and spacing manually or with private
macros.

Yours,
  Ingo



Re: Openrsync manpage - EXAMPLES and SEE ALSO

2019-12-09 Thread Ingo Schwarze
Namaste Aham,

Aham Brahmasmi wrote on Mon, Dec 09, 2019 at 04:55:07PM +0100:

> On the openrsync manpage [1],
> [1] - https://man.openbsd.org/openrsync
> 1) In the EXAMPLES section, the examples use "rsync".
> ...
> % rsync -t ../src/bar ../src/baz host:dest
> ...
> The SYNOPSIS section has the invocation as "openrsync".
> 
> Should we use "openrsync" in the EXAMPLES section?

I don't think so.

Ultimately, we hope to install OpenRSYNC as simply /usr/bin/rsync
rather than /usr/bin/openrsync, but it isn't quite ready for that
yet, too many features are still missing.

Until then, it can't be helped that the documentation is somewhat
messy.  In particular, we don't really want to force "openrsync"
too deeply into people's finger memory.

> 2) In the SEE ALSO section, clicking on rsync(5) and rsyncd(5) results
> in "No results found". An apropos [2] for "rsync" gives two results, one
> of which is for openrsync itself.

Our source tree contains files rsync.5 and rsyncd.5 documenting the
protocols, but they are not installed.  I think we should either
install these two files if they are accurate and considered relevant
or delete the two links from rsync(1).

I'm not sending a diff because i don't know which course of action
is better.

> Is there a configuration file format for rsync{d}?

Samba rsync supports rsyncd.conf(5) but OpenRSYNC does not appear
to at this time.

Yours,
  Ingo



Re: groups update

2019-12-09 Thread Ingo Schwarze
Hello,

please ignore this submission.

The content is wrong: no such group exists in Qazvin,
and the email address given on "M" line bounces.

Besides, the email is a forgery and did not originate
from the person given in the From: header.

Yours,
  Ingo


Faraz Vahedi wrote on Sun, Dec 08, 2019 at 09:43:15PM -0500:

> 0
> C Iran
> P Qazvin
> T Qazvin
> F Last Thursday of the month
> O Qazvin BSD User Group (QBUG)
> I Farid
> M qaz...@irbug.org
> U https://www.irbug.org
> N *BSD



Re: Using unveil(2) to block the entire file system

2019-12-05 Thread Ingo Schwarze
Hi Chris,

i just committed the patch shown below;
thanks for bringing up the point.

Yours,
  Ingo



CVSROOT:/cvs
Module name:src
Changes by: schwa...@cvs.openbsd.org2019/12/05 17:14:08

Modified files:
lib/libc/sys   : unveil.2 

Log message:
Explicitly say that *permissions can be "".

Potential for misunderstanding noticed by Chris Rawnsley , wording proposed by deraadt@, patch sent by Chris
Rawnsley, OK deraadt@.


Chris Rawnsley wrote on Wed, Dec 04, 2019 at 06:34:00PM +:

> Index: lib/libc/sys/unveil.2
> ===
> RCS file: /cvs/src/lib/libc/sys/unveil.2,v
> retrieving revision 1.19
> diff -u -p -u -r1.19 unveil.2
> --- lib/libc/sys/unveil.2 25 Jul 2019 13:47:40 -  1.19
> +++ lib/libc/sys/unveil.2 4 Dec 2019 18:28:03 -
> @@ -62,7 +62,8 @@ promise.
>  .Pp
>  The
>  .Fa permissions
> -argument points to a string consisting of the following characters:
> +argument points to a string consisting of zero or more of the following
> +characters:
>  .Pp
>  .Bl -tag -width "" -offset indent -compact
>  .It Cm r



Re: Using unveil(2) to block the entire file system

2019-12-05 Thread Ingo Schwarze
Hi,

i like the tweak; OK to commit?

While it is reasonable to expect this behaviour without the "zero
or more", i see how the misunderstanding "one or more" can arise:
In many situations, to grant no permissions on a given path, it is
sufficient to not mention it in unveil(2) at all, so it may not be
obvious to everybody that the "" case is sometimes useful (and
implemented).

Yours,
  Ingo


Chris Rawnsley wrote on Wed, Dec 04, 2019 at 06:34:00PM +:
> On Wed, 4 Dec 2019, at 18:07, Theo de Raadt wrote:

>> I think it is implied, if no permissions are listed.

> Perhaps and it may be due my inexperience with C interfaces that I didn't
> think to try it.
> 
> I think your wording would have been enough for me to twig so I've made
> the patch for that instances too (if you change your mind, of course :) ).
> 
> Index: lib/libc/sys/unveil.2
> ===
> RCS file: /cvs/src/lib/libc/sys/unveil.2,v
> retrieving revision 1.19
> diff -u -p -u -r1.19 unveil.2
> --- lib/libc/sys/unveil.2 25 Jul 2019 13:47:40 -  1.19
> +++ lib/libc/sys/unveil.2 4 Dec 2019 18:28:03 -
> @@ -62,7 +62,8 @@ promise.
>  .Pp
>  The
>  .Fa permissions
> -argument points to a string consisting of the following characters:
> +argument points to a string consisting of zero or more of the following
> +characters:
>  .Pp
>  .Bl -tag -width "" -offset indent -compact
>  .It Cm r



  1   2   3   4   5   6   7   8   9   >