Re: openvpn with ed25519 ca cert

[Theo Buehler]

On Sun, Apr 21, 2024 at 02:34:48PM +0200, Peter Wens wrote:
> Hi,
> 
> Does libressl 3.9.0 on 7.5 lacks support for ed25519 certs
> using tls 1.3?

Yes, it's not currently supported. Adding support for that isn't hard,
but hasn't been done.

Re: Libressl verify failure with 3.9.0

['Theo Buehler']

On Mon, Apr 08, 2024 at 05:53:47PM -0500, Ted Wynnychenko wrote:
> Thanks for the suggestion.
> The workaround does work, and creates (essentially) the same certificate,
> but one that does not fail verification with the new libressl.
> I did notice the option of not have the leading "20" for dates before 2050,
> but I did not know enough to try doing that.

Great. openssl ca should be smart enough to do that for you.  It tried
to, but failed due to a bug. This will be fixed in the next release:

https://github.com/openbsd/src/commit/72c7c57a68e32c57ac752161b5a93464ad11e7e1

The incomprehensible verification error is another bug and that will
also be fixed.

Re: Libressl verify failure with 3.9.0

[Theo Buehler]

On Sun, Apr 07, 2024 at 04:57:24PM -0500, Ted Wynnychenko wrote:
> Hello,
> 
> I recently updated to -current (about a week ago).
> 
> I see that Libressl is at 3.9.1 just now, but I hope that won't be an issue 
> (I did not see anything in the release notes that would impact my question).
> ---
> $ openssl version
> LibreSSL 3.9.0
> ---
> 
> Over the years, I have made certificates for personal servers/resources on 
> my home network.  This is just for me, so I do some things that would be 
> frowned on (although, technically, there is nothing "wrong" with them).
> 
> In this case, since I have Apple iOS devices that I want to connect to 
> https, I backdate any certificates I create to 1/2/2019.  Apple has imposed 
> a 300 or 800 day time limit on the validity for certificates created after 
> (about) 7/1/2019.  Since I don't want to constantly make new certificates 
> for my personal/home network, I have just been setting the certificates' 
> "not before" date to early 2019.
> 
> Anyway, this had worked fine.
> In fact, earlier this year (Jan 2024), I created a new certificate, and all 
> is good.
> 
> A few weeks ago, I added a new thing to the network - a raspberry pi (I got 
> as a gift about 2013 and installed a linux image from 2019 on it) that is 
> connected to the home alarm system.
> 
> Since I was annoyed that my browser was constantly giving me self-signed 
> certificate warnings, I decided to make a certificate for the nginx running 
> on this appliance.
> 
> I created a key, made a csr, and then signed it with:
> openssl ca -startdate 2019010200Z -in pi.csr -out pi.pem -config 
> /etc/ssl/openssl.cnf

As a workaround, try using '-startdate 19010200Z' instead. I think
this is fallout from this commit:

https://github.com/openbsd/src/commit/3feee4c53fbd67a4a480080d8ef5ae835d3fbf82

ASN1_TIME_set_string_X509() is documented as

 In LibreSSL, ASN1_TIME_set_string() and ASN1_TIME_set_string_X509()
 behave identically and always set the time object to a valid value to use
 in an X.509 certificate.

It seems to me that this is just wrong (it is true that both behave
identically because RFC5280 is defined to 0), but they do not set the
time object to "a valid value to use in an X.509 certificate".

Confusingly, ASN1_TIME_adj_internal() actually honours its RFC5280
parameter by behaving the expected way whereas its meaning in
ASN1_TIME_set_string_internal() is different.

I am unsure if the bug is in my commit above or in our version of
ASN1_TIME_set_string_X509() (or both).

> 
> This all works fine, and a certificate is created
> 
> When I check with:
> openssl x509 -text -noout -in pi.pem
> 
> everything seems as expected, including the not before/after dates:
> 
> Validity
> Not Before: Jan  2 00:00:00 2019 GMT
> Not After : Apr  7 15:39:59 2054 GMT
> 
> (yes, it is valid for 35 years - as I said before, if someone breaks into my 
> house to secretly do things, I have way bigger problems)
> 
> But, if I try to verify this on the openbsd system, I get:
> 
> # openssl verify pi.pem
> C = US, ST = Illinois, L = ***, O = ***, OU = ***, CN = ***
> error 20 at 0 depth lookup:unable to get local issuer certificate
> pi.pem: verification failed: 20 (unable to get local issuer certificate)
> ---
> 
> But, if I install this on the raspberry pi, which has a much older version 
> of openssl on it:
> $ openssl version
> OpenSSL 1.1.1c  28 May 2019
> 
> The certificate verifies without an issue:
> $ openssl verify pi.pem
> pi.pem: OK
> 
> The last time I created a certificate was in January of this year 
> (1/22/2024).
> I am thinking the openbsd system was using Libressl 3.8.2 at that point.
> 
> I created that certificate in the exact same way, backdating the start date:
> openssl ca -startdate 2019010200Z -in 54.csr -out 54.pem -config 
> /etc/ssl/openssl.cnf
> 
> This previously created certificate also has them same backdated and very 
> long valid period:
> 
> Validity
> Not Before: Jan  2 00:00:00 2019 GMT
> Not After : Jan 21 23:49:22 2054 GMT
> 
> (Notice the not after date is a little different)
> Today, with the new libressl, this certificate verifies OK.
> 
> $ openssl verify 54.pem
> 54.pem: OK
> 
> Finally, if I create the new certificate WITHOUT backdating it
> e.g.:  openssl ca -in pi.csr -out pi.pem -config /etc/ssl/openssl.cnf
> 
> The certificate is created and verifies OK.
> 
> So, it seems, there is some sort of issue with backdating the certificate, 
> but not an issue with the crazy long validity window, that was not present 
> in January of this year.
> 
> However, as I said, if I don't backdate, then in about a year the ipad will 
> refuse to connect because of the restrictions apple has imposed, unless I 
> update the certificate.
> 
> I know this is not "best practice," but it should still work, right?
> 
> Is there something I am missing?
> Otherwise, it appears something has changed in 

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

[Theo Buehler]

On Sun, Dec 24, 2023 at 05:25:55AM -0800, Paul Pace wrote:
> I have this vague memory of reading someone who posted a script, IIRC, to
> convert the system's man pages to HTML, or similar, into somewhere under
> /var/www and the pages worked just like the highly useful man.openbsd.org,
> and not like the plain text pages that everyone always posts to their
> websites.
> 
> Does someone happen to know where that is?

Not a script, but there are instructions in the lower half of
usr.bin/mandoc/Makefile and you can read the man.cgi manual with
$ mandoc -a usr.bin/mandoc/man.cgi.8

https://github.com/openbsd/src/blob/master/usr.bin/mandoc/Makefile#L43-L77

Re: Regression (or misconfig on my side?) after OpenOSPFd upgrade (OpenBSD 7.3 -> 7.4)

[Theo Buehler]

On Tue, Nov 07, 2023 at 10:59:48AM +0100, Claudio Jeker wrote:
> On Tue, Nov 07, 2023 at 08:21:16AM +0100, Laurent CARON wrote:
> > Hi,
> > 
> > After upgrading a 7.3 to 7.4 OpenBSD box, I noticed OSPF adjacencies using a
> > password are not coming up with the following in /var/log/messages:
> > 
> > ospfd[55040]: recv_packet: authentication error, neighbor ID X.X.X.X
> > interface vlanXX
> > 
> > After removing the authentication, I was able to get adjacencies to come up.
> > 
> > Config contains:
> > 
> > password=""
> > auth-key $password
> > auth-type simple
> > 
> > This config was working perfectly fine until OpenBSD 7.3 but fails with 7.4
> > 
> > The 'only' way I found to have it working is to get rid of authentication.
> > 
> 
> Ugh. My bad. I forgot that iface->auth_key is not really a string. So the
> code setting the auth_key would copy too much if you use a password with 8
> chars. Using a password with 7 or less chars works fine.
> 
> As a result of this overflow the checksum calculation in auth_validate
> fails and that's what you see.
> 
> Diff below should fix this.

ok tb

> -- 
> :wq Claudio
> 
> Index: auth.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/auth.c,v
> diff -u -p -r1.22 auth.c
> --- auth.c3 Jul 2023 09:40:47 -   1.22
> +++ auth.c7 Nov 2023 09:56:44 -
> @@ -166,7 +166,8 @@ auth_gen(struct ibuf *buf, struct iface 
>   fatalx("auth_gen: ibuf_set failed");
>  
>   if (ibuf_set(buf, offsetof(struct ospf_hdr, auth_key),
> - iface->auth_key, strlen(iface->auth_key)) == -1)
> + iface->auth_key, strnlen(iface->auth_key,
> + sizeof(iface->auth_key))) == -1)
>   fatalx("auth_gen: ibuf_set failed");
>   break;
>   case AUTH_CRYPT:
> 

Re: SSL issues after upgrading from 7.3 to 7.4

[Theo Buehler]

On Sat, Oct 21, 2023 at 09:23:51AM +0300, Mark wrote:
> So, no idea on this?

No. OCSP does work for me on 7.4 when enabled, both with httpd and nginx.
With nginx, you need to have accessed the page at least once so it
fetches and caches the staple and that may depend on the per worker
process.

I see no fundamental issues in my testing and this was confirmed
independently by others who have various setups with various CAs.

For example doing

$ nc -cvz www.openbsd.org 443

will show good OCSP stapling. Similar with

$ openssl s_client -status -connect www.openbsd.org:443

on several OS with various openssl variants. So there are no SSL issues
per se.

> There are people having similar SSL issues (have been reading about them in
> IRC channels)

I take your word for it. No actionable bug report reached the relevant
mailing lists.

A minimal, known working configuration with 7.3 that stops working with
7.4 will probably help.

Re: ldd error with setuid/setgid binaries

[Theo Buehler]

On Thu, Oct 19, 2023 at 01:39:00AM +0900, Yoshihiro Kawamata wrote:
> From: Marc Espie 
> Subject: Re: ldd error with setuid/setgid binaries
> Date: Wed, 18 Oct 2023 18:04:45 +0200
> 
> > objdump -p
> > will be as good.
> > 
> > Yes, it does not recurse, but it doesn't need to, since you also
> > want to wipe libraries that link with old libraries.
> 
> This seems to be easier to parse in a shell script than "readelf -d".

If you need recursion you may want to try lddtree from devel/pax-utils.

Re: Syspatch https://cdn.openbsd.org/pub/OpenBSD

[Theo Buehler]

On Wed, Jul 12, 2023 at 09:10:20PM -0600, Duncan Patton a Campbell wrote:
> I'm just looking at 
> http://www.openbsd.org/errata71.html
> (see attached PNG)
> 
> and it's missing the last 8 entries 
> (029_expat.patch thru 036_rpki.patch)

That sounds like 6.9:

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

Re: can't create csr with ed 25519 on libressl 3.7.2 / OpenBSD 7.3

[Theo Buehler]

On Wed, Jun 14, 2023 at 03:30:10PM +0300, S V wrote:
> can somebody explain why this doesn't work

Yes. The answer to this kind of question is always the same: somebody
has to write some code to support it. What is supported in 3.7.2 is the
cryptographic primitive. More plumbing has to be added for libssl and
the openssl app.

> or how to fix it ?

Write said code

> Same commands work on openssl on another computers/OS and they basically in
> every tutorial related to ed25519 generation

or use those alternatives.

Re: After update, vim reports undefined symbols in libruby32.so

[Theo Buehler]

On Sun, Jun 11, 2023 at 07:22:28PM +0200, Why 42? The lists account. wrote:
> vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_Backtrace'
> vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_GetIP'
> vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_GetCFA'
...

That's because libruby32 did not link explicitly against libc++abi, which
is now needed on aarch64 and amd64 for the Rust-based YJIT compiler.

Fixed in this commit: 
https://marc.info/?l=openbsd-ports-cvs=168663240314909=2

Once you get ruby-3.2.2p0 on your machine either by updating after it
made it into snapshot packages or by building the latest lang/ruby/3.2
yourself, this noise should go away.

Re: Intermittent certificate error on web clients using Chrome

[Theo Buehler]

On Mon, Apr 17, 2023 at 12:29:31PM -0600, Jeff Ross wrote:
> This is only tangentially related to OpenBSD...

It is related because it is a combination of how LibreSSL handles TLS
extension calbacks with how apache2 chose to redirect requests to
virtual hosts based on the server name indication. This now manifestes
itself because chrome started rolling out an anti-fingerprinting and
bug-finding feature that involves randomizing the order of TLS
extensions. They started rolling out this feature on Windows and add it
to more platforms over time, which likely explains why that issue now
shows up on some android phones as well.

One part of the problem is that LibreSSL calls callbacks directly on
reading an extension so that the (undocumented) order in which callbacks
are called depends on the order in which TLS extensions are sent.

The other part is that apache2 depends on having information from the
SNI available when the ALPN callback is called. So if the ALPN extension
precedes the SNI, the request will fail, otherwise it works as expected.

To my knowledge this manifests itself only with virtual hosts in
apache2. jsing and I know where the problem is and we know of several
approaches how to avoid it. As always, the issue is that someone needs
to sit down do it. Since this only affects one specific web server
software it's not especially high on the list of priorities.

More details and a link is in this mail and mor can be found in the
thread:

https://marc.info/?l=openbsd-ports=167577915605727=2

> My web server is running OpenBSD 6.8 (yes, I know) using apache2 and
> letsencrypt certificates.

The fix will not be extremely complicated and if we land it soon, it
will be easy to backport to 7.3. It will definitely not be easy to
backport it to 6.8...

> If anyone else out there is getting this error or has gotten this error and
> figured out a workaround I'd love to hear from you, either on or off list.

Unless you are able to switch to a config not involving virtual hosts
(in which case I believe the problem should not manifest but I'm not
100% certain about this) I am not aware of a workaround that only
involves some config knobs.

Re: All my Rust programs stop working on OpenBSD 7.3

[Theo Buehler]

On Tue, Apr 11, 2023 at 04:43:04PM +0800, Siegfried Levin wrote:
> I checked the core dump again. There is still an error on Ring 0.16.20.

Yes, that's expected. If you read my mail again, I told you to use the
patched source in /usr/local/share/ring-0.16.20 from the rust-ring
package, not simply ring 0.16.20. Once again: if Cargo.toml contains

[dependencies]
...
ring = "^0.16"
...

or similar, remove the ring line from [dependencies] and add a new section

[dependencies.ring]
version = "^0.16"
path = "/usr/local/share/ring-0.16.20"

Or you can follow Laurie Tratt's recpie.

> Where can I know more about the protection introduced in 7.3 in case that I 
> need to report this on GitHub? Thanks.

I don't think it's going to be useful to report this on github. I will
try to upstream the patches when I will find time to do so. It's a bit
of a tricky patchset since ring uses assembly from BoringSSL and targets
various platforms I don't have easy access to, so I can't upstream the
patches as they currently are in the port.

> Reading symbols from /usr/libexec/ld.so...Error while reading shared library 
> symbols:
> Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
> module /usr/libexec/ld.so]
> #0  GFp_sha512_block_data_order_avx () at 
> /mnt/warehouse/home/git/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/pregenerated/sha512-x86_64-elf.S:1881
> 1881  vpaddq  -128(%rbp),%xmm0,%xmm8

Yes, as expected.

> 
> > On Apr 11, 2023, at 02:54, Theo Buehler  wrote:
> > 
> > 
> >> 
> >> Thanks. Actually that’s what I did. Rust package was updated by
> >> “pkg_add -u rust” and then “cargo build —release” rebuilds the
> >> projects. However, when I ran it, it crashed because of segment fault.
> >> It no longer passes the tests as well,  “invalid memory reference” was
> >> returned.
> > 
> > Without seeing a backtrace it is difficult to tell.
> > 
> > Another issue could be that you use things depending on the ring crate
> > whose assembly isn't compatible with the new x-only protection on modern
> > amd64 machines.
> > 
> > If so, you will need to 
> > 
> > # pkg_add rust-ring
> > 
> > and replace lines like this
> > 
> > ring = "^0.16"
> > 
> > with something like this in Cargo.toml:
> > 
> > [dependencies.ring]
> > version = "^0.16"
> > path = "/usr/local/share/ring-0.16.20"

Re: All my Rust programs stop working on OpenBSD 7.3

[Theo Buehler]

> Thanks. Actually that’s what I did. Rust package was updated by
> “pkg_add -u rust” and then “cargo build —release” rebuilds the
> projects. However, when I ran it, it crashed because of segment fault.
> It no longer passes the tests as well,  “invalid memory reference” was
> returned.

Without seeing a backtrace it is difficult to tell.

Another issue could be that you use things depending on the ring crate
whose assembly isn't compatible with the new x-only protection on modern
amd64 machines.

If so, you will need to 

# pkg_add rust-ring

and replace lines like this

ring = "^0.16"

with something like this in Cargo.toml:

[dependencies.ring]
version = "^0.16"
path = "/usr/local/share/ring-0.16.20"

Re: [patch]: SSL_OP_NO_RENEGOTIATION vs SSL_OP_NO_CLIENT_RENEGOTIATION inconsistency

[Theo Buehler]

On Sun, Feb 05, 2023 at 03:59:38PM -0700, Ashlen wrote:
> (Can CC to tech@ or elsewhere if needed, I didn't know if it belonged here or
> there so I'm starting here)

Please do not send patches to misc. Many of us don't have the time and
nerves to dig through all the noise to see if there's anything worth
looking at.

> These files in the source tree are expecting SSL_OP_NO_RENEGOTIATION when only
> SSL_OP_NO_CLIENT_RENEGOTIATION is defined in lib/libssl/ssl.h. 
> 
> $ grep -Rl 'SSL_OP_NO_RENEGOTIATION'
> usr.sbin/unbound/util/net_help.c
> usr.sbin/unbound/smallapp/unbound-control.c
> usr.sbin/nsd/server.c
> usr.sbin/nsd/nsd-control.c
> sbin/unwind/libunbound/util/net_help.c

As you noted in your second mail, this is all third-party software. We
do not want patches in there that we can't upstream. So in principle I
would agree that your first patch is preferrable.

> $ grep -Rl 'SSL_OP_NO_CLIENT_RENEGOTIATION'
> lib/libssl/ssl_pkt.c
> lib/libssl/ssl.h
> lib/libssl/d1_pkt.c
> lib/libtls/tls_server.c
>
> Is this intentional? 

Yes. SSL_OP_NO_CLIENT_RENEGOTIATION was introduced in LibreSSL in Jan '15
and does what it says: it turns off client-side renegotiation. I do not
know if it was intentially left undocumented.

https://github.com/openbsd/src/commit/0d3c1a5098b4e6a447e95479733e6abd9b485298

[If you look at the code you patch in ssl_pkt.c and d1_pkt.c, it's when
the server reads a legacy (TLSv1.2 or earlier) ClientHello, so no change
in behavior on the client side.]

Of note: at that point renegotiation could still be turned off via the
undocumented SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS. This is no longer
possible since it needs an access to ssl->s3->flags and ssl is now
opaque.

> I should note that OpenSSL uses SSL_OP_NO_RENEGOTIATION. At least two ports 
> I've
> seen expect this and fail to disable client renegotiation as a result. 

This was introduced a few months later in OpenSSL and it turns off both
client-initiated and server-initiated renegotiation. The reason for
adding this option was precisely that the opaque SSL in OpenSSL 1.1 did
no longer allow setting SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS.

https://github.com/openssl/openssl/commit/db0f35dda18403accabe98e7780f3dfc516f49de

The two options don't do the same thing, so renaming
SSL_OP_NO_CLIENT_RENEGOTIATION into SSL_OP_NO_RENEGOTIATION or vice
versa isn't correct.

> I don't know for sure which direction others would prefer to patch in, but I 
> get
> the feeling it makes more sense to choose the approach that involves less 
> future
> patching (renaming SSL_OP_NO_CLIENT_RENEGOTIATION to 
> SSL_OP_NO_RENEGOTIATION). 

If the two options were equivalent, another option would have been to
add one compat define to ssl.h:

#define SSL_OP_NO_RENEGOTIATION SSL_OP_NO_CLIENT_RENEGOTIATION

This way no other patching would be needed.

> I'll include both methods of patching, one in this mail and one in my reply to
> it.

There are a few things to consider.

1. Should we add SSL_OP_NO_RENEGOTIATION?

In my opinion your findings suggest that it should be done. It should
not be hard if you want to take a stab at it.

2. We can probably also remove SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS (except
from ssl3.h)

3. OpenSSL 3 have disabled client-side renegotation by default. Can we
do the same? (Also, they now have SSL_OP_ALLOW_CLIENT_RENEGOTIATION
let's ignore this for now...)

BoringSSL have intricate logic on when they allow renegotiation and when
they don't, depending on the ALPN among other things. Basically, they
allow it for TLSv1.2 with HTTP/1.1, but disable it once they know they
use HTTP/2. Should we do similar instead?

> (Also, should lib/libssl/man/SSL_CTX_set_options.3 also get patched? Unsure 
> what
> to write there if so, as it depends on which solution makes more sense)
> 
> Index: lib/libssl/ssl_pkt.c
> ===
> RCS file: /cvs/src/lib/libssl/ssl_pkt.c,v
> retrieving revision 1.65
> diff -u -p -u -p -r1.65 ssl_pkt.c
> --- lib/libssl/ssl_pkt.c  26 Nov 2022 16:08:56 -  1.65
> +++ lib/libssl/ssl_pkt.c  5 Feb 2023 22:49:15 -
> @@ -958,7 +958,7 @@ ssl3_read_handshake_unexpected(SSL *s)
>   return -1;
>   }
>  
> - if ((s->options & SSL_OP_NO_CLIENT_RENEGOTIATION) != 0) {
> + if ((s->options & SSL_OP_NO_RENEGOTIATION) != 0) {
>   ssl3_send_alert(s, SSL3_AL_FATAL,
>   SSL_AD_NO_RENEGOTIATION);
>   return -1;
> Index: lib/libssl/ssl.h
> ===
> RCS file: /cvs/src/lib/libssl/ssl.h,v
> retrieving revision 1.230
> diff -u -p -u -p -r1.230 ssl.h
> --- lib/libssl/ssl.h  26 Dec 2022 07:31:44 -  1.230
> +++ lib/libssl/ssl.h  5 Feb 2023 22:49:16 -
> @@ -402,7 +402,7 @@ typedef int (*tls_session_secret_cb_fn)(
>  /* As server, disallow session resumption on renegotiation */
>  #define 

Re: Is CRONTAB(5) random really random ?

[Theo Buehler]

On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote:
> According to the docs :
> 
> > A random value (within the legal range) may be obtained by usingthe ‘~’ 
> > character in a field.

The random numbers are drawn once and then repeated regularly. This
behavior has always bothered me but never enough to spend the time
needed to fix it (it's not immediately obvious how to do it). A
workaround is to use a 

sleep $((RANDOM \% 512)) && run_whatever

construct. The number to the right of the modulo should be a power of 2
to avoid modulo bias.

Re: Lenovo IdeaPad 3 14ITL05 EST turbo mode

[Theo Buehler]

On Fri, Aug 19, 2022 at 08:41:57AM +0300, Mikhail wrote:
> Recently I've bought subject laptop, but it had an issue - when I was
> doing git clone of a any huge tree, like linux kernel, it shut down in
> the beginning of 'Resolving deltas' stage. I'd tested Debian 11 and
> OpenBSD (current) - Debian shut down almost immediately, OpenBSD was
> working randomly but about ~3 minutes.
> 
> Service guys set up Windows 10 on it and git clone worked fine there,
> they also did AIDA64 stress testing for a day, and I'd tested latest
> Ubuntu 22.04.1 and it worked without the issue. I did some digging and
> came up with this commit:
> 
> ---
> commit 086aa750ab8f1698a6c6eaafe1458279776ce66d
> from: tb 
> date: Wed Aug 11 18:15:50 2021 UTC
> 
> Make hw.setperf percentages proportional to the enhanced speed step
> frequencies on intel processors. This way, the default hw.setperf=99
> corresponds to the maximum ordinary speed while setting it to 100
> enables turbo mode.
> 
> Tested in snaps for a week, positive feedback from several.
> 
> M  sys/arch/amd64/amd64/est.c
> ---
> 
> Apparently setperf was set to 100, and if the CPU works in that "turbo
> mode" for long enough it overheats and shuts down (sensors shows
> temperature of ~100C while in 'Resolving deltas').
> 
> Work around was to set:
> hw.perfpolicy=manual
> hw.setperf=99
> 
> I was watching how Windows 10 behaves and noticed that when CPU
> intensive thing starts - it boosts CPU for 100% for about 5 seconds and
> then drops it to 85% and continue to work in this mode till the end of
> the task.
> 
> My previous laptop is around 12 years old, so I don't follow how modern
> HW in this segment works, I was told that current laptops can work in
> high speed mode only for a while, and then they should back to normal
> speeds, otherwise behavior is unpredictable (as with this one).
> 
> I'd like to know from your experience - is that shitty cooling design
> from Lenovo, or the OSes should be more careful about setting turbo
> mode? Since the commit is 1 year old and no one complained, I assume
> it's first, but would like to know opinion of the list.

It is known bad behavior of OpenBSD for which no-one has proposed an
acceptable solution.

My commit didn't really change the scheduler's behavior. Rather it
addressed how the percentages are mapped to different frequencies.
Previously, setting the setperf to 75 would enable turbo mode on some
machines.

You're much more likely to be bitten by this change:

https://github.com/openbsd/src/commit/0294e0be5821991219b454f4fdc27f570d30a6fd

which enables turbo mode by default as soon as a machine is plugged to
hw power.

There's been a lot of dicsussion and quite a few patches to address this
situation. No proposed solution was deeemed adequate. The old code
wasn't great either. Unless you want to patch the kernel (e.g. do
"if (0 && hw_power)" in the appropriate place), you're forced to use
your workaround.

Some people also recommend the obsdfreqd port.

Re: libressl's openssl command

[Theo Buehler]

On Fri, Jul 01, 2022 at 10:57:52AM +0300, Gregory Edigarov wrote:
> Hello,
> 
> $ openssl version
> LibreSSL 3.5.2
> 
> $ openssl genpkey -algorithm ed25519
> Algorithm ed25519 not found
> 
> $ openssl genpkey -algorithm x25519
> Algorithm x25519 not found
> 
> How would you generate a keypair?
> Yes I use openssl-1.1.1op0 package, but just out of curiosity,
> why this features still not in LibreSSL even with programming interface
> in?
> 
> X25519, X25519_keypair(3) - Elliptic Curve Diffie-Hellman primitive
> based on Curve25519

These functions do not provide what you are asking for. As the
description says, this is the ECDH primitive, not an ASN.1 interface.

The questions you are asking always have the same answer: no-one with
the requisite knowledge has done the work to add support, and it's more
than just a little bit of work. Also, Ed25519 is not currently supported
at all in LibreSSL.

It is an often requested feature and it will likely be added at some
point. Those who know how to do it will have to find the time to do it.
Those who don't will have to be patient. It won't happen by asking
repeatedly on various forums.

Re: mutt fetch-mail ssl error

[Theo Buehler]

On Fri, May 20, 2022 at 04:08:25PM +1200, Avon Robertson wrote:
> I have been unable to fetch mail with mutt on this host using either the
> currently installed snapshot and mutt package, or the snapshot and mutt
> package that had been installed 2-3 days previously.
> 
> I have been able to send mail using mutt in conjuction with msmtp from
> this host.
> 
> mutt's error-history command displays
> 
> Reading /home/aer/var/mail/inbox...
> Reading /home/aer/var/mail/inbox... 0
> Looking up pop3.xtra.co.nz...
> Connecting to pop3.xtra.co.nz...
> SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate
> +verify failed
> Error connecting to server: pop3.xtra.co.nz

There is a good chance that this is a bug I introduced by adding a more
stringent check when rewriting ASN1_STRING_to_UTF8(). This can now fail
if passed an uninitialized pointer. This bug should be fixed via
x509_utl.c r1.3 and a_string.c r1.11 which add initialization and relax
the check again.

X509_verify_cert()
 x509_verify() 
  x509_verify_cert_hostname()
   X509_check_host()
do_x509_check()
 do_check_string()
  ASN1_STRING_to_UTF8()

If this is the problem, you can fix this by checking out very current
sources and rebuilding libcrypto

  cd /usr/src/lib/libcrypto
  make obj
  doas make includes
  make
  doas make install

or you can wait for a new snapshot including this fix and try again.

Re: OpenBSD ftp and libtls: how to use session resumption with -S

[Theo Buehler]

On Thu, May 05, 2022 at 08:36:36PM -0400, Ted Unangst wrote:
> On 2022-05-05, Ted Unangst wrote:
> > On 2022-05-05, Theo Buehler wrote:
> > > On Thu, May 05, 2022 at 10:59:45AM +0200, Hiltjo Posthuma wrote:
> > > > Is this option currently enabled and working? I haven't been able to see
> > > > session resumption being used when testing uses OpenBSD ftp.
> > > 
> > > Yes, it works, but only with TLSv1.2. For TLSv1.3 this needs support for
> > > PSK, which is not currently implemented.
> > 
> > Should we default to TLS 1.2 if the user requests session resumption and
> > doesn't otherwise specify version?
> 
> Okay, I was a little confused. libtls already does this.
> 
> If you request session support, it drops to tls 1.2. Everything seems fine.

It does not. If you pass -S session=mysession.pem to ftp and the server
talks TLSv1.3, you get a TLSv1.3 session on disk which you can't resume
due to lack of PSK support. This is what triggered this question.

Once you have a resumable session on disk, libtls will resume it
automatically, but that currently means the initial connection must have
used the legacy stack.

While we could readily make libssl fall back to the legacy stack if
SSL_OP_NO_TICKET is disabled, I don't think this optimization outweighs
the overall benefit of TLSv1.3 - better protocol, cleaner code.

The real fix is to implement PSK support. It will come at some point.

Re: OpenBSD ftp and libtls: how to use session resumption with -S

[Theo Buehler]

On Thu, May 05, 2022 at 10:59:45AM +0200, Hiltjo Posthuma wrote:
> Hi,
> 
> I have a question how OpenBSD ftp and session resumption works and can be
> enabled or used using the option -S session=somepath .
> 
> If I remember correctly this option was added at the time to improve the
> performance of TLS handshakes for fetching OpenBSD packages from HTTPS 
> mirrors.
> I'd also like to test if this makes a difference for my use-case.
> 
> Is this option currently enabled and working? I haven't been able to see
> session resumption being used when testing uses OpenBSD ftp.

Yes, it works, but only with TLSv1.2. For TLSv1.3 this needs support for
PSK, which is not currently implemented.

$ ftp -M -S"session=mysession.pem,protocols=tlsv1.2" 
https://www.openbsd.org/index.html
Trying 199.185.178.80...
Requesting https://www.openbsd.org/index.html
3494 bytes received in 0.00 seconds (9.06 MB/s)
tls session resumed: no
$ ftp -M -S"session=mysession.pem,protocols=tlsv1.2" 
https://www.openbsd.org/index.html
Trying 199.185.178.80...
Requesting https://www.openbsd.org/index.html
3494 bytes received in 0.00 seconds (8.88 MB/s)
tls session resumed: yes

Re: [PATCH] Move warnx into correct place

[Theo Buehler]

On Sun, Feb 20, 2022 at 03:10:16PM +0100, Wolf wrote:
> Original location caused the line to be printed every time for ec keys.
> I suspect copy error from rsa_key_create.

Committed, thanks!

Re: `jq` won't chroot?

[Theo Buehler]

On Fri, Jul 16, 2021 at 10:24:10PM +, Kent Watsen wrote:
> I’ve spent a few hours on this and am lost.  I have plenty experience moving 
> executables into a chroot environments, but `jq` is proving to be 
> exceptionally difficult.
> 
> The executable is found when chrooted to ‘/‘ but not ' /var/www’.  Yes, of 
> course I copied all the files referenced from `ldd` into the chroot, and set 
> their file permissions to 777 (and likewise all the parent directories):
> 
> # pkg_add jq
> 
> # chroot / /usr/local/bin/jq --version 
> jq-1.6
> 
> *** COPY `ldd /usr/local/bin/jq` DEPENDENCIES INTO  /var/www/ HERE ***
> 
> # chroot /var/www /usr/local/bin/jq --version  
> ld.so: jq: can't load library 'libonig.so.7.1’
> 
> 
> Any ideas?

It seems you copied libjq and libonig into usr/local/lib in the chroot.
By default, ld.so only looks for shared objects in /usr/lib, so it can't
find them.

# env LD_LIBRARY_PATH=/usr/lib:/usr/local/lib chroot /var/www /usr/local/bin/jq 
--version

should work.

Chrooting to / works because rc(8) runs ldconfig(8) to add
/usr/local/lib and /usr/X11R6/lib if they're present.

You can copy all the libraries into /var/www/usr/lib, you can set
LD_LIBRARY_PATH=/usr/local/lib:/usr/, or you can run ldconfig in the
chroot.

Read ld.so(1) and ldconfig(8) for more details.

Re: iridium browser cache

[Theo Buehler]

On Fri, Jun 25, 2021 at 06:25:10AM +0200, Peter J. Philipp wrote:
> Hi,
> 
> Occasionally I see in my query logs that iridium browser contacts an address
> called "cache.iridiumbrowser.de".
> 
> Jun 25 06:16:31 eta delphinusdnsd[14254]: request on descriptor 24 interface 
> "cnmac1" from 192.168.177.8 (ttl=64, region=255, tta=1.794ms) for 
> "cache.iridiumbro
> wser.de." type=A(1) class=1, answering "FORWARD" (bytes=41/0, sum=a56)
> 
> I've had some instability issues with iridium in the past and I'm wondering
> how I can turn this off.  I guess they stripped all the google phone home
> stuff from chromium, and now do their own phone home.

Try turning off safe browsing.

https://github.com/iridium-browser/tracker/wiki/Differences-between-Iridium-and-Chromium#google-safe-browsing

> 
> The fact that it says "cache" leaves my mind boggling.
> 
> Best regards,
> -peter
> 
> PS: other than firefox what are the alternatives to iridium on arm64 (rpi4)?
> 

Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Theo Buehler]

On Thu, Jun 24, 2021 at 11:09:05AM -0600, Matt Dowle wrote:
> Hi,
> 
> Is it intentional or is there any good reason that OpenBSD 6.9 released May
> 2021 uses a 16 year old version of zlib (v1.2.3; July 2005)?  The latest
> version v1.2.11 (Jan 2017) is 4 years old.
> 
> Background here: https://github.com/Rdatatable/data.table/pull/5049

If we want to go the cherry-picking route, here's a diff that fixes the
test.csv.gz test case provided in the linked issue.

All of test.data.table() now passes:

All 9062 tests (last 2163) in tests/tests.Rraw.bz2 completed ok in 57.9s 
elapsed (49.9s cpu)

I haven't done further testing as deflateBound() is not used in the base
system.

This backports zlib's deflate.c diff between 1.2.3 and 1.2.3.1.  It
adjusts the calculation of the bound by calculating the wrapper length
instead of trying to bound it. The result can now be larger than the
previous bound.  It modifies the two copies of deflate.c in /usr/src
where the change would apply cleanly.  Perl's version has the change and
the copy in gnu/usr.bin/cvs is even older...

https://github.com/madler/zlib/commit/b1c19ca6d82c98a8be6cd9cad7a9c5fa5e8e634e#diff-7e5fd0aa55941ed3e3c9c564a713b3841f20f7defc549277cdf94f6c90882af8

Index: lib/libz/deflate.c
===
RCS file: /cvs/src/lib/libz/deflate.c,v
retrieving revision 1.11
diff -u -p -r1.11 deflate.c
--- lib/libz/deflate.c  27 Oct 2009 23:59:31 -  1.11
+++ lib/libz/deflate.c  25 Jun 2021 03:03:40 -
@@ -479,33 +479,65 @@ int ZEXPORT deflateTune(strm, good_lengt
  * resulting from using fixed blocks instead of stored blocks, which deflate
  * can emit on compressed data for some combinations of the parameters.
  *
- * This function could be more sophisticated to provide closer upper bounds
- * for every combination of windowBits and memLevel, as well as wrap.
- * But even the conservative upper bound of about 14% expansion does not
- * seem onerous for output buffer allocation.
+ * This function could be more sophisticated to provide closer upper bounds for
+ * every combination of windowBits and memLevel.  But even the conservative
+ * upper bound of about 14% expansion does not seem onerous for output buffer
+ * allocation.
  */
 uLong ZEXPORT deflateBound(strm, sourceLen)
 z_streamp strm;
 uLong sourceLen;
 {
 deflate_state *s;
-uLong destLen;
+uLong complen, wraplen;
+Bytef *str;
 
-/* conservative upper bound */
-destLen = sourceLen +
-  ((sourceLen + 7) >> 3) + ((sourceLen + 63) >> 6) + 11;
+/* conservative upper bound for compressed data */
+complen = sourceLen +
+  ((sourceLen + 7) >> 3) + ((sourceLen + 63) >> 6) + 5;
 
-/* if can't get parameters, return conservative bound */
+/* if can't get parameters, return conservative bound plus zlib wrapper */
 if (strm == Z_NULL || strm->state == Z_NULL)
-return destLen;
+return complen + 6;
 
-/* if not default parameters, return conservative bound */
+/* compute wrapper length */
 s = strm->state;
+switch (s->wrap) {
+case 0: /* raw deflate */
+wraplen = 0;
+break;
+case 1: /* zlib wrapper */
+wraplen = 6 + (s->strstart ? 4 : 0);
+break;
+case 2: /* gzip wrapper */
+wraplen = 18;
+if (s->gzhead != NULL) {/* user-supplied gzip header */
+if (s->gzhead->extra != NULL)
+wraplen += 2 + s->gzhead->extra_len;
+str = s->gzhead->name;
+if (str != NULL)
+do {
+wraplen++;
+} while (*str++);
+str = s->gzhead->comment;
+if (str != NULL)
+do {
+wraplen++;
+} while (*str++);
+if (s->gzhead->hcrc)
+wraplen += 2;
+}
+break;
+default:/* for compiler happiness */
+wraplen = 6;
+}
+
+/* if not default parameters, return conservative bound */
 if (s->w_bits != 15 || s->hash_bits != 8 + 7)
-return destLen;
+return complen + wraplen;
 
 /* default settings: return tight bound for that case */
-return compressBound(sourceLen);
+return compressBound(sourceLen) - 6 + wraplen;
 }
 
 /* =
Index: sys/lib/libz/deflate.c
===
RCS file: /cvs/src/sys/lib/libz/deflate.c,v
retrieving revision 1.3
diff -u -p -r1.3 deflate.c
--- sys/lib/libz/deflate.c  14 Mar 2016 23:08:06 -  1.3
+++ sys/lib/libz/deflate.c  25 Jun 2021 03:04:49 -
@@ -479,33 +479,65 @@ int ZEXPORT deflateTune(strm, good_lengt
  * resulting from using fixed blocks instead of stored blocks, which 

Re: nc(1) fails the tls handshake when destination ends with a full stop

[Theo Buehler]

On Sun, May 30, 2021 at 01:43:54PM -0400, Daniel Jakots wrote:
> On Sun, 30 May 2021 17:45:22 +0200, Theo Buehler 
> wrote:
> 
> > Unsure. If people really think this is useful and necessary, I can be
> > convinced. It's easy enough to do. And you're right, curl strips the
> > trailing dot after resolving a host name for SNI and HTTP host header.
> 
> Given the current error message makes it hard to understand what the
> problem is, I think it's nicer to fix the user error like curl(1) does.

What I do not quite see is why you would want or expect to be able to
have a trailing dot there. None of nc's examples have it and in ftp/curl
it seems even weirder.

Re: nc(1) fails the tls handshake when destination ends with a full stop

[Theo Buehler]

On Sun, May 30, 2021 at 02:31:55PM -, Stuart Henderson wrote:
> On 2021-05-30, Theo Buehler  wrote:
> > On Sat, May 29, 2021 at 10:37:18PM -0400, Daniel Jakots wrote:
> >> Hi,
> >> 
> >> $ nc -zvc openbsd.org 443 # works as expected
> >> Connection to openbsd.org (129.128.5.194) 443 port [tcp/https] succeeded!
> >> TLS handshake negotiated TLSv1.3/AEAD-AES256-GCM-SHA384 with host 
> >> openbsd.org
> >> [...]
> >> 
> >> $ nc -zvc openbsd.org. 443 # fails
> >> Connection to openbsd.org. (129.128.5.194) 443 port [tcp/https] succeeded!
> >> nc: tls handshake failed (handshake failed: error:1404B42E:SSL 
> >> routines:ST_CONNECT:tlsv1 alert protocol version)
> >
> > $ nc -cvz -e openbsd.org openbsd.org. 443 # works
> >
> > Unless -e is given, nc uses 'destination' in its server name indication
> > (SNI) extension.  By its specification, (RFC 6066, section 3) the SNI
> > does not contain the trailing dot.
> 
> Should something (libtls perhaps; ftp(1) is affected too) strip the dot?
> curl does handle this.
> 

Unsure. If people really think this is useful and necessary, I can be
convinced. It's easy enough to do. And you're right, curl strips the
trailing dot after resolving a host name for SNI and HTTP host header.

I would be against doing it server side since contrary to sending IP
addresses it doesn't seem to be common, but doing this client side seems
innocuous.

Index: tls_client.c
===
RCS file: /cvs/src/lib/libtls/tls_client.c,v
retrieving revision 1.45
diff -u -p -r1.45 tls_client.c
--- tls_client.c19 Mar 2018 16:34:47 -  1.45
+++ tls_client.c30 May 2021 15:26:54 -
@@ -279,6 +279,7 @@ static int
 tls_connect_common(struct tls *ctx, const char *servername)
 {
union tls_addr addrbuf;
+   size_t servername_len;
int rv = -1;
 
if ((ctx->flags & TLS_CLIENT) == 0) {
@@ -291,6 +292,12 @@ tls_connect_common(struct tls *ctx, cons
tls_set_errorx(ctx, "out of memory");
goto err;
}
+
+   /* If there's a trailing dot, strip it. */
+   servername_len = strlen(servername);
+   if (servername_len > 0 &&
+   ctx->servername[servername_len - 1] == '.')
+   ctx->servername[servername_len - 1] = '\0';
}
 
if ((ctx->ssl_ctx = SSL_CTX_new(SSLv23_client_method())) == NULL) {
@@ -306,7 +313,7 @@ tls_connect_common(struct tls *ctx, cons
goto err;
 
if (ctx->config->verify_name) {
-   if (servername == NULL) {
+   if (ctx->servername == NULL) {
tls_set_errorx(ctx, "server name not specified");
goto err;
}
@@ -353,10 +360,11 @@ tls_connect_common(struct tls *ctx, cons
 * RFC4366 (SNI): Literal IPv4 and IPv6 addresses are not
 * permitted in "HostName".
 */
-   if (servername != NULL &&
-   inet_pton(AF_INET, servername, ) != 1 &&
-   inet_pton(AF_INET6, servername, ) != 1) {
-   if (SSL_set_tlsext_host_name(ctx->ssl_conn, servername) == 0) {
+   if (ctx->servername != NULL &&
+   inet_pton(AF_INET, ctx->servername, ) != 1 &&
+   inet_pton(AF_INET6, ctx->servername, ) != 1) {
+   if (SSL_set_tlsext_host_name(ctx->ssl_conn,
+   ctx->servername) == 0) {
tls_set_errorx(ctx, "server name indication failure");
goto err;
}
Index: tls_server.c
===
RCS file: /cvs/src/lib/libtls/tls_server.c,v
retrieving revision 1.45
diff -u -p -r1.45 tls_server.c
--- tls_server.c13 May 2019 22:36:01 -  1.45
+++ tls_server.c30 May 2021 15:28:10 -
@@ -109,7 +109,7 @@ tls_servername_cb(SSL *ssl, int *al, voi
 inet_pton(AF_INET6, name, ) == 1)
return (SSL_TLSEXT_ERR_NOACK);
 
-   free((char *)conn_ctx->servername);
+   free(conn_ctx->servername);
if ((conn_ctx->servername = strdup(name)) == NULL)
goto err;
 

Re: nc(1) fails the tls handshake when destination ends with a full stop

[Theo Buehler]

On Sat, May 29, 2021 at 10:37:18PM -0400, Daniel Jakots wrote:
> Hi,
> 
> $ nc -zvc openbsd.org 443 # works as expected
> Connection to openbsd.org (129.128.5.194) 443 port [tcp/https] succeeded!
> TLS handshake negotiated TLSv1.3/AEAD-AES256-GCM-SHA384 with host openbsd.org
> [...]
> 
> $ nc -zvc openbsd.org. 443 # fails
> Connection to openbsd.org. (129.128.5.194) 443 port [tcp/https] succeeded!
> nc: tls handshake failed (handshake failed: error:1404B42E:SSL 
> routines:ST_CONNECT:tlsv1 alert protocol version)

$ nc -cvz -e openbsd.org openbsd.org. 443 # works

Unless -e is given, nc uses 'destination' in its server name indication
(SNI) extension.  By its specification, (RFC 6066, section 3) the SNI
does not contain the trailing dot.

The server will treat the name with a trailing dot illegal and send an
illegal_parameter alert. For some reason this alert is sent with a
record version of TLS1_VERSION instead of TLS1_2_VERSION as required by
the TLSv1.3 spec (that may be a bug), so while processing the illegal
parameter alert, the client's record layer throws a protocol version
error.

> And FWIW I get a different error when the destination runs nginx:
> 
> $ nc -zvc px.chown.me. 443 
> Connection to px.chown.me. (198.48.202.221) 443 port [tcp/https] succeeded!
> nc: tls handshake failed (handshake failed: error:1404B417:SSL 
> routines:ST_CONNECT:sslv3 alert illegal parameter)

This has less to do with the fact that it's nginx and more with the fact
that you configured it to use TLSv1.2, so the illegal_parameter alert is
received without error.

> I checked with -Tnoname to be sure, and it didn't change anything.

This disables a check whether the server's certificate matches the
server name sent in the SNI extension which comes later in the handshake.

> Is that normal?

I think so.

Re: Tor Relay log warning

[Theo Buehler]

On Wed, May 05, 2021 at 08:06:09AM -0300, Matheus Coelho wrote:
> Hello List!
> 
> I have a tor relay server and in version 6.9 of openbsd the log started
> showing this message:
> 
> tor_tls_finish_handshake: Bug: For some reason, wasV2Handshake didn't get
> set. Fixing that. (on Tor 0.4.5.7 )
> 
> I suspect something related to libressl according to this post:

Yes, libressl doesn't fully support the info callback that tor
relies on to set wasV2Handshake. This will be a bit tricky to fix.
I think tor will still work, but the log spam is annoying.

> https://gitlab.torproject.org/tpo/core/tor/-/issues/40128

This post conflates many different issues, most of which should be
resolved.

> 
> it makes sense?
> 
> thanks in advance.
> --
> Matheus Coelho Torres Macedo

Recent OpenSSL and LibreSSL errata

[Theo Buehler]

There appears to be a bit of confusion out there. To be clear:

1. The two bugs that were fixed in OpenSSL 1.1.1k [1] were introduced
   well after the fork, so LibreSSL is not affected.  OpenSSL have
   kindly given us advance access to their fixes.

2. The bug fixed in LibreSSL 3.2.5 [2] is our own and entirely unrelated.

[1]: https://marc.info/?l=openssl-announce=161668124700970=2
[2]: https://marc.info/?l=openbsd-announce=161582456312832=2

Re: iked does not recognize ikectl certificate

[Theo Buehler]

On Thu, Mar 18, 2021 at 11:25:22PM +0100, Lorenz Jiha wrote:
> Hi,
> 
> I'm using iked since a few years with certificate authentication for my
> roadwarrior linux without any trouble.
> 
> I took a 6.8 fresh install and used classically ikectl to generate a new CA
> and certificates.
> 
> But when I try to connect to the OBSD iked, authentication is refused for
> my client with this message :
> ca_validate_cert: /C=FR/ST=France/L=Paris/O=XXX rejecting self-signed
> certificate
> 
> if I syspatch the server, the error message become :
> 
> ca_validate_cert: /C=FR/ST=France/L=Paris/O=XXX unsupported or invalid name
> syntax

This is manifestly caused by the new name constraints code that is part
of the new x509 verifier shipped in 6.8. The syspatch changed back to
using the old verifier code, but keeps using the new name constraints
code. That's why the error changed  - "rejecting self-signed certificate"
is a catch-all used in iked.

It would be helpful if you could generate a new certificate and share
this (off-list if you prefer) so that we can look at precisely what
causes the issue.

> 
> If I restart from a 6.7 box, and generate my certificate, everything is OK
> but if I upgrade to 6.8, same behavior.
> 
> Has anyone met the same behavior ?
> 
> Thanks

Re: Q: pkg_add fails with: TLS handshake failure: ocsp verify failed: Undefined error ...

[Theo Buehler]

On Fri, Mar 19, 2021 at 04:56:11PM +, Stuart Henderson wrote:
> In gmane.os.openbsd.misc, li...@y42.org wrote:
> >
> > Hi All,
> >
> > What would cause pkg_add -u to report this error?
> >> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: TLS handshake 
> >> failure: ocsp verify failed: Undefined error: 0
> >> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: empty
> >> Couldn't find updates for ... a long list of (all?) installed packages ...
> >
> > Error 0?
> 
> There is some problem doing OCSP validation. It validates OK with openssl
> 1.0.2u and 1.1.1j but not with libressl. DFN run their own PKI and OCSP
> responder so it might hit some edge case that isn't seen with other
> responders.

I missed a typo in tobhe's diff. This fixes it for me.

Index: x509/x509_purp.c
===
RCS file: /cvs/src/lib/libcrypto/x509/x509_purp.c,v
retrieving revision 1.3
diff -u -p -r1.3 x509_purp.c
--- x509/x509_purp.c13 Mar 2021 23:01:49 -  1.3
+++ x509/x509_purp.c19 Mar 2021 17:21:29 -
@@ -571,7 +571,7 @@ x509v3_cache_extensions(X509 *x)
if (x->skid == NULL && i != -1)
x->ex_flags |= EXFLAG_INVALID;
x->akid = X509_get_ext_d2i(x, NID_authority_key_identifier, , NULL);
-   if (x->skid == NULL && i != -1)
+   if (x->akid == NULL && i != -1)
x->ex_flags |= EXFLAG_INVALID;
 
/* Does subject name match issuer? */

Re: ldapd.conf certificate directive not working?

[Theo Buehler]

On Sun, Nov 29, 2020 at 12:00:29AM +0100, Martijn van Duren wrote:
> On Sat, 2020-11-28 at 23:08 +0100, Theo Buehler wrote:
> > > "If the certificate name is an absolute path, a .crt and .key
> > > extension are appended to form the certificate path and key path
> > > respectively."
> > > This part does not seem to work at all.
> > > Neither it tries to search certificates using the absolute path nor
> > > it tries to append .crt or .key extension to the absolute path when no
> > > extension is used in config.
> > > 
> > > Or I do it completely wrong?
> > 
> > It's a bug. If the certificate path is absolute, faulty short-circuiting
> > logic would result in first correctly appending ".crt" to the path, then
> > incorrectly prepending "/etc/ldap/cert".
> > 
> > You can see the problem with a config containing
> > 
> > listen on lo0 port 6636 tls certificate "/bogus/lo0"
> > 
> > $ ldapd -vv -f ldapd.conf -n
> > ...
> > loading certificate file /etc/ldap/certs//bogus/lo0.crt
> > ldapd.conf:5: cannot load certificate: /bogus/lo0
> > ...
> > 
> > The diff below avoids calling bsnprintf() twice for an absolute
> > certificate path.
> > 
> 
> Wouldn't it be more future idiot proof if we were a little more verbose?
> But if you prefer, your diff also looks good to me.

I have no strong preference either way (I would probably use yours if it
were my code). Feel free to go ahead with your diff and my ok after
giving jmatthew a bit of time to respond.

Re: ldapd.conf certificate directive not working?

[Theo Buehler]

> "If the certificate name is an absolute path, a .crt and .key
> extension are appended to form the certificate path and key path
> respectively."
> This part does not seem to work at all.
> Neither it tries to search certificates using the absolute path nor
> it tries to append .crt or .key extension to the absolute path when no
> extension is used in config.
> 
> Or I do it completely wrong?

It's a bug. If the certificate path is absolute, faulty short-circuiting
logic would result in first correctly appending ".crt" to the path, then
incorrectly prepending "/etc/ldap/cert".

You can see the problem with a config containing

listen on lo0 port 6636 tls certificate "/bogus/lo0"

$ ldapd -vv -f ldapd.conf -n
...
loading certificate file /etc/ldap/certs//bogus/lo0.crt
ldapd.conf:5: cannot load certificate: /bogus/lo0
...

The diff below avoids calling bsnprintf() twice for an absolute
certificate path.

Index: parse.y
===
RCS file: /cvs/src/usr.sbin/ldapd/parse.y,v
retrieving revision 1.36
diff -u -p -r1.36 parse.y
--- parse.y 24 Jun 2020 07:20:47 -  1.36
+++ parse.y 28 Nov 2020 21:40:13 -
@@ -1281,8 +1281,9 @@ load_certfile(struct ldapd_config *env, 
 
if ((name[0] == '/' &&
 !bsnprintf(certfile, sizeof(certfile), "%s.crt", name)) ||
-   !bsnprintf(certfile, sizeof(certfile), "/etc/ldap/certs/%s.crt",
-   name)) {
+   (name[0] != '/' &&
+!bsnprintf(certfile, sizeof(certfile), "/etc/ldap/certs/%s.crt",
+   name))) {
log_warn("load_certfile: path truncated");
goto err;
}
@@ -1300,8 +1301,9 @@ load_certfile(struct ldapd_config *env, 
 
if ((name[0] == '/' &&
 !bsnprintf(certfile, sizeof(certfile), "%s.key", name)) ||
-   !bsnprintf(certfile, sizeof(certfile), "/etc/ldap/certs/%s.key",
-   name)) {
+   (name[0] != '/' &&
+!bsnprintf(certfile, sizeof(certfile), "/etc/ldap/certs/%s.key",
+   name))) {
log_warn("load_certfile: path truncated");
goto err;
}

Re: ERR=20:"unable to get local issuer certificate"

[Theo Buehler]

On Wed, Nov 18, 2020 at 03:16:57PM -0800, David Newman wrote:
> Do recent complaints about certificate chains [1] [2] also apply when a
> client running OpenBSD 6.8 uses a self-signed cert, and there are no
> intermediate certs?

This is unrelated. The complaints you mention are due to a deliberate
difference between the old TLS stack and the new TLSv1.3 stack that was
enabled server side in OpenBSD 6.8. We hoped that we could get away
without auto chain but as it turns out some important enough software
depends on it...

> Since upgrading to OpenBSD 6.8, a machine running the bacula-client
> backup package has been throwing "unable to get local issuer
> certificate" warnings. With the same certs and configuration on OpenBSD
> 6.7, backups ran to completion without errors warnings.

OpenBSD 6.8 not only enabled the TLSv1.3 server in libssl, but it also
includes a new X.509 verifier in libcrypto [1]. This verifier has a
completely new design to fix major issues with the old one. There are
some bugs, and in some corner cases we don't match the behavior of the
old one.  Much of this API is undocumented, and we fail to replicate
behavior parts the ecosystem relies on.

The issue you are seeing is known [2] and should be fixed in -current.
The most important pieces of the puzzle are in [3] and [4].  We will see
about how best to deal with this and with other problems in 6.8 fairly
soon.

I don't think you can eliminate this warning without changing either
libcrypto or your setup.

[1]: https://undeadly.org/cgi?action=article;sid=20200921105847
[2]: https://github.com/znc/znc/issues/1763
[3]: https://marc.info/?l=openbsd-cvs=160546290826930=2
[4]: https://marc.info/?l=openbsd-cvs=160512059417991=2

Re: Firefox libGL errors if unveil is enabled

[Theo Buehler]

On Mon, Oct 19, 2020 at 09:48:44AM +0530, Anirudh Oppiliappan wrote:
> Firefox 81 gives the below errors, and tabs hang for about ~2-3 minutes
> before becoming usable, when unveil is enabled:
> 
> libGL error: failed to open /dev/drm0: No such file or directory
> libGL error: failed to load driver: i965
> libGL error: MESA-LOADER: failed to open swrast (search paths 
> /usr/X11R6/lib/modules/dri)
> libGL error: failed to load driver: swrast
> 
> This is on Intel UHD 620, so intel(4).  Workaround is to disable
> unveil.{main,gpu,content}, but that's not ideal.

I saw similar errors with layers.acceleration.force-enabled set on

inteldrm0 at pci0 dev 2 function 0 "Intel UHD Graphics 620" rev 0x07
drm0 at inteldrm0
inteldrm0: msi, KABYLAKE, gen 9

ktrace showed that the gpu process tried opening libelf and libLLVM.
The issue went away (and acceleration worked) when I added

/usr/lib r

to unveil.gpu.


> 
> Thoughts?
> 
> --
> Anirudh Oppiliappan
> https://icyphox.sh
> 

Re: 019_libssl.patch regression

[Theo Buehler]

On Tue, Aug 11, 2020 at 05:26:22PM -0400, Predrag Punosevac wrote:
> This is a regression report for 019_libssl.patch
> After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no
> longer close STARTTLS IPMI session with Gmail server. I recompiled
> s-nail and rebooted the machine. After reverting the patch s-nail works
> as expected. Interestingly enough I can only see this with Gmail
> servers.  019_libssl.patch doesn't break Hotmail IPMI connection. Patch
> does break SMTP session with Gmail server in the same fashion as IPMI.
> It just doesn't terminate cleanly. I don't know enough about the subject
> to look further into the problem but I am 100% sure this is LibreSSL
> bug.

Thanks for the report. Could you give this patch a spin on a -stable
system, that is, on top of the 019_libssl patch?

Index: lib/libssl/tls13_legacy.c
===
RCS file: /var/cvs/src/lib/libssl/tls13_legacy.c,v
retrieving revision 1.3.4.2
diff -u -p -r1.3.4.2 tls13_legacy.c
--- lib/libssl/tls13_legacy.c   10 Aug 2020 18:59:47 -  1.3.4.2
+++ lib/libssl/tls13_legacy.c   12 Aug 2020 18:46:12 -
@@ -497,6 +497,7 @@ tls13_legacy_shutdown(SSL *ssl)
if ((ret = tls13_record_layer_send_pending(ctx->rl)) !=
TLS13_IO_SUCCESS)
return tls13_legacy_return_code(ssl, ret);
+   ctx->close_notify_sent = 1;
} else if (!ctx->close_notify_recv) {
/*
 * If there is no application data pending, attempt to read more

Re: Recent regression in SSL session reuse

[Theo Buehler]

On Wed, Jul 29, 2020 at 02:57:33PM -0700, Jeremy Evans wrote:
> After an OpenBSD upgrade, one of Ruby's tests for SSL session
> reuse started to fail.  After some debugging, I have found that
> if a maximum SSL version is not set by a client, then session
> reuse does not work.  Setting a minimum version does not have
> an effect.

This is an expected side-effect of switching TLS_method() to default to
TLSv1.3

https://github.com/openbsd/src/commit/94149d15d762bdbf7eef74c417c53d2b8dc7dd12

By setting the max version to TLSv1 with :TLS1 (or any of the other
defined versions :TLS1_1 or :TLS1_2), you use the legacy stack which
supports session resumption. The minimum version is already TLSv1, so
setting the minimum version to :TLSv1 has no effect.

In TLSv1.3, the session resumption feature has been merged with
pre-shared keys, which we may eventually support, but that's not going
to happen very soon:

https://tools.ietf.org/html/rfc8446#page-15

Re: ksh very slow compared to bash when running ghostscript's ./configure script

[Theo Buehler]

On Wed, Jul 22, 2020 at 01:10:38PM -0600, Todd C. Miller wrote:
> On Wed, 22 Jul 2020 18:38:42 +0200, Theo Buehler wrote:
> 
> > Likely glob. Many glob implementations were found to suffer from
> > complexity issues: https://research.swtch.com/glob
> >
> > The glob(3) in libc was fixed
> > https://github.com/openbsd/src/commit/5c36dd0c22429e7b00ed5df80ed1383807532b5
> > 9
> > but ksh's builtin glog still has the issue.
> 
> At the very least we should collapse consecutive stars.  This is a
> separate issue from making gmatch() iterative.

Yes. This makes sense and fixes this issue.

ok tb

> 
>  - todd
> 
> Index: bin/ksh/misc.c
> ===
> RCS file: /cvs/src/bin/ksh/misc.c,v
> retrieving revision 1.74
> diff -u -p -u -r1.74 misc.c
> --- bin/ksh/misc.c7 Jul 2020 10:33:58 -   1.74
> +++ bin/ksh/misc.c22 Jul 2020 19:08:20 -
> @@ -615,6 +615,9 @@ do_gmatch(const unsigned char *s, const 
>   break;
>  
>   case '*':
> + /* collapse consecutive stars */
> + while (ISMAGIC(p[0]) && p[1] == '*')
> + p += 2;
>   if (p == pe)
>   return 1;
>   s--;

Re: ksh very slow compared to bash when running ghostscript's ./configure script

[Theo Buehler]

On Wed, Jul 22, 2020 at 07:05:31PM +0200, Theo Buehler wrote:
> This works around the bug:

And this might even be a correct fix:

diff --git configure.ac configure.ac
index 0d22ad59b..d27222459 100644
--- configure.ac
+++ configure.ac
@@ -483,7 +483,7 @@ AC_LINK_IFELSE(
   [AC_LANG_PROGRAM([#include ], [
   return(0);
   ])],
-  [CFLAGS_SANITIZE="$CFLAGS"], 
[CFLAGS_SANITIZE="ADDRESS_SANITIZER_NOT_SUPPORTED*"])
+  [CFLAGS_SANITIZE="$CFLAGS"], 
[CFLAGS_SANITIZE="'ADDRESS_SANITIZER_NOT_SUPPORTED*'"])
 
 CFLAGS="$CFLAGS_SAVED"
 

Re: ksh very slow compared to bash when running ghostscript's ./configure script

[Theo Buehler]

On Wed, Jul 22, 2020 at 06:38:42PM +0200, Theo Buehler wrote:
> > I don't know what's causing this. Is there some algorithm inside ksh
> > that could be running into complexity issues somehow?
> 
> Likely glob. Many glob implementations were found to suffer from
> complexity issues: https://research.swtch.com/glob
> 
> The glob(3) in libc was fixed
> https://github.com/openbsd/src/commit/5c36dd0c22429e7b00ed5df80ed1383807532b59
> but ksh's builtin glog still has the issue.
> 
> A quick ktrace seems to confirm that (I terminated the shell after it
> hung a while):
> 
>  58829 sh   5.883025 RET   getdents 1832/0x728
>  58829 sh   40.637429 PSIG  SIGTERM caught handler=0x64287f47850 mask=0<>
> 
> This likely points to the readdir call in globit() before globit() recurses:
> https://github.com/openbsd/src/blob/master/bin/ksh/eval.c#L1089-L1102

Well:

AC_LINK_IFELSE(
  [AC_LANG_PROGRAM([#include ], [
  return(0);
  ])],
  [CFLAGS_SANITIZE="$CFLAGS"], 
[CFLAGS_SANITIZE="ADDRESS_SANITIZER_NOT_SUPPORTED*"])

This works around the bug:

diff --git configure.ac configure.ac
index 0d22ad59b..f670bde1b 100644
--- configure.ac
+++ configure.ac
@@ -495,7 +495,7 @@ dnl check for sanitize build warnings support
 dnl 
 AC_MSG_CHECKING([compiler/linker address santizer build warnings support])
 
-CFLAGS_SANITIZE_TRY="$CFLAGS_SANITIZE -W -Wall -Wno-unused-parameter 
-Wno-sign-compare -Wno-implicit-fallthrough -Wno-missing-field-initializers 
-Wno-shift-negative-value -Wno-old-style-declaration 
-Wno-unused-but-set-parameter"
+CFLAGS_SANITIZE_TRY="'$CFLAGS_SANITIZE' -W -Wall -Wno-unused-parameter 
-Wno-sign-compare -Wno-implicit-fallthrough -Wno-missing-field-initializers 
-Wno-shift-negative-value -Wno-old-style-declaration 
-Wno-unused-but-set-parameter"
 CFLAGS_SAVED="$CFLAGS"
 CFLAGS="$CFLAGS_SANITIZE_TRY"
 

Re: ksh very slow compared to bash when running ghostscript's ./configure script

[Theo Buehler]

> I don't know what's causing this. Is there some algorithm inside ksh
> that could be running into complexity issues somehow?

Likely glob. Many glob implementations were found to suffer from
complexity issues: https://research.swtch.com/glob

The glob(3) in libc was fixed
https://github.com/openbsd/src/commit/5c36dd0c22429e7b00ed5df80ed1383807532b59
but ksh's builtin glog still has the issue.

A quick ktrace seems to confirm that (I terminated the shell after it
hung a while):

 58829 sh   5.883025 RET   getdents 1832/0x728
 58829 sh   40.637429 PSIG  SIGTERM caught handler=0x64287f47850 mask=0<>

This likely points to the readdir call in globit() before globit() recurses:
https://github.com/openbsd/src/blob/master/bin/ksh/eval.c#L1089-L1102

Re: fw_update issue with colon in URL

[Theo Buehler]

On Tue, Jul 14, 2020 at 07:57:35PM +, mabi wrote:
> Hello,
> 
> I just updated from 6.6 to 6.7 and the fw_update part failed so I tried to 
> run it manually and get:
> 
> $ sudo fw_update -n
> http://firmware.openbsd.org/firmware/6.7/: no such dir
> Couldn't find updates for intel-firmware-20191115v0

One server had an incorrect config. This should be fixed now.

Re: TLSv1.3 no SNI for relayd?

[Theo Buehler]

On Wed, May 27, 2020 at 09:17:45AM -0400, Matrix Dactylopodite wrote:
> Using the protocol defaults (tlsv1.3 and tlsv1.2) in latest relayd has 
> regressed to not supporting SNI?

Thanks for the helpful and detailed report. This issue (in libssl) has
just been fixed in -current:

https://github.com/openbsd/src/commit/e4de2a75b8d7ed4398f6c5128524d6043eeab667

Re: security - preferred way to make check_access_file happy?

[Theo Buehler]

On Mon, Feb 25, 2019 at 05:14:50PM +, Stuart Henderson wrote:
> On 2019/02/25 09:13, Adam Thompson wrote:
> > > Use vipw to put 13 * in the password field
> > > 
> > > From passwd(5)
> > > [...]
> > >  authentication, conventionally have 13 asterisks in the password field.
> > 
> > Thank you!  Now that I know what I'm looking for, I can see the relevant
> > code in security(8), too.
> > 
> > I wonder if there's a way for ports to do that for me while calling useradd?
> > Another rabbit hole to go down.
> > 
> > Thanks again,
> > -Adam
> > 
> 
> It normally does already. Do you have an unusual "password" line in 
> /etc/usermgmt.conf?

I think the user(8) behavior changed in that regard in user.c rev 1.112
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/user/user.c.diff?r1=1.111=1.112

@@ -1130,16 +1082,8 @@
warnx("Warning: home directory `%s' doesn't exist, and -m was"
" not specified", home);
}
-   if (up->u_password != NULL && valid_password_length(up->u_password)) {
-   (void) strlcpy(password, up->u_password, sizeof(password));
-   } else {
-   (void) memset(password, '*', DES_Len);
-   password[DES_Len] = 0;
-   if (up->u_password != NULL) {
-   warnx("Password `%s' is invalid: setting it to `%s'",
-   up->u_password, password);
-   }
-   }
+   (void) strlcpy(password, up->u_password ? up->u_password : "*",
+   sizeof(password));
cc = snprintf(buf, sizeof(buf), "%s:%s:%u:%u:%s:%lld:%lld:%s:%s:%s\n",
login_name,
password,

OpenBSD Errata: June 14th, 2018 (libcrypto)

[Theo Buehler]

Errata patches for libcrypto have been released for OpenBSD 6.3 and 6.2.

DSA and ECDSA signature generation can potentially leak secret information
to a timing side-channel attack.

Binary updates for the amd64, i386, and arm64 platforms are available via
the syspatch utility. Source code patches can be found on the respective
errata pages:

  https://www.openbsd.org/errata62.html
  https://www.openbsd.org/errata63.html

For users running 6.3, the syspatches will be delayed approximately two days.
Use the source code patch if you need the fix before then.

Re: The compiler error about modifying libcrypto

[Theo Buehler]

On Thu, May 31, 2018 at 10:50:35AM +0800, Nan Xiao wrote:
> My OS is OpenBSD 6.3.

-current?

If not, please install the latest snapshot before trying to build
-current from source.

See also https://www.openbsd.org/faq/current.html

>   Since now the -current modify the interface of
> libcrypto, there is error in "make":
> ..
> ===> lib/libcrypto

Don't do "make" from /usr/src.

Please read https://man.openbsd.org/release.8 and follow at least
up through step 3.

If you have things prepared as described in release(8) and you do
"make build", it will do "make includes" and install the current
headers, thus preventing the compilation failure you ran into.

Re: is there foomatic-rip for lpd on openBSD 6.3?

[Theo Buehler]

On Tue, Apr 10, 2018 at 09:28:53AM +0200, Rudolf Sykora wrote:
> Dear Predrag,
> 
> > Around here we actually read man pages and pkg-readmes
> 
> I do read man pages. But 1) As far as I can tell, you will not find any
> information anywhere about foomatic-rip (or any other smart filter)

use the pkglocatedb package:
https://www.openbsd.org/faq/faq15.html#PkgFind

Re: FAQ6 patch for Shared Address Space / VMM

[Theo Buehler]

> The FAQ6 section for VMM Networking incorrectly specified the range
> for Shared Address Space. RFC6598 section 7 calls out 100.64.0.0/10

fixed, thanks

Re: pkg using "6.3" instead of "snapshots"

[Theo Buehler]

On Sat, Mar 24, 2018 at 08:35:05AM +0100, Tony Boston wrote:
> I have to add that I know I would use -Dsnap as a flag. It's just that I
> didn't need to in the past. That's why I was wondering if something has
> changed here

It's the point in time where -current is in release mode (after being
-beta for a while) to prepare for the next release.

At that point there is no way for pkg_add or the system in general to
know whether your machine is running current or release. Therefore you
need to use -D snap until the kernel says -current again.  This happens
in every release cycle and lasts roughly two weeks.

Re: SHA256.sig not contained in install62.iso

[Theo Buehler]

On Tue, Feb 20, 2018 at 12:56:06PM +0100, Nicolas Schmidt wrote:
> Hi,
> 
> I am finally getting around to upgrading 6.1->6.2. When I try to install from 
> CD using the install62.iso image, the install script complains that it can't 
> find SHA256.sig (indeed, it's on it).
> 
> Is that supposed to happen?

Yes. The last paragraph from
https://www.openbsd.org/faq/faq4.html#Download says:

The installXX.iso and installXX.fs images do not contain an SHA256.sig
file, and the installer will complain that it can't check the
signatures. It is not possible for the installer to verify the sets with
these images. After all, if someone were to make a rogue installXX.iso
file, they could certainly change the installer to say the files were
legitimate. Thus, you must verify those installer downloads separately.

Re: make release-sets - question

[Theo Buehler]

On Sun, Feb 18, 2018 at 03:13:35PM -0500, Jiri B wrote:
> Hello,
> 
> I try to understand why 'release-sets' does copy kernel.tgz from DESTDIR
> into OS /usr? Could anybody explain the logic behind?

This ensures that the build machine will have a snapshot kernel on next
reboot. The /usr/libexec/reorder_kernel script will untar this and
link a new /bsd with it.

Re: pfstat not generating graphs after upgrading to -current

[Theo Buehler]

On Thu, Feb 15, 2018 at 12:29:23AM +, Stuart Henderson wrote:
> On 2018-02-14, Glenn Faustino  wrote:
> > Hi,
> >
> >
> >> Did you upgrade your packages after upgrading to -current? Can you
> >> share your /etc/pfstat.conf?
> >
> > Every time I upgrade to -current I also update packages.
> 
> Try forcing pfstat to update (pkg_delete and pkg_add maybe, if that
> doesn't help then build it yourself from ports). If that helps then let
> me know because we need to figure out what change necessitated this and
> track down which ports need REVISION bumps to force updates..

Henning's SYN-cookies came with an ABI break in the ioctl path for
/dev/pf (after it was committed, at least pfctl and pflogd needed to be
rebuilt).

This diff seems to fix pfstat{,d} for me, but only superficially tested,
as I don't use the port normally. It adds a missing header for time(3).

Index: pfstat/Makefile
===
RCS file: /var/cvs/ports/net/pfstat/Makefile,v
retrieving revision 1.38
diff -u -p -r1.38 Makefile
--- pfstat/Makefile 11 Jan 2018 19:27:07 -  1.38
+++ pfstat/Makefile 14 Feb 2018 04:03:20 -
@@ -9,8 +9,8 @@ PKGNAME-main=   ${DISTNAME}
 PKGNAME-daemon=${DISTNAME:S/-/d-/}
 CATEGORIES=net
 MASTER_SITES=  http://www.benzedrine.ch/
-REVISION-daemon=2
-REVISION-main= 1
+REVISION-daemon=3
+REVISION-main= 2
 
 HOMEPAGE=  http://www.benzedrine.ch/pfstat.html
 
Index: pfstat/patches/patch-pfstat_c
===
RCS file: pfstat/patches/patch-pfstat_c
diff -N pfstat/patches/patch-pfstat_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ pfstat/patches/patch-pfstat_c   14 Feb 2018 04:06:57 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+Index: pfstat.c
+--- pfstat.c.orig
 pfstat.c
+@@ -44,6 +44,7 @@ static const char rcsid[] = "$Id: pfstat.c,v 1.2 2010/
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #include "data.h"

Re: trouble while building a release

[Theo Buehler]

On Wed, Jan 03, 2018 at 06:07:36PM +, Etienne wrote:
> Hello list,
> 
> I'm a bit confused. I believe I have correctly applied the instructions in
> release(8), but I hit this error when running "make release" in paragraph 4,
> on unmodified sources:
> 
> # cd /usr/src/etc && make release
> […]
> sh /usr/src/sys/conf/newvers.sh
> touch: version: Permission denied
> /usr/src/sys/conf/newvers.sh[84]: cannot create version: Permission denied

You probably didn't do 'rm -rf /usr/obj/*' after building and installing
the kernel (first sentence in second paragraph of step 3 in release(8)):

   3. Build a new base system
 The build process will place the object files in a tree under /usr/obj.
 This directory must be owned by build:wobj with mode 770.

 The first time, the /usr/obj directory must be cleaned out completely
 before proceeding to avoid permission issues.  After a successful release
 build, this is no longer needed.

The /usr/src/sys/arch/amd64/compile/GENERIC{,.MP}/obj/vers* files must
be readable and writable by the 'build' user for a release to build
successfully. If you don't want to start over, you should be able to set
their permissions manually to build:wobj 660 and issue 'make release'
again.

Re: support new

[Theo Buehler]

On Sat, Dec 30, 2017 at 12:18:18AM -0600, Abel Abraham Camarillo Ojeda wrote:
> 0
> C Mexico
> P Nuevo Leon
> T Monterrey
> Z 67113
> O Abel Abraham Camarillo Ojeda
> I
> A La pradera 314, Guadalupe
> M supp...@verlet.org
> U
> B
> X
> N Over 9 years of experience with OpenBSD. Infrastructure, networking
> and software consulting and development; strong focus on UNIX,
> specially OpenBSD and Linux.
> 

added. thanks

Re: support update

[Theo Buehler]

On Wed, Dec 20, 2017 at 09:54:56PM +0300, Kihaguru Gathura wrote:
> Please use the latter submission also copied below to update my profile.
> Kindly note email has changed.

i committed the information below.

> 
> On Tuesday, December 19, 2017, Kihaguru Gathura  wrote:
> > 0
> > C Kenya
> > P Nairobi
> > T Nairobi
> > Z P.O. Box 30164-00100
> > O PQscript
> > I
> > A Bishops Road
> > M pqscr...@gmail.com
> > U
> > B +254 706970697
> > X
> > N OpenBSD consulting. Speciality in web applications
> > development with OpenBSD-httpd web server, PostgreSQL DBMS, FastCGI
> protocol and C programming language.
> >

Re: Manual to cd (change working directory)

[Theo Buehler]

On Wed, Dec 13, 2017 at 10:22:32PM +0100, Freddy Fisker wrote:
> Hi
> 
> I can't get the manual to the cd (change working directory) command. When I
> am trying, I get the manual to cd (ATAPI and SCSI CD-ROM driver) instead.
> 
> It's the same with: man cd
> 
> and in: https://man.openbsd.org/cd

There's no manual for cd, as it's a shell built-in.  You need to consult
the manual of your shell for more info. The sh(1), ksh(1) and csh(1)
pages all contain a few paragraphs on cd.

> Best regards
> Freddy
> 

Re: cvs diff FAQ Ports Testing

[Theo Buehler]

> if I understand correctly: provide a short explanation, isn't-it?!

exactly.

> > yeah, the spacing around = in that file is somewhat arbitrary and
> > inconsistent. i'll have to think a bit what to do there. this one patch
> > doesn't really solve the problem, so i won't commit it as-is.
> OK.
> How can i help?

on second thought: i committed your diff. this tab looked too odd. the
other whitespace is somewhat inconsistent, but it isn't too bad. i'll
let it be. thanks, but i don't think you can help with that.

Re: cvs diff FAQ Ports Testing

[Theo Buehler]

> A new diff for page FAQ > Ports > Testing.

thanks, i committed this one. note that the path to the file is already
listed four times below, so the above info is not particularly useful :)

it would be more helpful if you said what you intend to do, like "remove
an extra closing parenthesis".

> Index: faq/ports/testing.html
> ===
> RCS file: /cvs/www/faq/ports/testing.html,v
> retrieving revision 1.37
> diff -u -p -r1.37 testing.html
> --- faq/ports/testing.html16 Oct 2017 21:21:27 -  1.37
> +++ faq/ports/testing.html22 Nov 2017 17:55:43 -


> Previously, i mailed other diff, who has remained unanswered.

yeah, the spacing around = in that file is somewhat arbitrary and
inconsistent. i'll have to think a bit what to do there. this one patch
doesn't really solve the problem, so i won't commit it as-is.

Re: [www] fix a link

[Theo Buehler]

On Mon, Nov 20, 2017 at 10:47:42PM +0100, Julien Steinhauser wrote:
> The link is leading to group.8, let it lead to group.5

fixed, thanks

Re: Transition from machdep.lidsuspend to machdep.lidaction?

[Theo Buehler]

On Sat, Nov 18, 2017 at 09:47:41PM +0100, pledge wrote:
> Hello
> 
> I just upgraded my laptop 6.1 -> 6.2.
> 
> Suddenly it appears that the sysctl setting machdep.lidsuspend was gone.
> 
> I checked the whats new site https://www.openbsd.org/62.html and
> https://www.openbsd.org/faq/upgrade62.html but found no information there.
> Interestingly, on https://www.openbsd.org/faq/upgrade61.html there is this
> note:
> 
> "*sysctl machdep.lidsuspend renamed to machdep.lidaction.* The
> machdep.lidsuspend sysctl variable has been renamed to machdep.lidaction.
> Setting it to 2 hibernates the machine when the lid is closed. Update
> sysctl.conf(5)  to use
> the new name."
> 
> So it appears that this note was on the wrong page? Since I was using it on
> 6.1 it can't have been renamed.

It was deprecated during the 6.1 release cycle

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/machdep.c#rev1.224

and accordingly, its deprecation was announced on upgrade61.html. The
machdep.lidsuspend sysctl was left functioning to ease the transition.

During the 6.2 release cycle it was definitely removed:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/machdep.c#rev1.231

> Also, where can I find documentation about what more options there are to
> machdep.lidaction?

The machdep sysctls are only briefly explained in comments in
/etc/examples/sysctl.conf, as sysctl(3) is already very long.

Here are the machdep sysctls for amd64:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/etc.amd64/sysctl.conf?annotate=1.7

Re: Advanced Programming in the Unix Environment 3rd Edition

[Theo Buehler]

fixed, thanks

Re: CVS Diff : FAQ Ports Guide (3)

[Theo Buehler]

On Sat, Nov 11, 2017 at 02:25:34PM +, Stuart Henderson wrote:
> On 2017-11-11, Stephane HUC "PengouinBSD"  wrote:
> > This is a multi-part message in MIME format.
> > --E3282A62CBBAFE07DF2ABE41
> > Content-Transfer-Encoding: 7bit
> > Content-Type: text/plain; charset=utf-8
> >
> > Hi, all...
> >
> > A new diff for this same page : A very small modification for a better
> > pagination... into section "Generic Porting Hints".
> >
> >
> 
> Hmm, this doesn't change anything?

I added "whitespace: pre;" to the  tags in openbsd.css, since in at
least 99% of the cases that's what we want. Looks like I havent found
all of the  tags that need fixing...

Re: Error : page Ports - Working with Ports

[Theo Buehler]

On Tue, Nov 07, 2017 at 12:41:22PM +0100, Stephane HUC "PengouinBSD" wrote:
> 
> 
> Le 11/07/17 à 12:34, Rodrigo Mosconi a écrit :
> (...)
> >> "
> >> By twice: "make install will only install the main subpackage". Normal?
> >>
> > 
> > [make install] is a command that is writen in the shell.  realize that is
> > in mono-spaced font, so it is something from terminal
> > 
> > 
> 
> I'm sorry, but you didn't understand me.
> I like to point out that it is written twice, as an unfortunate
> repetition. Normal?

I dunno. Seems pretty normal to me. If I read this correctly, there's a
one-line summary with the most important info, which is expanded on a
few lines later.

Please, if you really want to help, use the link sent by someone else a
few days ago and learn how to send a diff.

This will:

a) indicate clearly what you are talking about without you having to
   scramble to explain what you mean
b) force you to propose a solution, so it's easy to understand what you
   think is wrong
c) allow me (or someone else) to apply, tweak and commit the fix if it
   makes sense.

In the long run, this will save a lot of headache and time.

Re: How help about to review FAQ?

[Theo Buehler]

On Sat, Nov 04, 2017 at 10:49:57PM +0100, Stephane HUC "PengouinBSD" wrote:
> Thank you! :D
> 
> Do I have to create a new mail with just the page name to put the
> corrections proposals I was talking about "OpenBSD/macppc" page?

Not necessary. I fixed both typos you found. Thanks!

(note that this is not the faq, though)

Re: FAQ14: Growing disk partitions: fdisk

[Theo Buehler]

> => But then why is it written in the FAQ this below, since it doesn't
> seem to work? (at least with stable amd64 OpenBSD)

i tested it before giving my ok, but apparently i overlooked this detail.
fixed, thanks

Re: sysmerge is not needed when updating to 6.2?

[Theo Buehler]

> But I have only one question: Is sysmerge not longer needed for
> updating process like in previous releases?

Since 6.0 the installer installs an rc.sysmerge that runs 'sysmerge -b'
on first boot of the updated system.

Re: [diff] A few typos in www/faq

[Theo Buehler]

On Fri, Sep 15, 2017 at 05:16:15PM +, Lubos Boucek wrote:
> Hello,
> 
> I've found a few typos in www/faq, diff below.

Fixed, thanks!

Unfortunately, your patch was mangled, so I had to make the changes
manually. I think it's because you have some kind of wrapping of long
lines enabled.

Re: Can't get cvs checkout for src and ports as a normal user to work

[Theo Buehler]

On Tue, Sep 12, 2017 at 07:04:54PM +, Lea Chescotta wrote:
> Hi, i'd trying to make a checkout of the sources and ports to my fresh 
> openbsd 6.1 install, following this guide 
> https://www.openbsd.org/anoncvs.html but when i try to make the checkout i 
> get some errors.
> 
> I did this steps as root:
> # user mod -G wsrc usuario

In https://www.openbsd.org/faq/faq5.html#wsrc it says after a similar
command (with exampleuser in place of usuario):

"This change takes effect with exampleuser's next login."

Given that the permissions you display below are ok, I suggest you try
again with a freshly logged in shell for usuario.

> # cd /usr
> # mkdir -p   xenocara ports src
> # chgrp wsrc xenocara ports src
> # chmod 775  xenocara ports src
> 
> And as a normal user:
> $ cd /usr
> $ ls -la
> total 92
> drwxrwxr-x  18 root   wsrc512 Sep 12 11:32 .
> drwxr-xr-x  13 root   wheel   512 Sep  8 13:50 ..
> drwxr-xr-x   7 root   wheel   512 Apr  1 17:06 X11R6
> drwxr-xr-x   2 root   wheel  5632 Sep  8 13:45 bin
> drwxr-xr-x   2 root   wheel  1024 Sep  7 11:20 games
> drwxr-xr-x  28 root   bin3072 Sep  7 11:20 include
> drwxr-xr-x   6 root   wheel  3072 Sep 12 05:18 lib
> drwxr-xr-x   5 root   wheel   512 Sep  7 11:20 libdata
> drwxr-xr-x   6 root   wheel  1024 Sep  7 11:20 libexec
> drwxr-xr-x  11 root   wheel   512 Sep 12 12:21 local
> drwxr-xr-x   2 root   wheel   512 Apr  1 16:39 mdec
> drwxrwx---   2 build  wobj512 Sep  7 11:19 obj
> drwxrwxr-x  34 root   wsrc   1024 Sep 12 11:29 ports
> drwxr-xr-x   2 root   wheel  4096 Sep  8 13:45 sbin
> drwxr-xr-x  16 root   wheel   512 Apr  1 16:39 share
> drwxrwxr-x   2 root   wsrc512 Sep 12 11:28 src
> drwxrwxr-x   2 root   wsrc512 Sep 12 11:32 xenocara
> drwxrwx---   2 build  wobj512 Sep  7 14:34 xobj
> 
> But, when i try to cvs checkout:
> $ cvs -qd anon...@obsdacvs.cs.toronto.edu:/cvs checkout -rOPENBSD_6_1 -P src
> cvs checkout: warning: cannot make directory CVS in .: Permission denied
> cvs checkout: in directory src:
> cvs checkout: cannot open CVS/Entries for reading: No such file or directory
> cvs checkout: cannot open CVS/Tag: No such file or directory
> cvs checkout: cannot open CVS/Tag: No such file or directory
> cvs checkout: cannot write src/Makefile: Permission denied
> cvs checkout: cannot write src/Makefile.cross: Permission denied
> cvs checkout: cannot open CVS/Tag: No such file or directory
> cvs [checkout aborted]: cannot make directory src/bin: No such file or 
> directory

Re: What to do when package does not work in snapshot?

[Theo Buehler]

On Mon, Sep 04, 2017 at 11:38:48AM +0200, Niels Kobschätzki wrote:
[...]
> In the FAQ there is a link to "Report porblems" which just links to
> itself.
[...]

Could you be more specific where this link is? I'd like to fix it, but
couldn't find it.

Re: resolve.conf overwritten woes

[Theo Buehler]

On Sat, Aug 12, 2017 at 07:49:22PM -0700, jungle Boogie wrote:
> I think I saw it and there was a typo with resolveor section.

thanks, but unfortunately i have no idea what you mean. could you please
be more specific?

Re: resolve.conf overwritten woes

[Theo Buehler]

On Fri, Aug 11, 2017 at 11:12:52PM -0700, jungle boogie wrote:
> Hi All,
> 
> 
> From this page:
> https://www.openbsd.org/faq/faq6.html#Setup
> 

krw pointed out that the documentation got this pretty much entirely
wrong and provided a fix. it will be online shortly.

sorry for the inconvenience.

Re: OT: protonmail mail body

[Theo Buehler]

On Wed, Jul 12, 2017 at 04:54:24AM -0400, Rupert Gallagher wrote:
> +1

Alright, the base64 transfer encoding thing is in the RFC...

However, nowhere does the RFC specify that you should top-post and strip
all the newlines:

> On Wed, Jul 12, 2017 at 10:09 AM, Alarig Le Lay  wrote:
> 
> > On mer. 12 juil. 10:37:59 2017, Mihai Popescu wrote: > Hello, > > I preffer 
> > to keep it calm, but some people on the list are using > protonmail and 
> > their mails are impossible to read directly on the > list. I think they are 
> > destroying the list, maybe they should turn > that feature off. Here is 
> > what I see reading on marc.info: > > 
> > TmV2ZXIgaGVhcmQgb2YgVk5DPwpTZW50IGZyb20gUHJvdG9uTWFpbCBNb2Jp > 
> > bGUKCk9uIFR1ZSwgSnVsIDExLCAyMDE3IGF0IDg6MzkgUE0sIE5pZWxzIEtv > 
> > YnNjaMOkdHpraSA8bmllbHNAa29ic2NoYWV0emtpLm5ldD4gd3JvdGU6Cgo+ > 
> > IEhpLCBJIGFtIHBvbmRlcmluZyB0byBpbnN0YWxsIE9wZW5CU0Qgb24gbXkg > 
> > bWFpbiBtYWNoaW5lLiBCdXQgSSBqdXN0IGZvdW5kIGEgcG9zc2libGUgc2hv > 
> > d3N0b3BwZXI6IGZhbWlseSByZW1vdGUgc3VwcG9ydCBSaWdodCBub3cgSSBh > 
> > bSB1c2luZyBUZWFtdmlld2VyIHRvIGNvbm5lY3QgZnJvbSBteSBMaW51eC1t > 
> > YWNoaW5lIHRvIHRoZSBmYW1pbHktTWFjLiBOb3cgSSBhbSBzZWFyY2hpbmcg > 
> > YSBzaW1pbGFyIGVhc3kgd2F5IHRvIGRvIHRoYXQgZnJvbSBhIHBvc3NpYmxl > 
> > IE9wZW5CU0QtbWFjaGluZS4gSXMgdGhlcmUgYW55IHNvZnR3YXJlIHRoYXQg > 
> > Y291bGQgZG8gdGhhdD8gQXNraW5nIHRoZW0gZm9yIHRoZWlyIElQIG9yIGlD > 
> > bG91ZC1ob3N0bmFtZSB3b3VsZCBhbHJlYWR5IGJlIHRvbyBjb21wbGljYXRl > 
> > ZC4gV2hhdCBhcmUgeW91IHVzaW5nIGluIHN1Y2ggY2FzZXM/IElzIGEgUUVN > 
> > VS1WTSBwZXJmb3JtYW50IGVub3VnaCBmb3Igc3VjaCBhIHRoaW5nIChJIGhh > 
> > dmUgYSBUaGlua3BhZCBUNDYwIHdpdGggYSBTa3lsYWtlLWk1KSBOaWVscw== Hello, It’s 
> > just Base64 Content-Transfer-Encoding, and it’s part of rfc2045. 
> > https://tools.ietf.org/html/rfc2045#section-6.8 So, the problem is on 
> > marc.info side. Moreover, it’s working on mutt and on mail-archive: 
> > https://www.mail-archive.com/misc@openbsd.org/msg154853.html -- alarig

Re: KARL not sending email?

[Theo Buehler]

On Mon, Jul 10, 2017 at 07:44:19PM -0700, jungle boogie wrote:
> Hi All,
> 
> I just updated from the 6th of July snapshot to the 10th of July.
> When I logged in and check the mail, I didn't see a message advising a new
> kernel link. Between the 6th and 10th I rebooted my machine many times and
> didn't see the mail.
> 
> Are the mails no longer expected? How do I verify the kernel re-linking is
> actually in place?

The mails were replaced with syslog in etc/rc -r1.507 once we were
confident enough that it works as expected. You'll find
'Kernel relinking done' notices in your /var/log/messages. In case an
error occurs, it will additionally be logged to the console.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc#rev1.507

Re: Kernel relink failed

[Theo Buehler]

On Mon, Jul 03, 2017 at 01:05:19PM +0300, Kapetanakis Giannis wrote:
> On 03/07/17 12:45, Paul de Weerd wrote:
> > On Mon, Jul 03, 2017 at 11:52:09AM +0300, Kapetanakis Giannis wrote:
> > | Hi,
> > | 
> > | I've got this today after applying Jul 2 snapshot
> > | 
> > | sha256: cannot open /var/db/kernel.SHA256: No such file or directory
> > | sha256: /bsd does not exist in /var/db/kernel.SHA256
> > | 
> > | upgrade was "without the install kernel"
> > | https://www.openbsd.org/faq/upgrade61.html#NoInstKern
> > 
> > That is for moving from 6.0 to 6.1, for 6.1 to current snapshots, you
> > should add a step `sha256 /bsd > /var/db/kernel.SHA256` and reboot
> > (twice!).  See this ( http://marc.info/?t=14980725022=1=2 )
> > thread for some more details.
> > 
> > Paul 'WEiRD' de Weerd
> 
> I'm using the upgrade 6.0->6.1 just for the kernel info and untar (copy paste)
> Then I use -current info.
> 
> Could you please add something about it in -current
> https://www.openbsd.org/faq/current.html
> 
> So it should be something like this?
> #part1
> put new kernels
> extract new .tgz
> #part2
> sha256 -h /var/db/kernel.SHA256 /bsd
> cd /usr/share/compile/GENERIC.MP (replace kernel version here)
> make newbsd
> make newinstall
> reboot (once)
> 
> I did #part2 after the upgrade
> ?

This is a dangerous way to do it: you're running the new userland on an
old kernel.  In particular, this approach will very likely spell trouble
for a 6.1 -> 6.2 upgrade. These are among the reasons why I suggest what
I suggested (with two reboots).

The manual upgrade method is generally not recommended and not really a
supported way to run -current. Therefore, I don't think I want to add
something to current.html.

Re: Kernel relink failed

[Theo Buehler]

On Mon, Jul 03, 2017 at 11:52:09AM +0300, Kapetanakis Giannis wrote:
> Hi,
> 
> I've got this today after applying Jul 2 snapshot
> 
> sha256: cannot open /var/db/kernel.SHA256: No such file or directory
> sha256: /bsd does not exist in /var/db/kernel.SHA256
> 
> upgrade was "without the install kernel"
> https://www.openbsd.org/faq/upgrade61.html#NoInstKern

Thanks. It's a known issue that was briefly discussed here:

https://marc.info/?l=openbsd-tech=149821809527605=2

also:

https://marc.info/?l=openbsd-cvs=149821856027706=2

I will think about a better solution for this problem once the design
of KARL has stabilized (there are further steps that are planned).

For the moment, I suggest that you compute the kernel hash by hand
with

sha256 -h /var/db/kernel.SHA256 /bsd

*after* installing the new kernels but *before* extracting the userland.

After a reboot, rc(8) will do the rest of the cleanup since the hash
will be correct. Once you get the 'kernel relink info' mail, reboot
once more to run a unique kernel.

If you want to avoid the second reboot you'll need to study
reorder_kernel() in /etc/rc.

Re: Correct tftpproxy in faq/pf/ftp.html

[Theo Buehler]

On Tue, Jun 20, 2017 at 10:35:14AM +0200, Martin Ziemer wrote:
> Since OpenBSD 5.3 the tftpproxy is no longer startet via inetd, but as
> a daemon. The faq section in ftp.html still instructs you to use
> inetd.
> 
> Below is a diff which instructs the reader to use the service instead
> of inetd.

Committed, thanks!

sthen pointed out that the pf rules were in need of some fixing as
well, so I did that in addition to your diff.

Re: Correct tftpproxy in faq/pf/ftp.html

[Theo Buehler]

On Tue, Jun 20, 2017 at 10:35:14AM +0200, Martin Ziemer wrote:
> Since OpenBSD 5.3 the tftpproxy is no longer startet via inetd, but as
> a daemon. The faq section in ftp.html still instructs you to use
> inetd.
> 
> Below is a diff which instructs the reader to use the service instead
> of inetd.

Could someone familiar with the matter please confirm this?

Thanks

> 
> Index: ftp.html
> ===
> RCS file: /cvs/www/faq/pf/ftp.html,v
> retrieving revision 1.60
> diff -u -p -r1.60 ftp.html
> --- ftp.html15 Jan 2017 11:33:04 -  1.60
> +++ ftp.html20 Jun 2017 08:29:20 -
> @@ -243,16 +243,12 @@ The rules above allow TFTP outbound from
>  servers on the external network.
>  
>  
> -The last step is to enable tftp-proxy in
> -http://man.openbsd.org/inetd.conf;>inetd.conf(5) so that it
> -listens on the same port that the divert-to rule specified above,
> -in this case 6969.
> +The last step is to enable and start tftp-proxy(8).
>  
>  
> -127.0.0.1:6969  dgram   udp   wait  root  /usr/libexec/tftp-proxy tftp-proxy
> +# rcctl enable tftpproxy
> +# rcctl start  tftpproxy
>  
> -
> -Unlike ftp-proxy(8), tftp-proxy(8) is spawned from inetd.
>  
>  
>  
> 

Re: siteXX.tgz with /home/user/.ssh/authorized_keys results in empty file

[Theo Buehler]

> >How about not overwriting already existing files?
> >
> >Index: install.sub
> >===
> >RCS file: /var/cvs/src/distrib/miniroot/install.sub,v
> >retrieving revision 1.1011
> >diff -u -p -r1.1011 install.sub
> >--- install.sub  28 May 2017 09:24:56 -  1.1011
> >+++ install.sub  30 May 2017 00:18:16 -
> >@@ -2919,7 +2919,7 @@ do_install(){
> > 
> > _home=/mnt$_home
> > mkdir -p $_home
> >-(cd /mnt/etc/skel; cp -pR . $_home)
> >+(cd /mnt/etc/skel; pax -rw -k -pe . $_home)
> 
> If that's what it does, I'm all for it. 

It is: -rw is copy mode, -k keeps existing files, -pe preserves owners,
permissions, times, etc like cp -p.

I committed the diff, so it should be fixed in the next snapshot.

Re: Typo in the mg tutorial

[Theo Buehler]

On Wed, May 24, 2017 at 04:47:18PM -0400, Choose a display name wrote:
> mg tutorial contains some "M-x open-file" command, but mg has only
> "M-x find-file" command as far as I can see.

Fixed, thanks

Re: siteXX.tgz with /home/user/.ssh/authorized_keys results in empty file

[Theo Buehler]

From: Theo Buehler <t...@math.ethz.ch>
Cc: 
Bcc: 
Subject: Fwd: siteXX.tgz with /home/user/.ssh/authorized_keys results in empty
 file
Reply-To: 
In-Reply-To: <f34cb3c3904e4804e52555201c297f97.squir...@mail.kagu-tsuchi.com>

On Mon, May 29, 2017 at 07:16:06PM -0400, trondd wrote:
> On Mon, May 29, 2017 5:47 pm, Erling Westenvik wrote:
> > What is going on? Why is the process extracting siteXX.tgz
> > treating /mnt/home/user/.ssh different than /mnt/root/.ssh?

[...]

> My guess is this is an install.  The installer seems to unpack the sets
> first.  Including the site taball.  Then, if you created a new user,
> copies the /etc/skel/ files over, overwriting your authorized_keys file. 
> You'll need to use install.site or /etc/rc.firsttime
> 
> Root is different because root's files are part of the distribution sets.

Populating the $ADMIN's $_home with some files from siteXX.tgz looks
like a legitimate use case to me, especially for authorized_keys, but
also for the dotfiles in /etc/skel.

How about not overwriting already existing files?

Index: install.sub
===
RCS file: /var/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1011
diff -u -p -r1.1011 install.sub
--- install.sub 28 May 2017 09:24:56 -  1.1011
+++ install.sub 30 May 2017 00:18:16 -
@@ -2919,7 +2919,7 @@ do_install(){
 
_home=/mnt$_home
mkdir -p $_home
-   (cd /mnt/etc/skel; cp -pR . $_home)
+   (cd /mnt/etc/skel; pax -rw -k -pe . $_home)
(umask 077 && sed "s,^To: root\$,To: ${ADMIN_NAME} <${ADMIN}>," 
\
/mnt/var/mail/root >/mnt/var/mail/$ADMIN )
chown -R 1000:1000 $_home /mnt/var/mail/$ADMIN

Re: Difficulties with the sh manual page

[Theo Buehler]

On Thu, May 25, 2017 at 09:03:43AM +0200, Otto Moerbeek wrote:
> On Wed, May 24, 2017 at 04:27:06PM -0400, Choose a display name wrote:
> 
> > I don't quite understand the description of the PPID in the sh manual.
> > 
> > >PPID The shell's parent process ID. Subshells have the same
> > > PPID as the parent of the current shell.
> > 
> > PPID is the shell's parent's pid, okay (by the way, shouldn't the
> > second "'s" be added?). But, according to the next sentence, subshells
> > have the same value in their PPIDs as the current shell's parent have
> > in its PPID. Is it correct?
> 
> Yes, 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18

I think the point is that the current phrasing in sh(1) is incorrect.
POSIX says this:

In a subshell [...], PPID shall be set to the same value as that
of the parent of the current shell.

and sh(1) says this:

Subshells have the same PPID as the parent of the current shell.

I think either we should say something more explicit like

The PPID in a subshell is the PID of the parent of the current
shell.

or we drop "the parent of":

Index: sh.1
===
RCS file: /var/cvs/src/bin/ksh/sh.1,v
retrieving revision 1.141
diff -u -p -r1.141 sh.1
--- sh.116 Mar 2017 20:06:37 -  1.141
+++ sh.125 May 2017 07:31:53 -
@@ -2091,7 +2091,7 @@ Enable POSIX mode
 The shell's parent process ID.
 Subshells have the same
 .Ev PPID
-as the parent of the current shell.
+as the current shell.
 .It Ev PS1
 User prompt displayed every time an interactive shell
 is ready to read a command.

Re: ansible-playbook: Permission denied

[Theo Buehler]

> Now the mistery is how was I able to use ansible before 6.1 release
> without wxallowed on 

The semantics of wxallowed were made stricter during the 6.1 release
cycle. It was possible to run python on 6.0 without wxallowed (it would
be killed on violation), on 6.1 the kernel refuses to execute python if
it's not started from a wxallowed partition.

More details here:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/www/faq/current.html?rev=1.699=text/html

Re: faq5 and release.8 documentation adding wobj group

[Theo Buehler]

On Sun, May 21, 2017 at 07:47:59AM +0800, harold felton wrote:
> Hello,
> 
> I am unsure whether this has already been addressed.
> the documentation at faq5 and release.8 are slightly
> outdated.  For a non-root user, there should be another
> step besides only adding them to the wsrc-group.

This is one way that you can avoid running cvs as root.

> Typically, this non-root user is already in group-wheel.
> The instructions currently mention that they should be
> in group-wsrc, but they should also be in group-wobj.

This is not needed for 'make build' or 'make release', therefore I chose
not to mention it in the "building from source" section of faq5.

I did mention why that might be a useful thing to do here:
https://www.openbsd.org/faq/faq5.html#Miscellanea
and also on upgrade61.html.

> The relevant command is simply:
> 
> # *user mod -G wobj exampleuser*
> 
> as seen at https://www.openbsd.org/faq/faq5.html#Bld
> which then references release.8 step-2.
> 
> I do not know where/how to check for documentation
> that might be changing under -current.

The faq is updated within about half an hour after a commit is made. For
-current manuals, you can use http://man.openbsd.org

> Sincerely, hfelton
> 
> ps - I have followed the mailing-lists for awhile and
> would reference the following researched items:
> message to source-changes from 20170412 id:
> aca921a291cf2...@openbsd.org

This is when I added https://www.openbsd.org/faq/faq5.html#Miscellanea
mentioned above.

> similar, but unrelated-bug from 20170116 at:
> http://marc.info/?l=openbsd-bugs=148459605014161=2

This was fixed a week or two after that conversation:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/mk/bsd.obj.mk#rev1.17

Re: build amd64 kernel fails

[Theo Buehler]

On Thu, May 11, 2017 at 09:18:05AM +0200, Heiko wrote:
> Hello List,
> 
> I get this error:
> 
> uvm_init.o: In function `uvm_init':
> /sys/uvm/uvm_init.c:145: undefined reference to `uvm_km_page_lateinit'
> *** Error 1 in /sys/arch/amd64/compile/GENERIC.MP (Makefile:869 'bsd':
> @echo ld -T /sys/arch/amd64/conf/ld.script -X --warn-common -nopie -o...)
> cmp -s bsd /bsd || ln -f /bsd /obsd
> cp bsd /nbsd
> cp: bsd: No such file or directory
> *** Error 1 in /sys/arch/amd64/compile/GENERIC.MP
> 

Make sure you have /sys/uvm/uvm_km.c r1.130 before you try again.

Re: [PATCH] Installer bug (MSDOS tildes)

[Theo Buehler]

On Wed, May 10, 2017 at 12:51:45PM +, Michal Bozon wrote:
> There was a "typo" in my patch, this should be a correct one:
> 
> --- /usr/src/distrib/miniroot/install.sub.ooo   Wed May 10 12:19:56 2017
> +++ /usr/src/distrib/miniroot/install.sub   Wed May 10 12:48:31 2017
> @@ -1804,7 +1804,7 @@
>  fi
>  
>  # Always mount msdos partitions with -s to get lower case names.
> -grep -q "^  $resp: .*MSDOS" $_file && _opts="-s"
> +grep -q "^  $resp: .*MSDOS" $_file && _opts="-l"
>  mount -o ro,$_opts /dev/$_dev$resp /mnt2
>  }
> 
> I am not sure why "-s" flag is used, maybe it fixed some problem,
> but it has introduced another one.

A similar diff was briefly committed in 1.750 for the reason you mention:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub#rev750
It was backed out again in
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub#rev752

> 
> MB
> 
> 
> On 2017-05-10 Wed 12:34, Michal Bozon wrote:
> > Hi,
> > there is a typo in install.sub
> > causing problems e.g. when removable FAT32 formatted
> > disk with installation files is attached,
> > and "disk" is selected as install media:
> > 
> > INSTALL.i386 not found ...
> > (because it is visible as instal~1.i38)
> > 
> > Directory does not contain SHA256.sig ...
> > (because it is visible as sha256.sig)
> > 
> > here is the patch:
> > 
> > --- /usr/src/distrib/miniroot/install.sub
> > +++ /usr/src/distrib/miniroot/install.sub
> > @@ -1805,7 +1805,7 @@
> >  
> >  # Always mount msdos partitions with -s to get lower case names.
> >  grep -q "^  $resp: .*MSDOS" $_file && _opts="-s"
> > -mount -o ro,$_opts /dev/$_dev$resp /mnt2
> > +mount -o ro $_opts /dev/$_dev$resp /mnt2
> >  }
> > 
> > 
> > regards,
> > Michal Bozon
> 

Re: tmux fail to start when using if-shell in .tmux.conf

[Theo Buehler]

On Sat, Apr 22, 2017 at 10:35:50PM +0200, Erling Westenvik wrote:
> Hi!
> 
> After upgrading to today's snapshot (amd64, April 22) tmux refused to
> load with exit status 1 and error message 'lost server'. I quickly found the
> culprit in my .tmux.conf; a left over experimental if-shell statement I
> used a while ago when I needed nested tmux sessions:
> 
> if-shell "echo $SSH_TTY | grep /dev/ttyp" "set -g prefix C-r" "set -g prefix 
> C-Space"
> 
> After commenting out the if-shell statement tmux loads fine, but – why
> did this cause tmux not to load in the first place? Running the
> statement as a command in tmux as soon tmux is running works just fine!?

I ran into this as well; nicm fixed this bug in -current
(cmd-if-sh.c r1.54).

There was a change (cfg.c r1.56) that causes the commands in the config
file run outside of any client. A bug in the if-sh implementation led to
a NULL dereference in that situation, and this segfault killed the tmux
server (as indicated by the 'lost server' message you saw).

When run inside a tmux client, the pointer that was NULL in the previous
paragraph points to the client, and now the dereference is valid, so the
command worked properly.

Re: building release without noperm?

[Theo Buehler]

> > bash-4.4# export DESTDIR=/dest; export RELEASEDIR=/export/releasedir
> > bash-4.4# cd /usr/src/etc && make release
> > sh /usr/src/sys/conf/newvers.sh
> > touch: version: Permission denied
> > /usr/src/sys/conf/newvers.sh[84]: cannot create version: Permission denied
> > *** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP (Makefile:897 
> > 'vers.o')
> > *** Error 1 in . (Makefile:20 'bsd.mp')
> > *** Error 1 in . (Makefile:267 'release-sets')
> > *** Error 1 in . (Makefile:260 'do-release')
> > *** Error 1 in /usr/src/etc (Makefile:244 'release')
> 
> This indicates permission problems below /usr/obj (nothing to do with
> noperm).

I'm still travelling, so I can't test myself, but my suspicion is that
you haven't started 'make build' with an empty /usr/obj, as release(8)
indicates (note that building a kernel creates the /usr/obj/sys tree).

 The build process will place the object files in a tree under /usr/obj.
 This directory should be empty and owned by build:wobj with mode 770.
^^^

This is not strictly needed after the first successful 'make release'
(as the kernel obj/vers* files will have permissions at least 660), but
the first time around it is necessary, unfortunately (unless you built
the kernel with umask 007).

> What is the output of
> 
> # ls -al /usr/obj /usr/obj/sys/arch/amd64/compile/{,GENERIC.MP/vers*}

I'd still be interested in seeing the output of this for anyone who ran
into this problem.

Re: building release without noperm?

[Theo Buehler]

> On 04/14/17 09:21, Theo de Raadt wrote:
> >> AFAICS there is no way to build a release without upgrading the base 
> >> system first, i.e. you have to have root privileges.
> >> 
> >> To keep things simple, I wonder if it would be possible to use these 
> >> privileges to avoid the noperm partition?

No, it isn't.

> > noperm is now so well established, we have already forgotten the various 
> > tricks to during the transition, even moreso since there wasn't one 
> > transition it was done in steps.
> > 
> 
> ???
> 
> I would have guessed a simple
> 
>   if test "x$USER" != "xroot"; then
>   echo "error: noperm partition wanted"
>   exit 1
>   fi
> 
> would do.

There are such tests at the beginning of 'make release', so if you got
as far in 'make release' as you indicate below, your noperm setup is
fine:

$ sed -n 246,259p /usr/src/etc/Makefile
do-release:
@if [[ `id -u` -ne 0 ]]; then \
echo $@ must be called by root >&2; \
false; \
fi
@destmp=`df -P ${DESTDIR} | awk 'END { print $$6 }'`; \
if ! mount | grep -q " $${destmp} .*noperm"; then \
echo ${DESTDIR} must be on a noperm filesystem >&2; \
false; \
fi; \
if [[ `stat -f '%Su %Lp' $${destmp}` != '${BUILDUSER} 700' ]]; then \
echo $${destmp} must have owner BUILDUSER and mode 700 >&2; \
false; \
fi

> bash-4.4# export DESTDIR=/dest; export RELEASEDIR=/export/releasedir
> bash-4.4# cd /usr/src/etc && make release
> sh /usr/src/sys/conf/newvers.sh
> touch: version: Permission denied
> /usr/src/sys/conf/newvers.sh[84]: cannot create version: Permission denied
> *** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP (Makefile:897 
> 'vers.o')
> *** Error 1 in . (Makefile:20 'bsd.mp')
> *** Error 1 in . (Makefile:267 'release-sets')
> *** Error 1 in . (Makefile:260 'do-release')
> *** Error 1 in /usr/src/etc (Makefile:244 'release')

This indicates permission problems below /usr/obj (nothing to do with
noperm).

What is the output of

# ls -al /usr/obj /usr/obj/sys/arch/amd64/compile/{,GENERIC.MP/vers*}

> There are stable snapshots? Good thing, I will check.

There aren't. But you may want to check out syspatch(8)

http://man.openbsd.org/syspatch

Re: xenodm and .kshrc

[Theo Buehler]

On Fri, Apr 14, 2017 at 11:45:05AM +0800, Adam Steen wrote:
> Hi
> 
> I used to start X using startx and when opening terminal my .kshrc
> would get run,
> 
> but now i have switched to xenodm, my .kshrc is not being executed.
> 
> my .profile has "export ENV=$HOME/.kshrc"
> 
> what i am i missing?

Assuming that you use xterm: does your .Xdefaults contain

XTerm*loginShell: true

I removed the following somewhat outdated section from the FAQ because
by default it does:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/www/faq/faq8.html?rev=1.308=text/html#ksh

See also this post:

https://marc.info/?l=openbsd-misc=142829426523976=2

and the other posts in that thread.

Re: whois ends with core dump

[Theo Buehler]

On Tue, Mar 28, 2017 at 10:34:16AM +0300, Mihai Popescu wrote:
> Hello,
> 
> whois [address] ends with core dump and this message:
> 
> whois(23584) in free(): bogus pointer (double free?) 0xc588e902129
> Abort trap (core dumped)
> 
> The gdb message is this:
> 
> (gdb) core-file whois.core
> Core was generated by `whois'.
> Program terminated with signal 6, Aborted.
> #0  0x0c5ab4dc2a3a in ?? ()
> 
> This is for every address I try to use.
> 
> OpenBSD 6.1-beta (GENERIC.MP) #30: Thu Mar 16 16:39:27 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

this was fixed on Mar 17:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/whois/whois.c#rev1.55

Re: bioctl showing "0% done" on apparently healthy softraid

[Theo Buehler]

On Sat, Mar 18, 2017 at 11:36:15AM -0400, Joe Gidi wrote:
> Apologies for the horribly mangled formatting on the first attempt.
> Resending, hopefully much more legibly...
> 
> I have a file server running -current on amd64. It has a three-drive RAID1
> softraid array. Up until yesterday, I'd been running a snap from February
> 18 and everything was behaving as expected.
> 
> After updating to a fresh snapshot yesterday, I noticed that the output of
> bioctl is different and a bit odd. It now shows "0% done", but the array
> and all three member drives are showing as online:
> 
> $ sudo bioctl sd4
> Volume  Status   Size Device
> softraid0 0 Online  4000786726912 sd4 RAID1 0% done
>   0 Online  4000786726912 0:0.0   noencl 
>   1 Online  4000786726912 0:1.0   noencl 
>   2 Online  4000786726912 0:2.0   noencl 
> 
> SMART status on all member drives is healthy, and I can see no sign of
> an actual drive failure, so I don't understand why bioctl appears to
> be showing a rebuild in progress.
> 
> Can anyone clue me in on why I'm seeing this?

This is printed due to an unintended side effect of a code cleanup that
happened end of last May. It is harmless and I just committed a diff
that restores the previous behavior. Sorry for the inconvenience.

Re: Problems compiling stable

[Theo Buehler]

On Sat, Mar 18, 2017 at 05:48:50PM +0530, Hrishikesh Muruk wrote:
> I am trying to update from OpenBSD 6.0 release to stable by compiling
> sources. Following the instructions at
> 
> http://man.openbsd.org/OpenBSD-6.0/release
> 
> I was able to build the kernel. I have rebooted with the new kernel.
> 
> When building the system I get an error when executing this command:
> 
> $ cd /usr/src && make SUDO=doas build
> 
> The error:
> --
> test -z "doas" || doas rm -f /var/run/testdata_root /var/run/keycommand_root
> doas: Operation not permitted
> *** Error 1 in regress/usr.bin/ssh (Makefile:207 'clean')
> *** Error 1 in regress/usr.bin (:48 'cleandir')
> *** Error 1 in regress (:48 'cleandir')
> *** Error 1 in . (:48 'cleandir')
> *** Error 1 in /usr/src (Makefile:77 'build')
> 
> --
> 
> Doas works fine for me when I use is on commandline. The files
> /var/run/testdata_root /var/run/keycommand_root do not exist on my system.
> 
> I am building as a user in group wsrc.
> 
> Am I doing something incorrect ? How do I get around this issue?
> 

I believe you need a rule such as 

permit keepenv nopass root as root

in your /etc/doas.conf for this step to work. In /usr/src/Makefile,
'make cleandir' is run with SUDO and now root tries to run 'doas rm -f ...'

> Thanks
> Hrishi

Re: pkg.conf

[Theo Buehler]

On Fri, Mar 03, 2017 at 09:13:12AM +0100, Nils Reuße wrote:
> > Theo Buehler <t...@math.ethz.ch> hat am 2. März 2017 um 22:44 geschrieben:
> >
> >
> > On Thu, Mar 02, 2017 at 10:31:50PM +0100, Jan Stary wrote:
> > > current.html says to # rm /etc/pkg.conf
> > > after the switch to installurl(5).
> > > Should it also say to
> > >
> > >   # rm /usr/share/man/man5/pkg.conf.5
> >
> > yes. fixed, thanks
> >
> 
> I guess one should remove /etc/examples/pkg.conf then as well?
> 

I added that one, too, but I'll leave it at that. None of these files
does any harm if it's present.

Re: pkg.conf

[Theo Buehler]

On Thu, Mar 02, 2017 at 10:31:50PM +0100, Jan Stary wrote:
> current.html says to # rm /etc/pkg.conf
> after the switch to installurl(5).
> Should it also say to
> 
>   # rm /usr/share/man/man5/pkg.conf.5

yes. fixed, thanks

Re: chmod of /usr/obj/usr.sbin/unbound/util

[Theo Buehler]

On Sun, Feb 26, 2017 at 10:05:48PM -0800, Sean Kamath wrote:
> would “$(INSTALL) -d -m 775 util” be a less evil hack?

Nope. In principle, the umask is settable by WOBJUMASK in mk.conf, and
adjusting the mode passed to -m in a shell script in a generated
Makefile is disgusting. Especially when we can just let 'mkdir -p' do
this for us for free.

(Actually, it's not quite as disgusting as what you find when you grep
for umask in unbound/install-sh...)

Re: chmod of /usr/obj/usr.sbin/unbound/util

[Theo Buehler]

On Sun, Feb 26, 2017 at 04:37:57PM +0100, Antoine Jacoutot wrote:
> On Sun, Feb 26, 2017 at 04:30:38PM +0100, Theo Buehler wrote:
> > On Sun, Feb 26, 2017 at 02:33:14PM +0100, Jan Stary wrote:
> > > Cleaning up /usr/obj/ before a kernel build
> > > as a regular user who's in the wobj group,
> > > I get the following
> > > 
> > >   rm: /usr/obj/usr.sbin/unbound/util/configparser.h: Permission denied
> > >   rm: /usr/obj/usr.sbin/unbound/util/configparser.c: Permission denied
> > >   rm: /usr/obj/usr.sbin/unbound/util/configlexer.c: Permission denied
> > >   rm: /usr/obj/usr.sbin/unbound/util: Directory not empty
> > >   rm: /usr/obj/usr.sbin/unbound: Directory not empty
> > >   rm: /usr/obj/usr.sbin: Directory not empty
> > > 
> > > 
> > > $ find /usr/obj/ | xargs ls -ld
> > > drwxrwx---  3 build  wobj 512 Feb 26 14:19 /usr/obj/
> > > drwxrwx---  3 build  wobj2560 Feb 26 14:19 /usr/obj/usr.sbin
> > > drwxrwx---  3 build  wobj4096 Feb 26 14:19 /usr/obj/usr.sbin/unbound
> > > drwxr-xr-x  2 build  wobj 512 Feb 23 20:43 
> > > /usr/obj/usr.sbin/unbound/util
> > > -rw-rw  1 build  wobj  166639 Feb 23 20:43 
> > > /usr/obj/usr.sbin/unbound/util/configlexer.c
> > > -rw-rw  1 build  wobj  122438 Feb 23 20:43 
> > > /usr/obj/usr.sbin/unbound/util/configparser.c
> > > -rw-rw  1 build  wobj6016 Feb 23 20:43 
> > > /usr/obj/usr.sbin/unbound/util/configparser.h
> > > 
> > > Everything is 770 build:wobj, except the single directory
> > > /usr/obj/usr.sbin/unbound/util which is 755 build:wobj.
> > > 
> > > This is on four different -current machines.
> > > Is this intended?
> 
> Aaarrg... no not this again!
> ;-)
> 
> > Of course it is not intended. It was discussed during the last hackathon
> > and aja hunted the problem down to a quirk of install -d. We tried a fix
> > in Makefile.bsd-wrapper, but it turned out to be racy, so I had to back
> > it out: it could write to the src/ tree in some circumstances.
> 
> It's the kind of stupid oddities that make you loose half a day and make you
> feel even more stupid than you are... best memory of Australia!

same here :)

> > This is what seems to be the least evil hack:
> 
> If that actually improves things, OK aja.
> That bug makes me sad...

Indeed...

Before I commit that, I would appreciate if Jan or jmc could confirm
that it actually works for their 'make build' setup, too.

This thing had way too many failed attempts already.

> 
> > Index: usr.sbin/unbound/Makefile.in
> > ===
> > RCS file: /var/cvs/src/usr.sbin/unbound/Makefile.in,v
> > retrieving revision 1.20
> > diff -u -p -r1.20 Makefile.in
> > --- usr.sbin/unbound/Makefile.in17 Feb 2017 18:53:31 -  1.20
> > +++ usr.sbin/unbound/Makefile.in26 Feb 2017 15:04:38 -
> > @@ -408,7 +408,7 @@ _unbound.la:libunbound_wrap.lo libunbou
> >  
> >  util/config_file.c:util/configparser.h
> >  util/configlexer.c:  $(srcdir)/util/configlexer.lex util/configparser.h
> > -   @-if test ! -d util; then $(INSTALL) -d util; fi
> > +   @-if test ! -d util; then mkdir -p util; fi
> > if test "$(LEX)" != ":"; then \
> > echo "#include \"config.h\"" > $@ ;\
> > echo "#include \"util/configyyrename.h\"" >> $@ ;\
> > @@ -416,7 +416,7 @@ util/configlexer.c:  $(srcdir)/util/conf
> > fi
> >  
> >  util/configparser.c util/configparser.h:  $(srcdir)/util/configparser.y
> > -   @-if test ! -d util; then $(INSTALL) -d util; fi
> > +   @-if test ! -d util; then mkdir -p util; fi
> > $(YACC) -d -o util/configparser.c $(srcdir)/util/configparser.y
> >  
> >  clean:
> > 
> 
> -- 
> Antoine

Re: chmod of /usr/obj/usr.sbin/unbound/util

[Theo Buehler]

On Sun, Feb 26, 2017 at 02:33:14PM +0100, Jan Stary wrote:
> Cleaning up /usr/obj/ before a kernel build
> as a regular user who's in the wobj group,
> I get the following
> 
>   rm: /usr/obj/usr.sbin/unbound/util/configparser.h: Permission denied
>   rm: /usr/obj/usr.sbin/unbound/util/configparser.c: Permission denied
>   rm: /usr/obj/usr.sbin/unbound/util/configlexer.c: Permission denied
>   rm: /usr/obj/usr.sbin/unbound/util: Directory not empty
>   rm: /usr/obj/usr.sbin/unbound: Directory not empty
>   rm: /usr/obj/usr.sbin: Directory not empty
> 
> 
> $ find /usr/obj/ | xargs ls -ld
> drwxrwx---  3 build  wobj 512 Feb 26 14:19 /usr/obj/
> drwxrwx---  3 build  wobj2560 Feb 26 14:19 /usr/obj/usr.sbin
> drwxrwx---  3 build  wobj4096 Feb 26 14:19 /usr/obj/usr.sbin/unbound
> drwxr-xr-x  2 build  wobj 512 Feb 23 20:43 /usr/obj/usr.sbin/unbound/util
> -rw-rw  1 build  wobj  166639 Feb 23 20:43 
> /usr/obj/usr.sbin/unbound/util/configlexer.c
> -rw-rw  1 build  wobj  122438 Feb 23 20:43 
> /usr/obj/usr.sbin/unbound/util/configparser.c
> -rw-rw  1 build  wobj6016 Feb 23 20:43 
> /usr/obj/usr.sbin/unbound/util/configparser.h
> 
> Everything is 770 build:wobj, except the single directory
> /usr/obj/usr.sbin/unbound/util which is 755 build:wobj.
> 
> This is on four different -current machines.
> Is this intended?

Of course it is not intended. It was discussed during the last hackathon
and aja hunted the problem down to a quirk of install -d. We tried a fix
in Makefile.bsd-wrapper, but it turned out to be racy, so I had to back
it out: it could write to the src/ tree in some circumstances.

This is what seems to be the least evil hack:

Index: usr.sbin/unbound/Makefile.in
===
RCS file: /var/cvs/src/usr.sbin/unbound/Makefile.in,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile.in
--- usr.sbin/unbound/Makefile.in17 Feb 2017 18:53:31 -  1.20
+++ usr.sbin/unbound/Makefile.in26 Feb 2017 15:04:38 -
@@ -408,7 +408,7 @@ _unbound.la:libunbound_wrap.lo libunbou
 
 util/config_file.c:util/configparser.h
 util/configlexer.c:  $(srcdir)/util/configlexer.lex util/configparser.h
-   @-if test ! -d util; then $(INSTALL) -d util; fi
+   @-if test ! -d util; then mkdir -p util; fi
if test "$(LEX)" != ":"; then \
echo "#include \"config.h\"" > $@ ;\
echo "#include \"util/configyyrename.h\"" >> $@ ;\
@@ -416,7 +416,7 @@ util/configlexer.c:  $(srcdir)/util/conf
fi
 
 util/configparser.c util/configparser.h:  $(srcdir)/util/configparser.y
-   @-if test ! -d util; then $(INSTALL) -d util; fi
+   @-if test ! -d util; then mkdir -p util; fi
$(YACC) -d -o util/configparser.c $(srcdir)/util/configparser.y
 
 clean:

Re: Are ease-of-reference patches wanted for man pages?

[Theo Buehler]

> Are there any guidelines anywhere on what we are going for in a man
> page?  If not is there a page which is very good and can be held up as a 
> standard?

Ingo's EuroBSDCon 2014 tutorial slides might be a good place to start:

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

It should contain all the important pointers and while mandoc has
evolved since then, I think it shouldn't be too outdated.

One of my favorite pages is the (relatively) new sh(1) manual, but
usually things aren't that complex :)

Re: Are ease-of-reference patches wanted for man pages?

[Theo Buehler]

On Sat, Feb 25, 2017 at 07:01:30AM -0300, Eike Lantzsch wrote:
> On Saturday, 25 February 2017 10:16:37 PYST Janne Johansson wrote:
> > 2017-02-25 9:45 GMT+01:00 Currell Berry :
> > > Is feedback / are patches solicited for man-pages in order to improve
> > > their usability to average users (even if this were to make them
> > > somewhat less formal in nature)?
> > >
> > > I find the openbsd man pages very useful, but I do run across things
> > > which I cannot figure out from the man pages and/or faq.  Often I will
> > > then do a web search to look for an answer to my dilemma.  When I find
> > > the answer, I often wish that a piece of information had been included
> > > in the relevant man pages and/or faq which would have prevented me
> > > needing to search through the internet.  Often this piece of information
> > > is a usage example.
> > >
> > > Three recent examples for me were:
> > > 1. the xorg.conf manual page does not say anything about specifying
> > > resolution (rough answer -- the mode name generally identifies resolution
> > > by
> > > using a string such as "1024x768".  there are various preset modes or
> > > you can create your own).

Most of the manuals in xenocara/ are not ours and we don't usually
modify them a lot.  You may want to contact upstream:
https://www.x.org/wiki/DeveloperStart/

> > > 2. The openbsd disk setup FAQ does not really tell you to use newfs
> > > after you have used fdisk and disklabel.  It tangentially mentions newfs
> > > in the portion about "encrypting external disks" and in the answer to
> > > the prompt "Why does df tell me I have over 100% of my disk used".  I
> > > think perhaps newfs as the next step in the disk setup process could be
> > > mentioned in the FAQ, and also that maybe the disklabel utility man page
> > > could
> > > include a link to or small comment about newfs.
> >
> > Yes, the chapter
> > Partitions and filesystems
> >
> > of faq14 should actually talk about filesystems also, and probably mention
> > newfs while there, but it almost exclusively discusses partitions and
> > partitioning.

Sounds totally reasonable, a short sentence or two on newfs certainly
wouldn't hurt...  I suggest you send a patch to tech@ and tj and I will
consider it.

> > > 3. Many of the login.conf resource limits appear to be per process, but
> > > the man page does not in general differentiate the limits that are per
> > > user and per-process.  So, for instance, cputime is identified as "CPU
> > > usage limit" but I cannot know without prior knowledge or searching
> > > whether this is enforced per-process or per-user.
> >
> > I think a short notice on how it is applied could well fit into that
> > manpage, if kept brief. You would have to be careful not to have the same
> > information typed down in various ways also in limit descriptions (in shell
> > manpages mostly for ulimit) and setrlimit(2).
> >
> > > So, in all of these cases, there is no error in the documentation, it
> > > just doesn't hold the user's hand very much.  Does OpenBSD want man-page
> > > patch submissions which attempt to improve the usability of the
> > > man-pages?  If so,
> > > where should such patches be submitted?

Patches (including documentation) are best sent to the tech@ mailing
list.

Re: i3bar iwn info and battery status

[Theo Buehler]

On Wed, Feb 22, 2017 at 03:47:33PM +0300, Asbel Kiprop wrote:
> Hm, 17 feb. snapshot  - stilll have this problem. can't open /dev/apm" and
> wireless down (but works as well),
> Any suggestions? Should i just wait more for fix?

Did you try updating the packages since Monday? I.e., do you have the
i3status-2.11p2 installed?

There were some nfs-related issues that prevented new packages to be
pushed right when the fix for i3status went in and new packages arrived
only on Sunday or Monday this week.