text: pax mtime
  This is just a quick hack for now, but we need something like it in order to correctly extract some newer tars with correct timestamps, in particular python-generated ones like Index: tar.c === RCS file: /cvs/src/bin/pax/tar.c,v retrieving revision 1.69 diff -u -p -r1.69 tar.c --- tar.c 14 Jun 2021 00:36:13 - 1.69 +++ tar.c 15 Oct 2021 21:40:49 - @@ -784,12 +784,17 @@ reset: arcn->sb.st_mode = (mode_t)(asc_ul(hd->mode, sizeof(hd->mode), OCT) & 0xfff); arcn->sb.st_size = (off_t)asc_ull(hd->size, sizeof(hd->size), OCT); - val = asc_ull(hd->mtime, sizeof(hd->mtime), OCT); - if (val > MAX_TIME_T) - arcn->sb.st_mtime = INT_MAX;/* XXX 2038 */ - else - arcn->sb.st_mtime = val; - arcn->sb.st_ctime = arcn->sb.st_atime = arcn->sb.st_mtime; + if (arcn->sb.st_mtime == 0) { + val = asc_ull(hd->mtime, sizeof(hd->mtime), OCT); + if (val > MAX_TIME_T) + arcn->sb.st_mtime = INT_MAX;/* XXX 2038 */ + else + arcn->sb.st_mtime = val; + } + if (arcn->sb.st_ctime == 0) + arcn->sb.st_ctime = arcn->sb.st_mtime; + if (arcn->sb.st_atime == 0) + arcn->sb.st_atime = arcn->sb.st_mtime; /* * If we can find the ascii names for gname and uname in the password @@ -1266,6 +1271,13 @@ rd_xheader(ARCHD *arcn, int global, off_ if (!strcmp(keyword, "path")) { arcn->nlen = strlcpy(arcn->name, p, sizeof(arcn->name)); + } else if (!strcmp(keyword, "mtime")) { + /* XXX error handling, and should parse nanoseconds */ + arcn->sb.st_mtime = strtoull(p, NULL, 10); + } else if (!strcmp(keyword, "atime")) { + arcn->sb.st_atime = strtoull(p, NULL, 10); + } else if (!strcmp(keyword, "ctime")) { + arcn->sb.st_ctime = strtoull(p, NULL, 10); } else if (!strcmp(keyword, "linkpath")) { arcn->ln_nlen = strlcpy(arcn->ln_name, p, sizeof(arcn->ln_name));
  Re: syslogd: allow setting TLS protocols
  On 2021/10/11 15:50, Alexander Bluhm wrote: > On Sat, Oct 09, 2021 at 09:36:01PM +0100, Stuart Henderson wrote: > > This allows setting which TLS versions are usable by syslogd. Some > > environments require that TLSv1.0 is disabled. Manual wording stolen from > > ftp(1). any comments? ok? > > netcat and ftp allow to give TLS options as key=value. Maybe we > want that here, otherwise we could run out of option letters. Do > our users want specific ciphers or other things? For my current use case, simply requiring 1.2 or newer is good enough and I don't need to set particular ciphers. I can change the implementation to use that method, but I wonder which options would be needed. There is only partial consistency between netcat and ftp so far, netcat: noverify, noname, clientcert, muststaple, ciphers, protocols (cafile and clientcert are implemented via flags other than -T) ftp: cafile, capath, depth, do, dont, muststaple, ciphers, protocols, noverifytime Following netcat's lead there is probably no need to move -C/-c/-K/-k to a different flag. Maybe there's some use case for noverifytime. ciphers/protocols make sense. noname/noverify don't seem to make much sense to me for syslogd. > Is it wise to set the same options for client and server TLS? > > When syslogd is relaying messages from dumb devices with broken TLS > stacks to modern SIEM systems, the requirements on both sides are > different. I avoided to dive too deeply into this question by using > sane defaults. I use "all" or "compat" cipher lists. > It seems for your use case the defaults do not match. > > Do you need TLS 1.0 disabled for receiving or sending side? This is a good question. For my current use case as I understand it it's enough to just not be _using_ pre-1.2 TLS, but it's easier to document and prove if the earlier protocols are actually disabled rather than just not used. I would say at a minimum it needs setting server-side but it would be helpful to do client-side as well. I didn't expect to see syslogd used to relaying messages from client to a remote server, but now that you've described it, it makes complete sense and I see how different settings for client and server would be useful there.
  Re: head(1): fully support the legacy -count syntax
  On 2021/10/10 14:26, Scott Cheloha wrote: > On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote: > > Bryan Steele wrote: > > > > > On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > > > > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > > > > did anyone ever use it this way, or are you getting ahead of yourself. > > > > > > > > I don't understand the question. > > > > > > I've only ever seen it used with -count as the first argument, can't > > > say it's every occoured to me to type "head file -10". > > That is not what I proposed. Reread my first message: > > i.e. "head -2 -3 somefile" is taken as -3. This is unportable syntax, GNU head doesn't support it, current OpenBSD head doesn't support it, and it doesn't seem to be really meaningful. Additionally I don't think we've ever had a problem with this in ports. I think we would be better served to keep things as-is and not support it. Seems that FreeBSD is the odd one out here?
  syslogd: allow setting TLS protocols
  This allows setting which TLS versions are usable by syslogd. Some environments require that TLSv1.0 is disabled. Manual wording stolen from ftp(1). any comments? ok? Index: syslogd.8 === RCS file: /cvs/src/usr.sbin/syslogd/syslogd.8,v retrieving revision 1.60 diff -u -p -r1.60 syslogd.8 --- syslogd.8 27 Sep 2018 08:33:25 - 1.60 +++ syslogd.8 9 Oct 2021 20:27:37 - @@ -51,6 +51,7 @@ .Op Fl S Ar listen_address .Op Fl s Ar reporting_socket .Op Fl T Ar listen_address +.Op Fl t Ar tls_protocols .Op Fl U Ar bind_address .Ek .Sh DESCRIPTION @@ -155,6 +156,12 @@ There is no well-known port for syslog o must be specified using the .Ar host : Ns Ar port syntax. +.It Fl t Ar tls_protocols +Specify the TLS protocols that will be supported by +.Nm +(see +.Xr tls_config_parse_protocols 3 +for details). .It Fl U Ar bind_address Create a UDP socket for receiving messages and bind it to the specified address. Index: syslogd.c === RCS file: /cvs/src/usr.sbin/syslogd/syslogd.c,v retrieving revision 1.270 diff -u -p -r1.270 syslogd.c --- syslogd.c 19 Sep 2021 10:17:36 - 1.270 +++ syslogd.c 9 Oct 2021 20:27:37 - @@ -373,6 +373,7 @@ main(int argc, char *argv[]) char**path_unix, *path_ctlsock; char**bind_host, **bind_port, **listen_host, **listen_port; char*tls_hostport, **tls_host, **tls_port; + uint32_ttls_protocols = TLS_PROTOCOLS_ALL; /* block signal until handler is set up */ sigemptyset(); @@ -392,7 +393,7 @@ main(int argc, char *argv[]) nbind = nlisten = ntls = 0; while ((ch = getopt(argc, argv, - "46a:C:c:dFf:hK:k:m:nP:p:rS:s:T:U:uVZ")) != -1) { + "46a:C:c:dFf:hK:k:m:nP:p:rS:s:T:t:U:uVZ")) != -1) { switch (ch) { case '4': /* disable IPv6 */ Family = PF_INET; @@ -463,6 +464,11 @@ main(int argc, char *argv[]) address_alloc("listen", optarg, _host, _port, ); break; + case 't': /* specify protocols for TLS */ + if (tls_config_parse_protocols(_protocols, optarg) + != 0) + errx(1, "failed to parse TLS protocols"); + break; case 'U': /* allow udp only from address */ address_alloc("bind", optarg, _host, _port, ); @@ -645,7 +651,7 @@ main(int argc, char *argv[]) log_warnx("options -c and -k must be used together"); } if (tls_config_set_protocols(client_config, - TLS_PROTOCOLS_ALL) != 0) + tls_protocols) != 0) log_warnx("set client TLS protocols: %s", tls_config_error(client_config)); if (tls_config_set_ciphers(client_config, "all") != 0) @@ -695,7 +701,7 @@ main(int argc, char *argv[]) tls_config_verify_client(server_config); } if (tls_config_set_protocols(server_config, - TLS_PROTOCOLS_ALL) != 0) + tls_protocols) != 0) log_warnx("set server TLS protocols: %s", tls_config_error(server_config)); if (tls_config_set_ciphers(server_config, "compat") != 0)
  etc/syslog.conf: adjust comment for log host sample config
  The comments in etc/syslog.conf describe partially log-client setup and partially log-host setup and use UDP. I think it would be better to focus on "loghost-client" setup in the default config, the server options needed seem better described in syslogd(8) than in comments in syslog.conf. Since we have nice TLS features I think it makes sense to advertise them here too, and remove the mention of ISDN which makes it seem dated. any comments? OK? Index: syslog.conf === RCS file: /cvs/src/etc/syslog.conf,v retrieving revision 1.20 diff -u -p -r1.20 syslog.conf --- syslog.conf 27 Dec 2016 13:38:14 - 1.20 +++ syslog.conf 9 Oct 2021 11:48:35 - @@ -22,13 +22,10 @@ mail.info /var/log/maillog # Everyone gets emergency messages. #*.emerg * -# Uncomment to log to a central host named "loghost". You need to run -# syslogd with the -u option on the remote host if you are using this. -# (This is also required to log info from things like routers and -# ISDN-equipment). If you run -u, you are vulnerable to syslog bombing, -# and should consider blocking external syslog packets. -#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none @loghost -#auth,daemon,syslog,user.info;authpriv,kern.debug @loghost +# Uncomment to log to a central host named "loghost" using syslog-tls. +# Other protocols are available, see syslogd(8). +#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none @tls://loghost +#auth,daemon,syslog,user.info;authpriv,kern.debug @tls://loghost # Uncomment to log messages from doas(1) to its own log file. Matches are done # based on the program name.
  Re: Remove deprecated variables in sysctl(2)
  On 2021/10/05 18:11, Solene Rapenne wrote: > Variables HW_PHYSMEM and HW_USERMEM were deprecated 13 years ago, > maybe we can remove them from sysctl(2)? "deprecated" doesn't mean removed or disabled, it just means that one shouldn't use them. These are still in system headers and supported by the kernel, and could possibly be used by ports. > It was originally in sysctl(3) if someone want to do some history > research > > > Index: sysctl.2 > === > RCS file: /home/reposync/src/lib/libc/sys/sysctl.2,v > retrieving revision 1.44 > diff -u -p -r1.44 sysctl.2 > --- sysctl.2 18 May 2021 05:26:26 - 1.44 > +++ sysctl.2 5 Oct 2021 16:03:28 - > @@ -289,13 +289,11 @@ privileges may change the value. > .It Dv HW_NCPUONLINE Ta "integer" Ta "no" > .It Dv HW_PAGESIZE Ta "integer" Ta "no" > .It Dv HW_PERFPOLICY Ta "string" Ta "yes" > -.It Dv HW_PHYSMEM Ta "integer" Ta "no" > .It Dv HW_PHYSMEM64 Ta "int64_t" Ta "no" > .It Dv HW_PRODUCT Ta "string" Ta "no" > .It Dv HW_SENSORS Ta "node" Ta "not applicable" > .It Dv HW_SETPERF Ta "integer" Ta "yes" > .It Dv HW_SMT Ta "integer" Ta "yes" > -.It Dv HW_USERMEM Ta "integer" Ta "no" > .It Dv HW_USERMEM64 Ta "int64_t" Ta "no" > .It Dv HW_UUID Ta "string" Ta "no" > .It Dv HW_VENDOR Ta "string" Ta "no" > @@ -343,11 +341,6 @@ Can be one of > .Dq auto , > or > .Dq high . > -.It Dv HW_PHYSMEM > -The total physical memory, in bytes. > -This variable is deprecated; use > -.Dv HW_PHYSMEM64 > -instead. > .It Dv HW_PHYSMEM64 Pq Va hw.physmem > The total physical memory, in bytes. > .It Dv HW_PRODUCT Pq Va hw.product > @@ -393,11 +386,6 @@ is set to > If set to 1, enable simultaneous multithreading (SMT) on CPUs that > support it. > Disabled by default. > -.It Dv HW_USERMEM > -The amount of available non-kernel memory in bytes. > -This variable is deprecated; use > -.Dv HW_USERMEM64 > -instead. > .It Dv HW_USERMEM64 Pq Va hw.usermem > The amount of available non-kernel memory in bytes. > .It Dv HW_UUID Pq Va hw.uuid >
  Re: Relayd daily crash ca_dispatch_relay invalid
  On 2021/10/01 14:43, Stuart Henderson wrote: >: Hmm. Rereading your mail it might not be that..but if the limit is too low you could have other things failing as a result..
  Re: Relayd daily crash ca_dispatch_relay invalid: > dmesg > OpenBSD 6.9 (GENERIC) #5: Tue Aug 10 08:11:10 MDT 2021 > r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 1056833536 (1007MB) > avail mem = 1009586176 (962MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6320 (9 entries) > bios0: vendor SeaBIOS version "Ubuntu-1.8.2-1ubuntu1.1" date 04/01/2014 > bios0: QEMU Standard PC (i440FX + PIIX, 1996) > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S3 S4 S5 > acpi0: tables DSDT FACP SSDT APIC HPET > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Westmere E56xx/L56xx/X56xx (Nehalem-C), 3067.15 MHz, 06-2c-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,HV,NXE,LONG,LAHF,ARAT,MELTDOWN > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 999MHz > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins > acpihpet0 at acpi0: 1 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > "ACPI0006" at acpi0 not configured > acpipci0 at acpi0 PCI0 > acpicmos0 at acpi0 > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > acpicpu0 at acpi0: C1(@1 halt!) > cpu0: using IvyBridge MDS workaround > pvbus0 at mainbus0: KVM > pvclock0 at pvbus0 > > atapiscsi0 at pciide0 channel 0 drive 1 > scsibus1 at atapiscsi0: 2 targets > cd0 at scsibus1 targ 0 lun 0: removable > cd0(pciide0:0:1): using PIO mode 4, DMA mode 2 > pciide0: channel 1 disabled (no drives) > uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11 > piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9 > iic0 at piixpm0 > vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0:
  Re: OpenBSD Errata: September 30, 2021 (libressl)
  On 2021/09/30 21:45, Sebastian Benoit wrote: > An errata patch for LibreSSL has been released for OpenBSD 6.8 and > OpenBSD 6.9. > > Compensate for the expiry of the DST Root X3 certificate. The use of an > unnecessary expired certificate in certificate chains can cause validation > errors. > > Binary updates for the amd64, i386 and arm64 platform are available > via the syspatch utility. Source code patches can be found on the > respective errata page: > > > > Note: you may have issues fetching the syspatches from your regular mirror due to this issue. Try fetching it normally first, as a number of mirrors are either unaffected, or have a workaround on the server side, but if that fails you have two options: - edit /etc/installurl to allow you to fetch the syspatches. Either switch https to http (the updates are signed and verified anyway), or use another mirror (including,, cdn.openbsd.org). - locate the expired certificate in /etc/ssl/cert.pem and remove it, it is the one with this in the header above: === /O=Digital Signature Trust Co./CN=DST Root CA X3 If you're able to install the syspatch anyway (syspatch69-018_cert.tgz or syspatch68-032_cert.tgz) then you don't need either of the above steps.
  Re: Variable type fix in parse.y (all of them)
  On 2021/09/29 21:21, Christian Weisgerber wrote: > The oft-copied parse.y code declares some variables as "unsigned char *" > but passes them to functions that take "char *" arguments and doesn't > make any use of the unsigned property. btw, those used to be char: revision 1.628 date: 2013/11/25 12:52:45; author: benno; state: Exp; lines: +7 -7; use u_char for buffers in yylex, for ctype calls found by millert@, ok deraadt@ Index: parse.y === RCS file: /cvs/src/sbin/pfctl/parse.y,v retrieving revision 1.627 retrieving revision 1.628 diff -u -p -r1.627 -r1.628 --- parse.y 22 Nov 2013 04:12:48 - 1.627 +++ parse.y 25 Nov 2013 12:52:45 - 1.628 @@ -1,4 +1,4 @@ -/* $OpenBSD: parse.y,v 1.627 2013/11/22 04:12:48 deraadt Exp $ */ +/* $OpenBSD: parse.y,v 1.628 2013/11/25 12:52:45 benno Exp $ */ /* * Copyright (c) 2001 Markus Friedl. All rights reserved. @@ -5536,9 +5536,9 @@ lookup(char *s) #define MAXPUSHBACK128 -char *parsebuf; +u_char *parsebuf; int parseindex; -charpushback_buffer[MAXPUSHBACK]; +u_char pushback_buffer[MAXPUSHBACK]; int pushback_index = 0; int @@ -5630,8 +5630,8 @@ findeol(void) int yylex(void) { - char buf[8096]; - char*p, *val; + u_char buf[8096]; + u_char *p, *val; int quotec, next, c; int token; @@ -5654,7 +5654,7 @@ top: return (findeol()); } if (isalnum(c) || c == '_') { - *p++ = (char)c; + *p++ = c; continue; } *p = '\0'; @@ -5699,7 +5699,7 @@ top: yyerror("string too long"); return (findeol()); } - *p++ = (char)c; + *p++ = c; } yylval.v.string = strdup(buf); if (yylval.v.string == NULL)
  Re: sigwaitinfo(2) and sigtimedwait(2)
  On 2021/09/24 19:36, Rafael Sadowski wrote: > I'm trying to port the more KDE stuff so my question is from porter > perspective. > > I need sigwaitinfo(2)/sigtimedwait(2) and I found both functions in > lib/libc/gen/sigwait.c with the comment "need kernel to fill in more > siginfo_t bits first". Is the comment still up to date? If no, is it > possible to unlock the functions? > > Thanks, Rafael > I don't think any more bits have been filled in since these were added revision 1.13 date: 2012/04/13 08:25:37; author: guenther; state: Exp; lines: +40 -1; Add sigwaitinfo and sigtimedwait stubs under #if 0; a bit more kernel support is needed before they can be usefully enabled but I don't want to misplace this diff yet again For sure si_pid is not filled in, I ran into that with icinga2 relatively recently (jmatthew helped a lot figuring that one out)..
  Re: Should 80MB of RAM be enough for kernel relinking on i386?
  Nobody should really by using i386 for new systems. The advantages of running amd64-compatible hardware are too big to ignore. Lower power consumption, much faster in most cases (the extra register used by PIE hurts i386 mode a lot more than amd64 mode with its extra registers), more address space for ASLR, some other security mitigations don't work on i386, more compatible with software in ports. If it's an old system then you already have it so you can just see for yourself how much space it needs (and make your own decisions on swap space vs RAM, and whether to disable relinking at boot [just using it for upgrades/syspatch], and whether to bodge things to use ld.bfd to save RAM). So much depends on how you're going to use the system that I don't think it's really useful to publish the numbers.
  Re: pf.conf(5) & reply-to
  On 2021/09/22 11:28, Landry Breuil wrote: > Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a écrit : > > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200: > > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote: > > > > did i screwup something somewhere in my config and there's a better way > > > > for that ? > > > > > > This was changed in February. No more interface, but gateway > > > addresses. It seems that some parts of the documentation were > > > missed. > > > > > > > should the manpage be improved for reply-to and talk about 'destination > > > > address' instead of 'interface' like route-to does ? > > > > > > Yes. > > > > > > It looks like most information is in the commit message. > > > > > > > It's also on > > my english sucks and i'm not sure i got the meaning right, but here's a > try: > > Index: pf.conf.5 > === > RCS file: /cvs/src/share/man/man5/pf.conf.5,v > retrieving revision 1.587 > diff -u -r1.587 pf.conf.5 > --- pf.conf.5 19 Jul 2021 16:23:56 - 1.587 > +++ pf.conf.5 22 Sep 2021 09:23:14 - > @@ -1103,13 +1103,14 @@ > option is similar to > .Cm route-to , > but routes packets that pass in the opposite direction (replies) to the > -specified interface. > +specified address. > Opposite direction is only defined in the context of a state entry, and > .Cm reply-to > is useful only in rules that create state. > It can be used on systems with multiple external connections to > -route all outgoing packets of a connection through the interface > -the incoming connection arrived through (symmetric routing enforcement). > +route all outgoing packets of a connection through the interface the incoming > +connection arrived through (symmetric routing enforcement) via the address of > +the gateway specified in the rule. I think using "connection" twice (internet connection, and TCP/UDP/...\ connection) can make this harder to read. Not 100% happy with this and I have to go out so won't do any more wordsmithing now, but maybe it gives some ideas? It can be used on systems with multiple paths to the internet to ensure that replies to an incoming network connection to a particular address are sent using the path associated with that address (symmetric routing enforcement). This is done by specifying the address of the gateway in "reply-to". > .It Cm route-to > The > .Cm route-to > > i wouldnt know how to change the example in faq/upgrade69.html as it is valid > (but only specific to the case of a point-to-point interface with a :peer > property) > > ccing experts :) >
  Re: [PATCH] Always generate SAN
  Moved to tech@. Full original mail at On 2021-09-17, Wolf wrote on misc@: > Use of only CN is not allowed according to Baseline Requirements 1.8.0 > from CA Browser Forum. Using CN is not prohibited, but if it is present, > value in it must also be present in SAN. And SAN is always required. Baseline requirements relate to the CA-signed certificate; a CA will make changes to the certificate requested in a CSR for baseline requirements compliance. > While currently Let's Encrypt does accept requests without CN, in the > interest of future-proofing, this commit modifies acme-client to always > generate SAN and include CN in it. There are two issues: - if you only list a plain domain (no "alternative names") in acme-client.conf then subjectAlternativeName isn't generated in the CSR at all. a CA is definitely expected to fix this up. If this was the only problem then I would recommend deferring to post-7.0. - if you list alternative domains, only the alternatives and not the main domain are listed in subjectAlternativeName in the CSR. This is definitely wrong. If SAN is present, the domain name in the subject must be ignored. Current CAs are clearly fixing this up, but we are generating the SANs incorrectly here and I don't think we should rely on them being fixed, So I think for this reason it's worth getting this in pre 7.0. > I recommend viewing the diff with whitespace differences ignored (-w), > helps to show how minimal it is. Indeed; "if (altsz > 1)" is removed shifting the indentation up a level, and the loop initialiser is changed from "i = 1" to "i = 0". > I've tested this and it issues valid certificate that includes both CN > and SAN (check current cert of wolfsden.cz if you want to make sure). > > Baseline Requirements can be found here [0], CN is described in > 7.1.4.2.2. > > Why this is even a problem: My version of acme-client has some tests and > pebble (let's encrypt's test server) already does not accept > certificates without correct SAN [1]. pebble is not exactly "letsencrypt's test server" (which I'd think of as their staging server) it's test server *software* for integration testing etc and is expected to be more strict than a real server. (i.e. if someone wants to test this against a fussy server, they will need to run the software themselves, running against letsencrypt-staging is *not* sufficient). > usr.sbin/acme-client/keyproc.c | 90 +- > 1 file changed, 44 insertions(+), 46 deletions(-) [quoting removed so they diff will apply directly; it is unchanged from the original] This is OK sthen@. diff --git a/usr.sbin/acme-client/keyproc.c b/usr.sbin/acme-client/keyproc.c index b4cc6184e26..3a1d68526d9 100644 --- a/usr.sbin/acme-client/keyproc.c +++ b/usr.sbin/acme-client/keyproc.c @@ -175,53 +175,51 @@ keyproc(int netsock, const char *keyfile, const char **alts, size_t altsz, * TODO: is this the best way of doing this? */ - if (altsz > 1) { - nid = NID_subject_alt_name; - if ((exts = sk_X509_EXTENSION_new_null()) == NULL) { - warnx("sk_X509_EXTENSION_new_null"); - goto out; - } - /* Initialise to empty string. */ - if ((sans = strdup("")) == NULL) { - warn("strdup"); - goto out; - } - sansz = strlen(sans) + 1; - - /* -* For each SAN entry, append it to the string. -* We need a single SAN entry for all of the SAN -* domains: NOT an entry per domain! -*/ - - for (i = 1; i < altsz; i++) { - cc = asprintf(, "%sDNS:%s", - i > 1 ? "," : "", alts[i]); - if (cc == -1) { - warn("asprintf"); - goto out; - } - pp = recallocarray(sans, sansz, sansz + strlen(san), 1); - if (pp == NULL) { - warn("recallocarray"); - goto out; - } - sans = pp; - sansz += strlen(san); - strlcat(sans, san, sansz); - free(san); - san = NULL; - } - - if (!add_ext(exts, nid, sans)) { - warnx("add_ext"); - goto out; - } else if (!X509_REQ_add_extensions(x, exts)) { - warnx("X509_REQ_add_extensions"); - goto out; - } - sk_X509_EXTENSION_pop_free(exts, X509_EXTENSION_free); + nid = NID_subject_alt_name; + if ((exts = sk_X509_EXTENSION_new_null()) == NULL) { +
  Re: Diff: Function Length Reduction
  On 2021/09/10 16:39, VARIK VALEFOR wrote: > Is any particular aspect of the replacement code bad? The use of 'magic number' ASCII values obfuscates what the code is doing.
  Re: Diff: Function Length Reduction
  On 2021/09/10 00:27, VARIK VALEFOR wrote: > P.S. s/originalBuf/vp->buffer/g I think this is a good demonstration of why sometimes it's better to have longer but simpler code.
  Re: Change vm_dsize to vsize_t
  On 2021/09/09 06:47, Greg Steuck wrote: > Mark Kettenis writes: > > >> From: "Theo de Raadt" > >> Date: Tue, 07 Sep 2021 07:08:19 -0600 > >> > >> Or we could coordinate the Greg approach as a sysctl ABI change near a > >> libc major bump. On the other side of such a bump, all kernel + base + > >> packages are updated to use the new storage ABI. We get orderly .h > >> files without a confusing glitch, and kern_sysctl.c doesn't need to > >> store the value into two fields (32bit and 64bit) for the forseeable > >> future. > >> > >> Over the years I've arrived at the conclusion that maintaining binary > >> compatibility at all costs collects too much confusing damage. Instead, > >> we've built an software ecosystem where ABI changes are expected and > >> carry minimal consequence. Sadly rust and especially go made a different decision about that. > I'd take some short term intense pain over a long term nagging one. I'll > try to beg somebody with a full unpacked source ports tree to grep for > p_vm_dsize. Superficially, I only see it in a single patch: > > /usr/ports/databases/mongodb/patches/patch-src_mongo_util_processinfo_openbsd_cpp I think it's a change to kinfo_proc in general that is more of a problem than the individual member. The last big change in that area was supposed to be to avoid this pain - indeed kvm_getprocs manual says. FWIW search results for p_vm_dsize from 15 month old unpacked src: u/lcdproc-0.5.5/lcdproc-0.5.5/clients/lcdproc/machine_NetBSD.c 73:#define PROCSIZE(pp) ((pp)->p_vm_tsize + (pp)->p_vm_dsize + (pp)->p_vm_ssize) u/mongodb-3.2.22/mongodb-src-r3.2.22/src/mongo/util/processinfo_openbsd.cpp 114:return ((task->p_vm_dsize + task->p_vm_ssize + task->p_vm_tsize) * sysconf(_SC_PAGESIZE)) / u/libgtop2-2.40.0/libgtop-2.40.0/sysdeps/openbsd/procmem.c 125: (pinfo[0].p_vm_tsize + pinfo[0].p_vm_dsize + pinfo[0].p_vm_ssize) u/libgtop2-2.40.0/libgtop-2.40.0/sysdeps/openbsd/procsegment.c 74: buf->data_rss = pinfo[0].p_vm_dsize * pagesize; u/spidermonkey68-68.9.0/firefox/spidermonkey68-68.9.0/firefox-68.9.0/xpcom/base/nsMemoryReporterManager.cpp 178: ((kp.p_vm_dsize + kp.p_vm_ssize + kp.p_vm_tsize) * getpagesize()) u/thunderbird-68.9.0/thunderbird-68.9.0/xpcom/base/nsMemoryReporterManager.cpp 178: ((kp.p_vm_dsize + kp.p_vm_ssize + kp.p_vm_tsize) * getpagesize()) u/thunderbird-68.9.0/thunderbird/net-snmp-5.8.1.pre2/net-snmp-5.8.1.pre2/agent/mibgroup/host/hr_swrun.c 1273:proc_table[LowProcIndex].p_vm_dsize; 1295:proc_table[LowProcIndex].p_vm_dsize; u/zabbix-4.0.19-no_server/zabbix-4.0.19/src/libs/zbxsysinfo/netbsd/proc.c 169:value = pproc->p_vm_tsize + pproc->p_vm_dsize + pproc->p_vm_ssize; u/zabbix-4.0.19-no_server-mysql/zabbix-4.0.19/src/libs/zbxsysinfo/netbsd/proc.c 169:value = pproc->p_vm_tsize + pproc->p_vm_dsize + pproc->p_vm_ssize; u/zabbix-4.0.19-mysql-pgsql/zabbix-4.0.19/src/libs/zbxsysinfo/netbsd/proc.c 169:value = pproc->p_vm_tsize + pproc->p_vm_dsize + pproc->p_vm_ssize; u/zabbix-4.0.19-pgsql-sqlite3/zabbix-4.0.19/src/libs/zbxsysinfo/netbsd/proc.c 169:value = pproc->p_vm_tsize + pproc->p_vm_dsize + pproc->p_vm_ssize; u/zabbix-4.0.19-sqlite3
  Re: OpenSSH: RSA/SHA1 disabled by default
  On 2021/09/08 09:03, Damien Miller wrote: > This is a case of the host key algorithm not matching, so you > should use HostKeyAlgorithms=+ssh-rsa - I'll make sure to mention > this in the release notes. People seem to really be having a hard time grasping what's being disabled by default. And it doesn't help with the confusion that a large well-known site doing a lot of SSH traffic for many users are handling ssh-rsa deprecation as "old user RSA keys will still work with SHA-1 but new ones will need SHA-2" (creating an artificial link between user keys and host key algorithm that doesn't exist in the protocol).
  Re: OpenSSH: RSA/SHA1 disabled by default
  On 2021/09/07 14:40, Martijn van Duren wrote: > On Mon, 2021-08-30 at 10:08 +1000, Damien Miller wrote: > > Hi, > > > >@ > > > > Thanks, > > Damien > > > Just did an update to the latest snapshot and this breaks connection > to one of the older hosts I still need to connect to from time to time. > > Reverting this diff fixes the issue for me. > > According to -G it should work: > > $ ssh -G -oPubkeyAcceptedAlgorithms=ssh-rsa 10.255.3.242 | grep -i > PubkeyAcceptedAlgorithms > pubkeyacceptedalgorithms ssh-rsa -oHostKeyAlgorithms=+ssh-rsa It works, I have disabled ssh-rsa by default for ages and have set that for various cisco/procurve switches that I need to connect to.
  Re: timeout: Prettify man page and usage
  On 2021/09/02 08:56, Job Snijders wrote: > On Thu, Sep 02, 2021 at 07:23:26AM +0100, Jason McIntyre wrote: > > > .Ar time > > > -can be integer or decimal numbers. > > > +are positive integer or real (decimal) numbers, with an optional > > > > can you have a negative timeout? > > Negative values are not permitted > > $ timeout -- -1 /bin/ls > timeout: invalid duration: Undefined error: 0 that's a terrible error message ;)
  Re: async traceroute(8)
  On 2021/09/01 11:25, Florian Obser wrote: > So traceroute sends one probe, waits upto 5^W3 seconds for an answer to > arrive, sends the next probe and so on. > > This makes it a bit faster (10x on a path with two intermediate systems > not answering) by sending probes, waiting for the answer and doing > reverse DNS lookups async. Basics are working here with icmp and udp. -A doesn't work reliably, try it with an empty cache - I think it only prints if the route lookup had a reply before the rdns lookup. I don't know libevent, is it possible to reset the timer and skip the 30ms delay if a response is received? Currently it's a little slower for the case where all hops respond. Hosts that don't respond result in a lot of *'s printed quickly, maybe scrolling the useful output off the terminal. The overall output is the same as the sequential version if you actually leave it to finish but most users would have hit ^C by then. I don't know what could be done to improve it (suppressing multiple * * * lines might help?) but user experience with that isn't great as-is. Try mp3.com for an example.
  Re: [Patch] - Add -u (update packages) to sysupgrade(8)
  On 2021/08/28 09:26, Sebastien Marie wrote: > On Fri, Aug 27, 2021 at 08:17:51PM -0500, Aaron Poffenberger wrote: > > Following is patch to add a flag to upgrade packages during > > rc.firsttime after a sysupgrade. > > > > if you need this flag, is it a ponctual usage (running sysupgrade with > the flag or not, depending the moment) ? or you will use it everytime > you use sysupgrade ? For my normal use, I decide at the time I run sysupgrade whether I want to update packages or not (if it's just a small bump in base, or I'm updating to test something quickly and it won't matter about packages, then I'll often skip it to save time - also I'll skip it if I know there's a major pgsql update in the way). I'd say my "more common" case would be to _not_ update. > for permanent usage, I would recommand using existing facility: the > /upgrade.site script. That's handy and I didn't know about it (though it does break /u for /usr tab-completion though :p). I don't think I'll use it for this usage but it's nice to have.
  Re: arm64 rpi4 upgrade, "Failed to install bootblocks" at end
  On 2021/08/28 22:28, Stuart Henderson wrote: > Oh and I see why I hit it now, I have this from when I was trying various u-boot changes (to make it easier to update the files from the booted system). $ grep boot /etc/fstab a3d7f93f60aec212.i /boot msdos rw,noatime 1 1
  arm64 rpi4 upgrade, "Failed to install bootblocks" at end installboot: unable to mount EFI System partition: Device busy Failed to install bootblocks. You will not be able to boot OpenBSD from sd0. syncing disks... done rebooting...
  Re: [patch] traceroute timeouts
  OK? Index: traceroute.8 === RCS file: /cvs/src/usr.sbin/traceroute/traceroute.8,v retrieving revision 1.69 diff -u -p -w -r1.69 traceroute.8 --- traceroute.811 Feb 2020 18:41:39 - 1.69 +++ traceroute.828 Aug 2021 08:56:20 - @@ -201,7 +201,7 @@ and are listed. .It Fl w Ar waittime Set the time, in seconds, to wait for a response to a probe. -The default is 5. +The default is 3. .It Fl x Print the ICMP extended headers if available. This option is not available for IPv6. Index: traceroute.c === RCS file: /cvs/src/usr.sbin/traceroute/traceroute.c,v retrieving revision 1.164 diff -u -p -w -r1.164 traceroute.c --- traceroute.c12 Jul 2021 15:09:21 - 1.164 +++ traceroute.c28 Aug 2021 08:56:20 - @@  =':
  Re: wg(4) ipv6 ospf6d
  On 2021/08/25 22:23, Sebastian Benoit wrote: > Stefan Sperling(s...@stsp.name) on 2021.08.25 22:02:02 +0200: > > On Wed, Aug 25, 2021 at 08:13:26PM +0200, Florian Obser wrote: > > > On 2021-08-25 18:02 +01, Stuart Henderson wrote: > > > >? > > > > > > > > > > RFC 4291 2.1: > > >All interfaces are required to have at least one Link-Local unicast > > >address. > > > > If you're not using the interface to send or receive OSPF messages this > > should not matter. I doubt the RFC authors considered the possibility > > of an IPv6-capable interface that doesn't support link-local. > > Thats because by definition it's not IPv6 capable :-P > > In this case, it should be possible to distribute a route that points to the > wg peer using > > redistribute _prefix_ depend on wg0 > > instead of using passive. > > If that does not work i would like to know why. > Yes this does work and I think I prefer it, thanks. (I had problems either with "redistribute" or with my expectations of what it would do before, but this seems alright..)
  Re: [Patch] - Add -u (update packages) to sysupgrade(8)
  On 2021/08/27 23:07, Aaron Poffenberger wrote: > On 2021-08-27 23:00 -0400, Daniel Jakots wrote: > > On Fri, 27 Aug 2021 20:17:51 -0500, Aaron Poffenberger > > wrote: > > > > > + ${PKGS} && echo "pkg_add -Iu" >> /etc/rc.firsttime > > > > I don't think this addition is worth it, but anyway this won't work for I do - I do this a lot manually and it's a pain to start sysupgrade downloading with -n, wait for it to finish, then edit the file so would welcome a flag to do it. I find the method helpful as it means you don't run outdated packages after reboot (which might even crash after some updates) and don't need to reboot 3 times (to bsd.rd for sysupgrade, then to the new kernel, then again to restart package daemons etc) which takes flipping ages on some servers. It's not perfect because some packages ask questions if pkg_adf is run in interactive mode (mostly just postgresql across major version updates). Aaron's diff uses -I to disable that which stops those packages from getting updated when the trigger condition applies, but that's not very common in the ports tree and doesn't make it less useful. The point at which rc.firsttime runs is after sshd starts, so if the package update does run into any problems you can still connect in to fix, and progress can be seen in "dmesg -s" or syslog. > > people running -current when it's release time and the release isn't > > available yet (-Dsnap). sysupgrade itself doesn't work properly in that case either, you need tricks to get from "not quite release but the -beta suffix was removed" to actual release. I think there might be other problems with the system relating to version handling in that time too. Basically we just need to keep that to the smallest possible time window. > Initially I considered a PKG_ADD environment variable to let the > override the command concatenated to /etc/rc.firsttime, but held > off until needed. Something like the following would resolve that > concern. > > PKG_ADD='pkg_add -Iu -Dsnap' sysupgrade -u No need for that complexity, just set a variable to -Dsnap if sysupgrade -s was used and include it on the line that adds pkg_add to the file. Bikeshed: I think I'd prefer using a -p flag to signify packages rather than -u.
  Re: wg(4) ipv6 ospf6d
  On 2021/08/25 19:58, Crystal Kolipe wrote: > On Wed, Aug 25, 2021 at 06:02:11PM +0100, Stuart Henderson wrote: > > If I manually configure a link-local the interface is successfully > > added. > > > > Anyone have an idea what the behaviour should be here? For passive > > would it make sense to accept an interface without link-local? > > Is there a specific use case for leaving the interface configured without > IPv6 link-local? > > We use IPv6 extensively, (and are aware of various issues with the OpenBSD > IPv6 implementation), but I'm not aware of any advantage or problem that is > resolved by deliberately removing or not configuring link-local. If we > support this particular case of wg on such an interface, and by extension > encourage the general practice, then users with little experience of IPv6 are > likely to start shooting themselves in the foot by disabling it on a whim. > > If there is a problem somewhere that is resolved by removing IPv6 link-local, > I'm curious to know what it is. > It's not a question of "removing IPv6 link-local", with wg it is not there at all unless you go out your way and explicitly configure a link-local address.
  Re: wg(4) ipv6 ospf6d
  On 2021/08/25 13:33, Daniel Jakots wrote: > On Wed, 25 Aug 2021 18:02:11 +0100, Stuart Henderson > wrote: > > > If I manually configure a link-local the interface is successfully > > added. > > > > Anyone have an idea what the behaviour should be here? For passive > > would it make sense to accept an interface without link-local? > > I discussed about that with remi@ a few months ago when I considered > using ospf6d, as I had the same cryptic error than you give. I was told: > > > ospf6d can not work without a link-local address on the interface. > > RFC 5340 mandates the use of link-local addresses in section 2.5. > > And here's a link to the mentioned section: > > > Cheers, > Daniel Thanks, but in itself that doesn't give a reason to have this restriction on a "passive" interface, in that case it's only redistributing the network on the interface, not sending OSPF packets on the interface itself.
  wg(4) ipv6 ospf6d?
  Re: allow KARL with config(8)'d kernels
  On 2021/08/25 10:35, Sebastien Marie wrote: > On Tue, Aug 24, 2021 at 01:53:41PM +0200, Paul de Weerd wrote: > > I have a new machine where I'd like to use IPMI. Of course, doing > > `config -e -f /bsd` will break KARL, so I tried to find a minimal way > > of supporting this. Done by introducing a new config file, > > /etc/kernel.conf, which gets applied to the kernel reorder_kernel > > builds and installs. > > I like it: it is simple. > > but here are some thoughts (with questions and some answers, but it is > open): > > - does it integrate well with syspatch ? > > yes, syspatch will call /usr/libexec/reorder_kernel (and the > configuration will be applied) > > > - after install or upgrade, does the installed kernel (by installer) > has the configuration applied ? > > it seems not: install.sub has it owns logic and is directly calling > "make newbsd ; make install" and do not use reorder_kernel script. > > > I could see reason to avoid it, and reason to requiring it. > > > For install, no problem: the file is controlled (it doesn't > exist). It doesn't change anything. > > For upgrade, the file could exists. Should the installer using it or > not ? > > > If using it, it makes the upgrade process dependent of the file: how > to deal with an invalid file ? should the file ignored (kernel > installed but not configured) ? I don't see a reason why upgrade shouldn't use it. Invalid file handling is no more or less of a problem for upgrades than reboots. > how to deal with a format change in config(8) (file on disk in old > format, used config(8) understanding new format) ? but config(8) > doesn't change often, and could take care of both formats for one > release, and/or current.html could mention some required changes. > > > If not using it, does it is a problem that the first boot will be > different from next boot ? > > I could imagine some changes made to be the machine bootable, so the > first boot could lead to unbootable machine (but it isn't different > from now). > Questions are open: I have no problem which using or not using the > configuration file on upgrade, but I think it should be documented (to > avoid questions and/or surprises). > Somebody had an earlier method for applying kernel config changes automatically that IIRC used a bootloader based mechanism passing the config to the kernel. I think that might actually be better overall as you could bypass it at the boot loader (rather than requiring a backup "clean" kernel) though that's more work and I expect difficult to do within space constraints on some archs. I would be quite happy to have this problem solved one way or another, while a "one size fits all" kernel should be the goal, there are some workarounds needed e.g. for semi-broken hardware and I think that's always likely to be the case.
  Re: pf.conf(5) about queueing may be wrong
  On 2021/08/23 22:21, Klemens Nanni wrote: > On Mon, Aug 23, 2021 at 07:03:45PM +0200, Solene Rapenne wrote: > > pf.conf says this in QUEUEING > > > > > > > If the referenced queue does not exist on the outgoing interface, > > > the default queue for that interface is used. > > This text is outdated, pfctl gained the below error in 2014 "shortly" > after henning reworked queueing in 2013 to where that manual text dates > back. > > > > > > > From the man page, I understand that if the queue used in match > > doesn't exist, the default queue is used, as if "queue dns" wasn't > > written in the rule. > > Specified queues must exist, rules without `[set] queue ...' do use the > default queue, obviously. > > > Either the man page is wrong or not easy to understand, or the > > parser is wrong. > > OK kn to remove that sentence from the manual. > Not ok with me.
  Re: pf.conf(5) about queueing may be wrong
  On 2021/08/23 19:03, Solene Rapenne wrote: > pf.conf says this in QUEUEING > > > > If the referenced queue does not exist on the outgoing interface, > > the default queue for that interface is used. > > In your config, the queue "dns" does not exist _at all_ in the config. > From the man page, I understand that if the queue used in match > doesn't exist, the default queue is used, as if "queue dns" wasn't > written in the rule. The manual talks about something a bit different, a queue that does not exist _on a particular interface_. > Either the man page is wrong or not easy to understand, or the > parser is wrong. I don't think it is wrong or even really hard to understand.
  Re: [patch] traceroute timeouts
  Shell aliases are good for that. I think I'd be happy with 3 seconds by default. 2 feels a bit short on overloaded links, GPRS, and some round-the-world packet trips -- Sent from a phone, apologies for poor formatting. On 20 August 2021 16:30:24 Tom Smyth wrote: Hello all,, would it make sense to have the value as a sysctl option or an environment variable ? so that it can be tailored for users /admins needs, On Fri 20 Aug 2021, 12:22 Mark Kettenis, wrote: > From: Florian Obser > Date: Fri, 20 Aug 2021 10:46:21 +0200 > > Makes sense to me, OK florian Doesn't make sense to me. The RTT for an ICMP packet can be a significant part of a second (think Europe-Australia the wrong way around cause that is where all the bandwidth is, or when satellites are involved). I think this means that a single dropped packet could result in a failure to resolve one of the hops on such a path. I don't necessarily object to giving folks the ammunition to shoot themselves into the foot by dropping the minimum value to 1 second. But the default should be larger I think. > On 2021-08-19 23:47 -07, wrote: > > The default traceroute timeout of 5 seconds is excruciatingly long > > when there are elements of the route that don't respond, and it > > wasn't allowed to be set lower than 2 seconds. > > > > This changes the minimum to 1 second, matching FreeBSD, and also > > makes that the default, which should be reasonable for the vast > > majority of users today. > > > > The two awk files in this directory are two decades old, and > > not installed anywhere they can be executed as part of a traceroute > > pipeline; can they be removed? If the functionality is useful, > > implementing mean/median reporting as a new option in C would be > > straightforward. > > > > Index: usr.sbin/traceroute/traceroute.8 > > === > > RCS file: /cvs/src/usr.sbin/traceroute/traceroute.8,v > > retrieving revision 1.69 > > diff -u -p -u -r1.69 traceroute.8 > > --- usr.sbin/traceroute/traceroute.811 Feb 2020 18:41:39 - 1.69 > > +++ usr.sbin/traceroute/traceroute.820 Aug 2021 06:33:30 - > > @@ -201,7 +201,7 @@ and > > are listed. > > .It Fl w Ar waittime > > Set the time, in seconds, to wait for a response to a probe. > > -The default is 5. > > +The default is 1. > > .It Fl x > > Print the ICMP extended headers if available. > > This option is not available for IPv6. > > Index: usr.sbin/traceroute/traceroute.c > > === > > RCS file: /cvs/src/usr.sbin/traceroute/traceroute.c,v > > retrieving revision 1.164 > > diff -u -p -u -r1.164 traceroute.c > > --- usr.sbin/traceroute/traceroute.c12 Jul 2021 15:09:21 - 1.164 > > +++ usr.sbin/traceroute/traceroute.c20 Aug 2021 06:33:30 - > > @@ ': > > > > > > -- > I'm not entirely sure you are real. > >
  Re: [patch] traceroute timeouts
  On 2021/08/20 10:46, Florian Obser wrote: > Makes sense to me, OK florian I think 1 second by default is still too short.
  Re: ucc(4): consumer control keyboard device driver
  On 2021/08/18 18:48, Martin Pieuchot wrote: > Regarding the introduction of a separate wskbd(4) this can be seen as an > intermediate step. Having this logic in ukbd(4) implies revisiting the > way reportID are mapped to USB drivers, which is still a bit of a hack > when it comes to supporting multiple of them. Talking of this, paco@ (cc'd) should send the lsusb from his USB-C dock...
  Re: snmp(1): Fix unsafe defaults
  On 2021/08/11 19:34, Martijn van Duren wrote: > On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote: > >? > > My reasoning being that setting having public the default in snmp(1) > might encourage users to set public in snmpd(8) as well, which is what > we tried to discourage. Hmm maybe. I won't object to that. > And it's easy enough to do something like > alias in .profile for interactive use and walk, bulkwalk, df, [...] FWIW I have this for now. - #!/bin/ksh if [[ -z $2 ]]; then /usr/bin/snmp 2>&1 | sed "s/snmp/`basename $0`/" >&2 exit 1 fi cmd=$1 shift exec /usr/bin/snmp $cmd -v 3 -l authPriv -u xxx [etc] $* - > and in scripts you always want to be > explicit with such parameters. Maybe. I do quite like keeping the secrets out of ps/top though. While I'm thinking about it, thoughts on this? Index: snmpd.conf.5 === RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v retrieving revision 1.56 diff -u -p -r1.56 snmpd.conf.5 --- snmpd.conf.510 Aug 2021 07:53:57 - 1.56 +++ snmpd.conf.511 Aug 2021 17:57:53 - @@ -402,12 +402,13 @@ Example configuration file. .Sh EXAMPLES The following example will tell .Xr snmpd 8 -to listen on localhost for SNMPv2c messages only with the public community, -override the default system OID, set the magic services value and provides some -custom OID values: +to listen on localhost for SNMPv2c messages only with the community +.Dq 8LHQtm1QLGzk , +override the default system OID, set the magic services value, +and provide some custom OID values: .Bd -literal -offset indent listen on 127.0.0.1 snmpv2c -read-only community public +read-only community 8LHQtm1QLGzk system oid 1.3.6.1.4.1.30155.23.2 system services 74
  Re: snmp(1): Fix unsafe defaults? (net-snmp tools do have that, but they also have /etc/snmp/snmp.conf or .snmp/snmp.conf so there's less to type on the command line). > Now that snmpd(8) moved on, so should snmp(1). > > OK? > > martijn@ > > Index: snmpc.c > === > RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v > retrieving revision 1.35 > diff -u -p -r1.35 snmpc.c > --- snmpc.c 8 Aug 2021 13:41:26 - 1.35 > +++ snmpc.c 11 Aug 2021 14:34:08 - > @@ -84,12 +84,12 @@ struct snmp_app snmp_apps[] = { > }; > struct snmp_app *snmp_app = NULL; > > -char *community = "public"; > +char *community = NULL; > struct snmp_v3 *v3; > char *mib = "mib_2"; > int retries = 5; > int timeout = 1; > -enum snmp_version version = SNMP_V2C; > +enum snmp_version version = SNMP_V3; > int print_equals = 1; > int print_varbind_only = 0; > int print_summary = 0; > @@ -468,7 +468,10 @@ main(int argc, char *argv[]) > argc -= optind; > argv += optind; > > - if (version == SNMP_V3) { > + if (version == SNMP_V1 || version == SNMP_V2C) { > + if (community == NULL || community[0] == '\0') > + errx(1, "No community name specified."); > + } else if (version == SNMP_V3) { > /* Setup USM */ > if (user == NULL || user[0] == '\0') > errx(1, "No securityName specified"); > >
  Re: CVS: cvs.openbsd.org: src
  On 2021/08/09 22:35, Martijn van Duren wrote: > Moving to tech@ > > On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote: > > On 2021/08/09 12:14, Martijn van Duren wrote: > > > CVSROOT:/cvs > > > Module name:src > > > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53 > > > > > > Modified files: > > > usr.sbin/snmpd : parse.y snmpd.c snmpd.conf.5 snmpd.h snmpe.c > > > util.c > > > > > > Log message: > > > Allow setting the engineid. > > > > > > The previous engineid was based aronud the engine boottime and a random > > > value, which gives problems when sending/receiving unacknowledged PDUs > > > (trapv2) over SNMPv3 with authentication enabled, which need a consistent > > > engineid across restarts to determine the correct user from the sender. > > > > > > The new default engineid takes a sha256 hash (chosen for its longer > > > output) > > > of gethostname(3) and places the first 27 bytes after the new format > > > number > > > 129. This should give us a very low probability of collisions, assuming > > > all machines have a unique name. > > > > what happens if there's a collision? i'm not sure it's safe to assume > > unique names. > > The engineid is used to load the engine context of the originator agent. > For unacknowledged pdu's this means at least loading the remote users > (unlike get requests the users, keys and engineid are from the > originator). > > If there's a collision for trapv2 this means that if a user exists on > both remote agents but with different keys one of them will fail. > > But if you want to enter a new user of a new system and you find that > that engineid already exist it should be a pretty big red flag that > there's a collision and the new system can explicitly set the engineid. > Similar if you ever want to set up something like "this engineid can > only send from this ip": If you see that a new systems engineid already > has such restriction it means you have to manually set the engineid. > > For existing get requests we don't have any risk: For acknowledged PDUs > (get*/set) the engineid will be discovered (RFC3414 Section 4). And > people can't have any hefty restrictions in place as is, because > previously it was randomly generated at startup, so no persistent > engineid to check on. > > I don't see any big risks here. > > A minor risk would be that if a hostname ever changes traps won't be > received anymore, since the engineid changes. But changing a hostname > seems like something that doesn't happen very often and brings with it > a lot more migration research. > > But considering the question if there was a better idea for generating > a consistent engineid by jmatthew@ on the 1st without any feedback I > went with this one. > If you still feel like there's a risk here after my previous reasoning > feel free to come up with an alternative. We still have time to change > it, and even then we have the range 130-255 to implement new formats > (although then we come back to the discussion about defaults without > negotiation) > > > > > The other formats as specified in SNMP-FRAMEWORK-MIB (RFC3411) are also > > > supported as well as arbitrary formats in the range 128-255 for other > > > private enterprise numbers in hex format. > > > > > > OK jmatthew@ > > > > > > > Thanks. I haven't looked closely at this before, I just know that it's common for agents to set it randomly at startup (net-snmp docs say "must be consistent through time and should not change or conflict with another agent's engineID. Ever." which isn't exactly clear which is the stronger requirement - consistency or not conflicting). Regarding the commit, the manual doesn't mention that there's a default. Should it? e.g. maybe Index: snmpd.conf.5 === RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v retrieving revision 1.54 diff -u -p -r1.54 snmpd.conf.5 --- snmpd.conf.59 Aug 2021 19:13:08 - 1.54 +++ snmpd.conf.59 Aug 2021 20:57:10 - @@ -153,6 +153,7 @@ generation for the .Ar auth and .Ar key . +By default, a hash of the system hostname is used. .Ar enterprise specifies the private enterprise number of the instance and can be either an integer or .
  Re: snmpd: tweak listen on
  On 2021/08/09 20:55, Martijn van Duren wrote: > Updated diff after my engineid commit. ok > Index: snmpd.conf.5 > === > RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v > retrieving revision 1.53 > diff -u -p -r1.53 snmpd.conf.5 > --- snmpd.conf.5 9 Aug 2021 18:14:53 - 1.53 > +++ snmpd.conf.5 9 Aug 2021 18:54:56 - > @@ -96,9 +96,22 @@ reduced during bulk updates. > The default is > .Ic no . > .It Ic listen on Oo Ic tcp | udp Oc Ar address Oo Ic port Ar port Oc Op Ar > flags > -Specify the local address > +Specify the local > +.Ar address > .Xr snmpd 8 > should listen on for incoming SNMP messages. > +If > +.Ar address > +is set to > +.Cm any , > +it resolves to 0.0.0.0 and ::. > +Multiple > +.Ic listen on > +statements are supported. > +If no > +.Ic listen on > +statement is present, the default is > +.Ic listen on Cm any . > .Pp > The > .Ar flags while most snmpd users will likely know what 0.0.0.0 and :: are, this might be a bit friendlier (and is shorter) Specify the local .Ar address .Xr snmpd 8 should listen on for incoming SNMP messages, or .Cm any to listen on all local IPv4 and IPv6 addresses. Multiple .Ic listen on statements are supported. If no .Ic listen on statement is present, the default is .Ic listen on Cm any .
  Re: dhcpleased(8): ignore servers / parts of lease
  On 2021/08/09 15:03, Andras Vinter wrote: > It's probably an overkill for first implementation, but in the future > I think we should support subnet definitions in CIDR notation (e.x.: > 192.168.0.0/24) and IP ranges for fine control (e.x.: > 192.168.0.100-192.168.0.254). dhclient never needed that.
  Re: Fix unsafe snmpd defaults
  On 2021/08/08 10:05, Martijn van Duren wrote: > > +++ > > This is probably is a bad example. > Reading it like this: you're correct that we listen on all interfaces > by default, but that's not listed in snmpd.conf(5). So that should > probably be fixed (including mentioning that setting one "listen on" > disables the all interfaces default). Let's handle that separately. (it would be convenient to support "any" to mean any v4+v6 as well). > Second, your examples enable snmpv2c on all interfaces, while you > enable an implicit snmpv3 on 127.0.0.1. This should probably be the I wasn't intending that they should all be uncommented at once, just showing some common options. And actually it seems snmpd doesn't allow listening to 0.0.0.0 as well as a specific v4 address (and similarly for :: and v6) so while it's a convenient idea to allow v2c on localhost for quick testing while using v3 for external traffic, it doesn't actually work. > other way around, or replace 127.0.0.1 with something like > "listen on 192.168.0.2 snmpv2c" to map with source-address by trap > receiver. And an additional > "listen on 0.0.0.0 > listen on ::" > to make it clear that snmpv2c should only be enabled on internal > networks, but snmpv3 is less of a problem. For users who haven't got round to figuring out SNMPv3 yet, they'll need to know how to listen with v2c, so I think that's still going to be quite a common use case. Hence including that specifically. > > -# Specify a number of trap receivers > > -#trap receiver nms.localdomain.local > > +# Enable SNMPv3 USM with authentication, encryption and two defined users > > This sentence feels wrong, it is enabled by default. > Also, since we only enable SNMPv3 by default, maybe also make it > clear that at least one user should be created? Something like: > # SNMPv3 USM users. At least one user should be created to use SNMPv3. > > +#seclevel enc > > This is the default and if we would ever change this default back (I > can't imagine we ever will, but who knows) it still wouldn't break. > So maybe just leave seclevel out of the example, or show how to use > it for e.g. authNoPriv. Makes sense. Let's leave it out for simplicity. > > + PAV9kpE02gDPvAi > > source-address 192.0.2.1 > > At this time (with future additions in mind) I think that oid would be > more useful than source-address. > One example I can think of that could be possible if I manage to get > agentx back up and running and we add agentx support to vmd (I have a > working PoC). Mischa could send traps to individual users for > OpenBSD.amsterdam. Just a random example that's top of my mind, not > claiming any realism. I'll skip source-address in the trap receiver example then. When trap does something more than it does now we could add oid in if it's going to be useful to more than just niche users. (fwiw the traps that I'd find most useful internal to snmpd are interface up/down; and with external hooks traps for bgp peers dropping out would be pretty great). > > # Adjust the local system information > > #system contact "Charlie Root (r...@myhost.example.com)" > > #system description "Powered by OpenBSD" > > #system location "Rack A1-24, Room 13" > > -system services 74 > > > > -# Provide static user-defined SNMP OIDs > > -oid 1.3.6.1.4.1.30155.42.3.1 name testStringValue read-only string "Test" > > -oid 1.3.6.1.4.1.30155.42.3.4 name testIntValue read-write integer 1 > > I fully agree that these should go. This whole oid keyword is just > clutch (limited data types, assuming an oid should be turned into a > scalar by appending a zero) > > - > > -# Enable SNMPv3 USM with authentication, encryption and two defined users > > -#seclevel enc > > -#user "user1" authkey "password123" enc aes enckey "321drowssap" > > -#user "user2" authkey "password456" enckey "654drowssap" > > +# Required by some management software > > +#system services 74 > > Maybe you can explain how admins can change the value to something > correct for their environment? :-) > Or maybe we should add something like > system services physical|datalink|internet|endtoend|applications > to parse.y and let snmpd(8) create the
  Re: Fix unsafe snmpd defaults
  On 2021/08/07 15:17, Martijn van Duren wrote: > Let me give one final pushback, if this doesn't convince you then feel > free to commit sthen's diff without my OK, but make sure it stays in > sync with snmp(1). I was convinced enough to try it, hence okaying your previous diff, but practical experience after updating some production machines got me to reconsider. What happened in my case: updated machine running snmpd, stopped getting monitoring in one place, reconfigured that to use sha256 (which either involves click-click-click in a web interface or poking a database table), noticed some other stats weren't working too, spent quarter of an hour figuring out how to tell the collector to use sha256, eventually working out that it's not possible, revert the snmpd config, revert clicky click, ended up with the same algorithms as before but wasted time. Then I updated another one enough later that I'd forgotten about the first until partway through the cycle again... > First let me sum up what defaults have changed since 6.9: > - community authentication disabled (snmpv1/snmpv2c) > - no default community name set set So this one breaks old SNMPv2 configs unless config is changed. Between the widely abused and scanned-for UDP amplification vector on "public", the hidden default "private" RW community that I bet many people have enabled even if they changed public, and old snmpd still accepting v2 sessions when v3 was configured (as I discovered thanks to shadowserver after I reconfigured it to use v3 "to improve security"), I think that was absolutely the right thing to do. > - seclevel moved from none to enc I will honestly be very surprised if this affects anyone, you have to set the username/keys to configure SNMPv3 at all so you're highly likely to configure them into the management station too. Possibly fixes an amplification vector if you have a poorly chosen username but not all that likely. > - enc moved from des to aes Might affect some users but I find it hard to believe it will be many. Which OpenBSD sysadmin going to the trouble of configure SNMPv3 is going to voluntarily pick des when aes is on offer, shown in the example config file, and widely supported? > - auth moved from hmac-sha1 to hmac-sha256 ...whereas there are good reasons why someone would use hmac-sha1 rather than hmac-sha256, and auth is the only part of the usm settings not shown in examples/snmpd.conf, # Enable SNMPv3 USM with authentication, encryption and two defined users #seclevel enc #user "user1" authkey "password123" enc aes enckey "321drowssap" #user "user2" authkey "password456" enckey "654drowssap" (The thing I'm most concerned about with snmpd-provided SNMP service is easily guessed defaults, especially with regard to the UDP amp vector. It would be better to keep SNMP-provided stats more private, but that's further down the list, and totally off the list for anyone currently running with v2c and "public"). Updated diff below. I've rearranged examples/snmpd.conf some more, explictly listed auth/enc algs for all usm examples, got rid of the oid settings that are specialist enough that someone wanting them can read the manual, and shown setting the v2c community if needed. (I pondered getting rid of "trap receiver" as well as it doesn't do a lot in snmpd yet, only coldStart, but it has potential so I showed some options instead). (And now that I realise "the complicated services alg" is actually "bitwise OR of 2^(OSI layer number) for all supported layers" I am now going to step away from the computer and try to forget it ;) Index: etc/examples/snmpd.conf === RCS file: /cvs/src/etc/examples/snmpd.conf,v retrieving revision 1.1 diff -u -p -r1.1 snmpd.conf --- etc/examples/snmpd.conf 11 Jul 2014 21:20:10 - 1.1 +++ -# Restrict daemon to listen on localhost only -listen on $listen_addr +# Define a RO community if you use SNMPv2c (there is no default) +#read-only community MWgp3MWbD2khaYnwy2B -# Specify a number of trap receivers -#trap receiver nms.localdomain.local +# Enable SNMPv3 USM with authentication, encryption and two defined users +#seclevel enc +
  Re: Fix unsafe snmpd defaults
  On 2021/08/03 23:46, Martijn van Duren wrote: > On Tue, 2021-08-03 at 21:58 +0100, Stuart Henderson wrote: > > 11 Jul 2014 21:20:10 - 1.1 > > > +++ snmpd.conf 3.. > > > I think that these management software applications should join 2016 and start > implementing it and until then its just two or four minor keywords per user. > But I'm not a heavy user of 3rd party mangement software. "Given the lack of support for SHA2-256 in much management software _until recently_". What they do now is only relevant to new configurations, it's what they did in the past when they were configured that determines what people are using in existing config and whether they'll have to reconfigure things to cope with the default changing. Since even hmac-md5 is still AFAIK not considered unsafe (hmac is a very different thing to using the algorithm for file integrity checks) and there are clearly still issues with sha2-256 in SNMP I think we're probably better off reverting that part of the defaults change and go back to hmac-sha1. Diff for that below - it also fixes some text missed in the previous change des->aes, a
  Re: rpki-client support more http status codes
  On 2021/08/04 19:58, Sebastian Benoit wrote: > just as i had looked them up :P My usual quick http status code reference doesn't even have 103 (and the graphical representation of is a bit confusing :)
  Re: Add versioned lib to system perl's @INC for non-packaged modules
  On 2021/08/04 19:45, Ingo Schwarze wrote: > Hi Andrew, > > Andrew Fresh wrote on Fri, Jul 30, 2021 at 05:34:40PM -0700: > > On Sun, May 16, 2021 at 03:30:39PM -0700, Andrew Hewus Fresh wrote: > > >> There do appear to be some annoyances with still shared directories for > >> man pages, in that if you install a CPAN module and then attempt to > >> pkg_add it, it complains because "files already exist" in the man > >> directory. We could separate the cpan man pages, or I think un-setting > >> the site_lib man*dir will mean cpan won't instal them. I haven't yet > >> tested that, but I'm not sure what would be best there. > > If i understand correctly, this is all about making installation of > un-ported Perl modules work better and reducing clashes between doing > that on the one hand and between package installation with pkg_add(1) > on the other hand. Correct. The specific problem that prompted this was people who had installed something locally outside of ports - I think it was an updated version of a core perl module - and made worse by pkg_add at the time searching /usr/local/libdata/perl5/site_perl for modules and refusing to run until the locally built module was removed. pkg_add now uses "no lib ('/usr/local/libdata/perl5/site_perl')" so it won't run into the same problem any longer, but most other perl software is likely to still have the problem. > Who will profit most from that? I guess very experienced Perl users > and porters who play around a lot with many different Perl modules > and with very large Perl programs, in particular when evaluating > whether those large programs are worth porting. Not having manual > pages installed for dependencies while trying to get a complicated > program to work and while trying to understand it seems like a > disservice to me. So "un-setting the site_lib man*dir" doesn't > strike me as particularly convincing on first sight. > > I guess ordinary users are less likely to use this route, they are more > likely to just use pkg_add(1). But if they do, for whatever reason, > not getting manual pages is not good for them, either. I think it's likely to be the other way round, at least people with more experience of OpenBSD are more likely to start by making a port, partly because they realise that installing modules from CPAN can cause problems, partly to make it easier to clean up if needed. I think ordinary users who need something that isn't ported are probably more likely to pick it up from CPAN instead. (then, if they're more experienced with Perl, they'll realise the cause of the "key mismatch" error quickly and know what to do with it). > So i think in the long term, installing those manual pages into their > own manpath outside /ust/local/man/ would seem desirable to me. > I'm not saying it needs to be done in the same commit; sorting that > out can certainly be a later step. I agree with all this. > You suggest to make the sitelib directory versioned. Consequently, > i guess that you want the following process to work: > > 1. install base and arbitrary numbers of packages > 2. install lots of modules and programs from CPAN for evaluation > 3. install the next Perl version outside base to figure out what > needs to be done to ultimately move base to it > 4. install various modules for the new Perl from step 3 > for testing purposes > > If i got that right, then the new man directory needs to be versioned > just like the new sitelib directory, or the manual pages from steps 2 > and 4 will clash just like the libraries from steps 2 and 4 would. > The price to pay, of course, is that you need to edit man.conf(5) > for each new Perl you install. And not just you, the base system > Perl maintainer, but all users installing stuff from CPAN. I think perldoc would pick them up anyway - if so, users still have an easy way to read the docs without editing man.conf. > On the other hand, if working with two different Perl versions in > parallel is not a requirement (for example because people do testing > like in steps 3 and 4 on separate machines?), then i don't see why > either the sitelib or the new man dir needs to be versioned at all, > making everything simpler. I think it's mostly to mitigate some user problems (at least, make it so they are more obvious and less likely to need somebody more experienced to point out what the problem is). On the one hand, that is already reduced by the pkg_add change. But on the other, if it's simple enough to reduce problems further then, as long as it doesn't get in the way too much, why not..
  Re: Fix unsafe snmpd defaults11 Jul 2014 21:20:10 - 1.1 > +++ snmpd.conf3..
  Re: Fix unsafe snmpd defaults..
  Re: iked(8): Increase the default Child SA data lifetime limit
  On 2021/08/03 17:02, Vitaliy Makkoveev wrote: > > - a 50% lower limit feels too low to me > > > > Why? The 95% limit is too close to lifetime expiration and as it was > exposed we don't have enough time to perform rekeying. I also had this > problem while tested iked(8) over WIFI connection and this is one of > real-world usage cases. Rekeying with 9-18 minutes spare out of a 180 minute lifetime seems pretty good to me. Rekeying with 72-90 minutes left of a 180 minute lifetime seems way too early. For bytes, if 10% of the byte lifetime isn't long enough to complete a rekey, that really suggests to me the lifetime is set too low, not that the jitter amount is too low.
  Re: iked(8): Increase the default Child SA data lifetime limit
  On 2021/08/03 01:12, Vitaliy Makkoveev wrote: > iked(8) uses 3 hours and 512 megabytes of processed data as default > lifetime hard limits for Child SA. Also it sets 85-95% of these values as > soft limit. iked(8) should perform rekeying before we reach hard limit > otherwise this SA will be killed and the tunnel stopped. With default > values the window is only 25-52 megabytes and we easily consume them > before rekeying and the tunnel stops. > > Hrvoje Popovski complained about such stops when he has tested ipsec(4) > related diffs. I also tried iked(8) with my macos and found that simple > "ping -f ..." makes rekeying impossible. > > The hard limit could be modified in iked.conf(5) by setting "lifetime > xxx bytes yyy", but the 5% difference between hard and soft limits forces > to set bytes limit big enough, about 4G and more, which could be bad for > security reason. > > I propose to increase the default hard limit at least up to 1G. Also I > propose to decrease the soft limit down to 50-60% of hard limit. This > keeps the rekeying frequency but increases the update window to 410-512 > megabytes. Also this allow to keep bytes in "lifetime" setting small > enough. I have a couple of comments; - this isn't a problem I've run into with real-world usage or when running tcpbench over (moderately fast) internet connections - I'm not saying it doesn't happen, but it seems relatively uncommon, with connections at LAN speeds of course it's much more likely - a 50% lower limit feels too low to me - your jitter change affects lifetime both in seconds and in bytes, I think changing the jitter for the seconds lifetime is a mistake - the jitter change could result in some really short rekey intervals if somebody has manually specified lifetimes which are the same as or less than the current default - looking at other IKEv2 implementations: if bytes lifetime is supported at all (several implementations don't have it, only time-based lifetime), the default settings rarely seem to use it - 512MB is not really a lot of data My first though now I know about this problem is just to increase the default byte limit and leave the jitter range as-is. I don't know enough about the security requirements of IKEv2 to know what demands it places on rekeying, but given the above (especially that other implementations mostly don't use byte limits at all), the figure I'd pull out of the air would be more like 4GB. > Index: sbin/iked/iked.conf.5 > === > RCS file: /cvs/src/sbin/iked/iked.conf.5,v > retrieving revision 1.85 > diff -u -p -r1.85 iked.conf.5 > --- sbin/iked/iked.conf.5 11 Apr 2021 23:27:06 - 1.85 > +++ sbin/iked/iked.conf.5 2 Aug 2021 21:41:55 - > @@ -586,8 +586,8 @@ parameter defines the Child SA expiratio > SA was in use and by the number of > .Ar bytes > that were processed using the SA. > -Default values are 3 hours and 512 megabytes which means that SA will be > -rekeyed before reaching the time limit or 512 megabytes of data > +Default values are 3 hours and 1024 megabytes which means that SA will be > +rekeyed before reaching the time limit or 1024 megabytes of data > will pass through. > Zero values disable rekeying. hm, this doesn't mention jitter. I think it should. Perhaps something like this. Default values are X hours and Y megabytes. Rekeying is initiated at between A% and B% of the limit; if unsuccessful the SA will not be allowed to continue beyond the hard limit. > -#define IKED_LIFETIME_BYTES 536870912 /* 512 Mb */ > +#define IKED_LIFETIME_BYTES 1073741824 /* 512 Mb */ Comment is now wrong. I think I would write this as N * 1024 * 1024 and remove the comment, but if not then the comment needs to match. > #define IKED_LIFETIME_SECONDS10800 /* 3 hours */ > > #define IKED_E 0x1000 /* Decrypted flag */ >
  Re: dhcpleased vs gif(4) (and othes like that)
  On 2021/08/01 12:57, Gregory Edigarov wrote: > Hello Everybody, > > The very minimal change to make it work correctly: Running configuration twice on all interfaces is not 'very minimal' and could easily cause more problems than it solves. > +# We need to run /etc/netstart two times, first is to set autoconf > flags and static addresses > sh /etc/netstart > > mount -s /usr >/dev/null 2>&1 > @@ -456,6 +457,9 @@ > > start_daemon dhcpleased unwind resolvd >/dev/null 2>&1 > > +sleep 5 We have a "wait for routes to show up" mechanism rather than a fixed sleep for a reason. > +# On second run, it will reconfigure interfaces, setting proper > addresses on interfaces which depend on phys ones, like gif(4), or gre(4) > +sh /etc/netstart I would currently suggest either 1) use dhclient instead ("!dhclient $_if" in the hostname file will do) or 2) configure that from rc.local instead. Most use of gif(4) doesn't need this. Is this so you can use hostnames in the files, or something else?
  Re: ahci(4): Add support for JMicron JMB585 chipset
  On 2021/07/25 13:25, Mark Kettenis wrote: > > Date: Sun, 25 Jul 2021 12:08:09 +0100 > > From: Stuart Henderson > > > >). > > Hmm, that suggests that the right fix might actually be to add > pciide(4) on riscv64. The FreeBSD commit is "do not allow hw.ahci.force to work with this device" so kind-of the opposite of that.
  Re: ahci(4): Add support for JMicron JMB585 chipset).
  Re: dhcpleased: default route with classless static routes option
  On 2021/07/17 13:16, Bjorn Ketelaars wrote: > An inconsistency exists between dhclient(8) and dhcpleased(8) when > receiving the Classless Static Routes option: dhcpleased creates a > default route, while dhclient does not. > > If I'm not mistaken, the behaviour of dhclient is correct. From rfc3442: > "If the DHCP server returns both a Classless Static Routes option and a > Router option, the DHCP client MUST ignore the Router option." That is correct. > Comments? > > > diff --git sbin/dhcpleased/dhcpleased.c sbin/dhcpleased/dhcpleased.c > index 2157406e71a..93df9f55e7f 100644 > --- sbin/dhcpleased/dhcpleased.c > +++ sbin/dhcpleased/dhcpleased.c > @@ -819,7 +819,7 @@ configure_routes(uint8_t rtm_type, struct > imsg_configure_interface *imsg) > { > struct sockaddr_in dst, mask, gw, ifa; > in_addr_taddrnet, gwnet; > - int i; > + int csr = 0, i; > > memset(, 0, sizeof(ifa)); > ifa.sin_family = AF_INET; > @@ -840,6 +840,13 @@ configure_routes(uint8_t rtm_type, struct > imsg_configure_interface *imsg) > > addrnet = imsg->addr.s_addr & imsg->mask.s_addr; > > + for (i = 0; i < imsg->routes_len; i++) { > + if (imsg->routes[i].dst.s_addr != INADDR_ANY) { > + csr = 1; > + break; > + } > + } > + > for (i = 0; i < imsg->routes_len; i++) { > dst.sin_addr.s_addr = imsg->routes[i].dst.s_addr; > mask.sin_addr.s_addr = imsg->routes[i].mask.s_addr; > @@ -872,6 +879,15 @@ configure_routes(uint8_t rtm_type, struct > imsg_configure_interface *imsg) > /* directly connected default */ > configure_route(rtm_type, imsg->if_index, > imsg->rdomain, , , , NULL, 0); > + } else if (csr) { > + /* > + * RFC3442 states that if the DHCP server returns > + * both a Classless Static Routes option and a > + * Router option, the DHCP client MUST ignore the > + * Router option. > + */ > + log_warnx("%s: ignoring router option", > + __func__); > } else { > /* default route via gateway */ > configure_route(rtm_type, imsg->if_index, >
  Re: xmm(4): WIP diff for Intel XMM7360 LTE modem
  On 2021/07/09 17:22, Stuart Henderson wrote: >. If anyone else wants to play, here's a port roughly based on the one in pkgsrc. Obviously not optimal but it is nice to be able to see it working. xmm7360.tgz Description: application/tar-gz
  Re: xmm(4): WIP diff for Intel XMM7360 LTE modem.
  Re: xmm(4): WIP diff for Intel XMM7360 LTE modem ;)
  Re: systat(1) counter overflow
  On 2021/07/03 01:09, Anindya Mukherjee wrote: > Thanks for the discussion. This has been very illuminating. I have been > digging > around in /usr/src/ and ignoring the atomic architectures (where I got stuck) > it > looks like it should be possible to use uint64_t everywhere. I'm playing with > some changes on my machine to see if I can get at least systat(1) and > vmstat(8) > to work with uint64_t. The ddb printer (uvmexp_print)is another consumer. > > If it works in the base system then ideally every relevant port should be > updated to be consistent. That is indeed quite a big change; more than I > realised so thanks for setting me straight on that. We have coped with bigger changes in structs like this before, it didn't used to be too difficult, but that was before go...
  Re: systat(1) counter overflow
  On 2021/07/02 13:43, Stuart Henderson wrote: >. FWIW in the year-old ports source that was 41 ports (special prize for sysutils/nomad which managed to include 3 separate copies), there are probably a few more now.
  Re: systat(1) counter overflow
  On 2021/07/02 13:09, Martin Pieuchot wrote: > On 01/07/21(Thu) 13:53, Anindya Mukherjee wrote: > > Hi, > > > > I noticed that if I leave the system running for more than about a month, > > some > > of the counters in the uvm view of systat(1) overflow and become negative. > > This > > is because the members of struct uvmexp in sys/uvm/uvmexp.h are ints. The > > kernel's internal counters are of course uint64_t so they don't overflow. It > > only happens during the uvm_sysctl(9) call which casts the numbers to > > integers. > > The function is uvmexp_read. > > > > In the attached diff I took the path of least resistance and promoted some > > of > > the counters to unsigned int. Ideally I would have liked to use int64_t or > > even > > uint64_t, but I hit an issue in some of the architecture dependent code. An > > example is: > > /usr/src/sys/arch/alpha/alpha/trap.c:536 atomic_add_int(, > > 1); > > In other places the ++ operator is used to increment the counters and the > > 64 bit > > types can be used. > > > > I am not completely sure this is the best way to proceed, but even if this > > diff > > is horrifying, I'd appreciate some feedback and advice, thanks! > > I wonder if we shouldn't use uint64_t for those and embrace the ABI > break, that would at least simplify the kernel side and remove a > truncation. > > Do you have an idea of the different consumers of the "struct uvmexp" > apart from systat(1)? What is the impact in userland & ports of such > change? It's used by a couple of dozen ports, from a search over 1-year-old ports source: lcdproc libuv, embedded copies (incl electron, node, ruby-passenger) py-uv py-psutil, embedded copies (incl spidermonkey + firefox ports) libstatgrab, embedded copies (digikam) jdk libgtop2 py-gevent net-snmp zabbix plan9port conky bubblemon-dockapp facter gkrellm free htop monit node_exporter p5-Sys-MemInfo slant tmux-mem-cpu-load xuvmstat xfce4-systemload xfce4-taskmanager Most of these would just need a recompile, so would either need a REVISION bump in the port, or in most cases bumping libc would be enough to trigger pkg_add -u to update them (some exceptions e.g. py-psutil, py-uv, py-gevent don't depend on libc and would need to be bumped separately).. Some of those ports include gopsutil which increases the chance things from struct uvmexp might actually be used (including sqlc, keybase, vault, consul, nomad, packer). Some other go ports are either very likely to use uvmexp things e.g. at least some of the sysutils/beats/XXX ports. (And I listed node_exporter in the main list above as it's almost certain).
  Re: SiFive Unmatched radeondrm/amdgpu
  On 2021/06/25 21:41, Mickael Torres wrote: > Here is a new version of the diff, based on an up-to-date tree, and > (hopefully) with tabs as tabs. Hi, the tabs are fixed now, but it's word-wrapped so still causes indigestion for patch(1). This suggestions a setting which may help: Some of the edited lines are now quite long, if you could keep to <80 columns (with the relevant number of tabs plus a 4-space indent on continuation lines) that will reduce the editing that someone who commits would need to do.
  Re: snmpd(8) Better traphandler flow
  On 2021/06/20 22:31, Martijn van Duren wrote: > On Fri, 2021-06-11 at 16:13 +0200, Martijn van Duren wrote: > > any takers? > > > > On Fri, 2021-06-04 at 22:11 +0200, Martijn van Duren wrote: > > > ping > > > > > > On Fri, 2021-05-28 at 08:19 +0200, Martijn van Duren wrote: > > > > As the original comment said: > > > > /* > > > > * This should probably go into parsevarbinds, but that's for a > > > > * next refactor > > > > */ > > > > > > > > This moves the pdu parsing of traps into parsevarbinds. > > > > Added bonus, we can now see the packets in debugging mode: > > > > startup > > > > snmpe: listening on udp 127.0.0.1:162 > > > > ktable_new: new ktable for rtableid 0 > > > > snmpe_parse: 127.0.0.1:162: SNMPv2 'public' pdutype SNMPv2-Trap request > > > > 1329591927 > > > > snmpe_parse: 127.0.0.1:162: SNMPv1 'public' pdutype Trap request 0 > > > > > > > > OK? > > > > > > > > martijn@ > > > > > Somehow this one survived the tightened security mayhem with only a few > offset warnings. Still looking for OKs. I don't know snmpd well enough to give a considered OK for this (and don't use snmpd's trap handler, figure that if I'm going to need to call net-snmp code to translate the numeric oid anyway I might as well use their trapd), it does seem generally neater to me > @@ -460,7 +457,14 @@ snmpe_parsevarbinds(struct snmp_message > struct ber_element *pvarbind = NULL, *end; > char buf[BUFSIZ]; > struct ber_oid o; > - int i; > + int i = 1; > + > + if (msg->sm_pdutype == SNMP_C_TRAP || > + msg->sm_pdutype == SNMP_C_TRAPV2) { > + if (traphandler_parse(msg) == -1) > + goto varfail; > + return 0; > + } > > msg->sm_errstr = "invalid varbind element"; > > @@ -468,7 +472,7 @@ snmpe_parsevarbinds(struct snmp_message > msg->sm_varbindresp = NULL; > end = NULL; > > - for (i = 1; varbind != NULL && i < SNMPD_MAXVARBIND; > + for (; varbind != NULL && i < SNMPD_MAXVARBIND; > varbind = varbind->be_next, i++) { > if (ober_scanf_elements(varbind, "{oeS$}", , ) == -1) { > stats->snmp_inasnparseerrs++; not sure moving the initializer for i here is an improvement though, seems better to have the loop more self-contained?
  Re: Fix unsafe snmpd defaults
  Index: current.html === RCS file: /cvs/www/faq/current.html,v retrieving revision 1.1071 diff -u -p -r1.1071 current.html --- current.html26 May 2021 12:12:58 - 1.1071 +++ current.html20 Jun 2021 11:58:05 - @@ -65,6 +65,36 @@ to update /etc/raddb/mods-available/eap lines. +2021/06/20 - snmpd authentication changes + +Default authentication settings in;>snmpd(8) have been tightened. +You may need to adjust +;>snmpd.conf(5) and/or +configuration of your SNMP management stations. +Preferably use SNMPv3 with AES/SHA-256 or better. + +For SNMPv1/v2c, previously it responded to requests for communities named +"public" or "private" unless alternative communities were set; this has +changed so that there are no default communities. +If you would like it to continue to respond to the community named "public" +then set read-only community public (do not use this if the +service is accessible from the internet; UDP SNMP with insecure +authentication is a potent packet amplifier). read-write +disabled has been removed as this is now the default. + +For SNMPv3, previously it responded to SNMPv3 "noAuthNoPriv" requests +(without authentication) unless "seclevel" was used. +This has changed to requiring authentication and encryption by +default. +If you would like it to continue to respond without authentication, +set seclevel none. +If you would like it to respond with authentication but without +requiring encryption, set seclevel auth. +The default authentication has changed to hmac-sha256 +and the default encryption to AES. + +
  Re: Fix unsafe snmpd defaults
  On 2021/06/20 12:46, Martijn van Duren wrote: > And here's the diff to change the crypto defaults. > > Currently snmp(1) and snmpd(8) don't match up by default since snmp(1) > uses md5/des as per RFC3414 (sha-1 is a should, md5 is a must) and > net-snmpd's defaults, where snmpd(8) uses sha-1/des. > > While I haven't heard that md5 and/or sha1 are broken in HMAC context; > I'd argue that using them is bad practice in general and setting them as > defaults isn't done anymore. RFC7860 states that > usmHMAC192SHA256AuthProtocol is a must and usmHMAC384SHA512AuthProtocol > a should. So I'd guess it's best to stick with SHA256 as default, even > though the resulting HMAC is truncated to 192 bits. > > As for the encryption bit, I guess I don't have to explain why changing > from DES to AES-128 (RFC3826) by default would be a good decision. > > Diff should be able to apply stand alone and on previous diff. > > I want to commit this one at the same time as the previous diff. > > OK? OK. I'm not sure what was up with my hmac-sha256 tests earlier but I'm unable to reproduce the problem now. > Index: usr.sbin/snmpd/snmpd.conf.5 > === > RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v > retrieving revision 1.48 > diff -u -p -r1.48 snmpd.conf.5 > --- usr.sbin/snmpd/snmpd.conf.5 14 Jun 2021 12:28:58 - 1.48 > +++ usr.sbin/snmpd/snmpd.conf.5 20 Jun 2021 10:37:50 - > @@ -276,7 +276,7 @@ must be either > or > .Ic hmac-sha512 . > If omitted the default is > -.Ic hmac-sha1 . > +.Ic hmac-sha256 . > .Pp > With > .Ic enckey > @@ -292,7 +292,7 @@ algorithm can be either > or > .Ic aes > and defaults to > -.Ic des . > +.Ic aes . > .Pp > Any user account that has encryption enabled requires authentication to > be enabled too. > @@ -350,7 +350,7 @@ algorithm. > seclevel enc > > user "hans" authkey "password123" enc aes enckey "321drowssap" > -user "sophie" authkey "password456" enckey "654drowssap" > +user "sophie" authkey "password456" enc des enckey "654drowssap" > .Ed > .Sh SEE ALSO > .Xr snmp 1 , > Index: usr.sbin/snmpd/snmpd.h > === > RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v > retrieving revision 1.95 > diff -u -p -r1.95 snmpd.h > --- usr.sbin/snmpd/snmpd.h20 May 2021 08:53:12 - 1.95 > +++ usr.sbin/snmpd/snmpd.h20 Jun 2021 10:37:51 - > @@ -522,7 +522,7 @@ enum usmauth { > AUTH_SHA512 /* usmHMAC384SHA512AuthProtocol. RFC7860 */ > }; > > -#define AUTH_DEFAULT AUTH_SHA1 /* Default digest */ > +#define AUTH_DEFAULT AUTH_SHA256 /* Default digest */ > > enum usmpriv { > PRIV_NONE = 0, > @@ -530,7 +530,7 @@ enum usmpriv { > PRIV_AES/* CFB128-AES-128, RFC3826 */ > }; > > -#define PRIV_DEFAULT PRIV_DES/* Default cipher */ > +#define PRIV_DEFAULT PRIV_AES/* Default cipher */ > > struct usmuser { > char*uu_name; > Index: usr.bin/snmp/snmp.1 > === > RCS file: /cvs/src/usr.bin/snmp/snmp.1,v > retrieving revision 1.17 > diff -u -p -r1.17 snmp.1 > --- usr.bin/snmp/snmp.1 23 Mar 2021 22:07:36 - 1.17 > +++ usr.bin/snmp/snmp.1 20 Jun 2021 10:37:51 - > @@ -197,7 +197,7 @@ Options are > or > .Cm SHA-512 . > This option defaults to > -.Cm MD5 . > +.Cm SHA-256 . > This option is only used by > .Fl v Cm 3 . > .It Fl C Ar appopt > @@ -439,6 +439,8 @@ protocol. > Options are > .Cm DES > and > +.Cm AES . > +This option defaults to > .Cm AES . > This option is only used by > .Fl v Cm 3 . > Index: usr.bin/snmp/snmpc.c > === > RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v > retrieving revision 1.33 > diff -u -p -r1.33 snmpc.c > --- usr.bin/snmp/snmpc.c 23 Mar 2021 22:07:36 - 1.33 > +++ usr.bin/snmp/snmpc.c 20 Jun 2021 10:37:51 - > @@ -476,7 +476,7 @@ main(int argc, char *argv[]) > err(1, "usm_init"); > if (seclevel & SNMP_MSGFLAG_AUTH) { > if (md == NULL) > - md = EVP_md5(); > + md = EVP_sha256(); > if (authkey == NULL) > errx(1, "No authKey or authPassword specified"); > if (usm_setauth(sec, md, authkey, authkeylen, > @@ -485,7 +485,7 @@ main(int argc, char *argv[]) > } > if (seclevel & SNMP_MSGFLAG_PRIV) { > if (cipher == NULL) > - cipher = EVP_des_cbc(); > + cipher = EVP_aes_128_cfb128(); > if (privkey == NULL) > errx(1, "No privKey or privPassword specified"); > if (usm_setpriv(sec, cipher, privkey, privkeylen, > >
  Re: Fix unsafe snmpd defaults
  On 2021/06/20 12:12, Martijn van Duren wrote: > I didn't change the example, since the example below shows how to set > up snmpv3 and this example's accompanying text is already on the long > side. I did change the text a little to "for SNMPv2c messages only", > so that it's clearer that this does disable snmpv3. > > OK? one tweak to the manual: > -.It Ic read-write Pq Ic community Ar string Ic | disabled > +.It Ic read-write Ic community Ar string > Specify the name of the read-write community, or disallow writes completely. > -The default value is > -.Ar private . > +There is no default value. Specify the name of the read-write community. There is no default value, so writes are disabled by default. Otherwise OK sthen@.
  Re: Fix unsafe snmpd defaults
  > > > -. > > I agree that it's safer, but do we want to break the config of more > people than needed for the goal of preventing simple amplification > attacks? Can we take a straw poll of readers of this email who are using SNMPv3 (if any ;-) -- are you using auth+enc, just auth, or no authentication? I'm thinking that somebody who went to the trouble of using v3 probably uses auth+enc though I could be..) > > and i'll try to have another read through and actually test it > > in the morning :) > > > Hopefully you haven't spend too much on a second read. didn't get there yet, i have spent the best part of 8 hours on 2 emails so far today ;) > | READWRITE DISABLED { > - conf->sc_readonly = 1; > + /* XXX Remove after 7.0 */ > + conf->sc_rwcommunity[0] = '\0'; > + log_warnx("'read-write disabled' is deprecated"); if it's going, might as well just disable it? almost nobody will react to that warning unless it refuses to start, it's not like this will lock someone out of their machine if it doesn't run. > +.It Ic write > +Specifies if the listen address accepts set requests. > +.It Ic notify > +Specifies if the listen address accepts trapv1 and trapv2 requests. > +.It Ic snmpv1 > +Enables SNMPv1 subsystem on the listen address. > +.It Ic snmpv2c > +Enables SNMPv2c subsystem on the listen address. > +.It Ic snmpv3 > +Enables SNMPv3 subsystem on the listen address. I like this! I guess we could also do listen on 127.0.0.1 snmpv2c read listen on 0.0.0.0 read listen on :: read read-only community public to allow localhost requests with v2c for quick lookups and require something better on the network. I'll do some testing and get back to you.
  Re: Fix unsafe snmpd defaults
  On 2021/06/14 19:40, Martijn van Duren wrote: > On Mon, 2021-06-14 at 12:55 +0100, Stuart Henderson wrote: > >. > > I fully agree. > > > >. > > > I think that your approach is a nice first stab, but is incomplete. thanks for looking. > -. > - Make sure that no users can be created with lower privs then seclevel, > so that people don't have to start debugging this issue when already > running in production with loglevels that are always too low. nice. > - If we disable SNMPv{1,2c} by default I reckon it's dumb to overload > seclevel with said protocols. I decoupled them (this addresses your > last statement) > - Add a disallow for empty community strings. This effectively > disables SNMPv{1,2c} in all cases if we set an empty string. agreed. > - Log the disabling of SNMPv{1,2c} properly and increment > snmp_inbadversions. this feels like it's overloading snmp_inbadversions a bit, previously this refers to things which are actually invalid and since ro and rw can be disabled independently it's hard to give an accurate log message. > - Setting an empty string is equal to disallow, so make > "read-write community" equal to an empty string and remove the now > useless sc_readonly. > - When sc_trcommunity is disabled we don't have the backup for > "trap receiver". Check for this explicitly during startup. makes sense. > At some point I want to rework the MPS subsystem (which snmpe.c > basically mostly is). But I think this diff is a nice stopgap until > I get around to it. > > Only lightly tested through regress and written quickly in between > jobs, so OKs welcome, but some modifications before commit can't > be ruled out. :-) > > martijn@ from a first read through: > Index: parse.y > === > RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v > retrieving revision 1.63 > diff -u -p -r1.63 parse.y > --- parse.y 22 Jan 2021 06:33:26 - 1.63 > +++ parse.y 14 Jun 2021 17:39:47 - > @@ -217,7 +217,7 @@ main : LISTEN ON listenproto > free($3); > } > | READWRITE DISABLED { > - conf->sc_readonly = 1; > + conf->sc_rwcommunity[0] = '\0'; > } > | TRAP COMMUNITY STRING { > if (strlcpy(conf->sc_trcommunity, $3, > @@ -1102,7 +1102,10 @@ parse_config(const char *filename, u_int > struct sockaddr_storage ss; > struct sym *sym, *next; > struct address *h; > - int found; > + struct trap_address *tr; > + const struct usmuser*up; > + const char *errstr; > + int found; > > if ((conf = calloc(1, sizeof(*conf))) == NULL) { > log_warn("%s", __func__); > @@ -1112,10 +1115,8 @@ parse_config(const char *filename, u_int > conf->sc_flags = flags; > conf->s
  Fix unsafe snmpd defaults. Index: usr.sbin/snmpd/parse.y === RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v retrieving revision 1.63 diff -u -p -r1.63 parse.y --- usr.sbin/snmpd/parse.y 22 Jan 2021 06:33:26 - 1.63 +++ usr.sbin/snmpd/parse.y 14 Jun 2021 11:49:33 - @@ -266,6 +266,9 @@ main: LISTEN ON listenproto free($2); YYERROR; } + if (conf->sc_min_seclevel == -1) + conf->sc_min_seclevel = + (SNMP_MSGFLAG_AUTH | SNMP_MSGFLAG_PRIV); } userspecs { const char *errstr; if (usm_checkuser(user, ) < 0) { @@ -1112,10 +1115,8 @@ parse_config(const char *filename, u_int conf->sc_flags = flags; conf->sc_confpath = filename; TAILQ_INIT(>sc_addresses); - strlcpy(conf->sc_rdcommunity, "public", SNMPD_MAXCOMMUNITYLEN); - strlcpy(conf->sc_rwcommunity, "private", SNMPD_MAXCOMMUNITYLEN); - strlcpy(conf->sc_trcommunity, "public", SNMPD_MAXCOMMUNITYLEN); TAILQ_INIT(>sc_trapreceivers); + conf->sc_min_seclevel = -1; if ((file = pushfile(filename, 0)) == NULL) { free(conf); @@ -1155,6 +1156,9 @@ parse_config(const char *filename, u_int log_warnx("notify listener needs at least one trap handler"); free(conf); return (NULL); + } + if (conf->sc_min_seclevel == -1) { + conf->sc_min_seclevel = 0; } /* Free macros and check which have not been used. */ Index: usr.sbin/snmpd/snmpd.conf.5 === RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v retrieving revision 1.47 diff -u -p -r1.47 snmpd.conf.5 --- usr.sbin/snmpd/snmpd.conf.5 9 Mar 2021 18:18:55 - 1.47 +++ usr.sbin/snmpd/snmpd.conf.5 14 Jun 2021 11:49:33 - @@ -136,12 +136,10 @@ set requires at least one statement. .It Ic read-only community Ar string Specify the name of the read-only community. -The default value is -.Ar public . +There is no default value. .It Ic read-write Pq Ic community Ar string Ic | disabled Specify the name of the read-write community, or disallow writes completely. -The default value is -.Ar private . +There is no default value. .It Ic seclevel Pq Ic none | auth | enc Specify the lowest security level that .Xr snmpd 8 @@ -149,7 +147,7 @@ accepts: .Bl -tag -width "auth" -offset ident .It Ic none Both authentication and encryption of messages is optional. -This is the default value. +This is the default value if an SNMPv3 user is not configured. .It Ic auth Authentication of messages is mandatory. .Xr snmpd 8 @@ -158,6 +156,7 @@ Encryption of messages is optional. .It Ic enc Messages must be encrypted and must have a valid digest for authentication. Otherwise they will be discarded. +This is the default value if an SNMPv3 user is configured. .El .Pp If the chosen value is different from @@ -206,8 +205,7 @@ description in the SNMP MIB for details. .\"XXX describe the complicated services alg here .It Ic trap community Ar string Specify the name of the trap community. -The default value is -.Ar public . +There is no default value. .It Ic trap handle Ar oid Qq Ar command Execute .Ic command @@ -330,6 +328,7 @@ to listen on localhost, override the def magic services value and provides some custom OID values: .Bd -literal -offset indent listen on 127.0.0.1 +read community public system oid 1.3.6.1.4.1.30155.23.2 system services 74 Index: regress/usr.sbin/snmpd/snmpd.sh === RCS file:
  Re: cert.pem sync
  On 2021/06/10 13:05, Theo Buehler wrote: > On Thu, Jun 10, 2021 at 11:39:46AM +0100, Stuart Henderson wrote: > > I was just reminded of the Apple cert problem with GeoTrust Global CA > > and checked and they're using better intermediates for api.push.apple.com > > now. OK to sync up with Mozilla's CA bundle again, including removal > > of GeoTrust Global CA? > > Thanks! > > > Changes in the list first; diff below: > > > > -AC Camerfirma S.A. > > Ah, good. > > > > > I could not find any information on this removal and it's still in my > firefox. Why is that removed in your diff? > Ah, there's a handy summary ticket: Validity in NSS was changed from web+email to just email: Obviously the cert.pem format doesn't allow expressing different trust purposes or levels as is done in NSS, the script I'm using to convert (curl's "mk-ca-bundle") defaults to only include certificates listed for "SERVER_AUTH", hence the removal. (You can see it reflected in firefox if you "edit purposes"). The script accepts a parameter to allow different trusts so if we wanted to include certificates only trusted for email, we could do that; doing that would however reenable the O=AC Camerfirma S.A. roots unless we manually tweak it. The relevant data is in the "Trust for Certificate XXX" in certdata.txt and looks like this: CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_MUST_VERIFY_TRUST CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_TRUSTED_DELEGATOR CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST "CKT_NSS_MUST_VERIFY_TRUST" is "don't trust as a CA" and "CKT_NSS_TRUSTED_DELEGATOR" is "do trust as a CA" i
  cert.pem sync
  I was just reminded of the Apple cert problem with GeoTrust Global CA and checked and they're using better intermediates for api.push.apple.com now. OK to sync up with Mozilla's CA bundle again, including removal of GeoTrust Global CA? Changes in the list first; diff below: -AC Camerfirma S.A. - /C=EU/L=Madrid (see current address at)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Chambers of Commerce Root - 2008 - /C=EU/L=Madrid (see current address at)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Global Chambersign Root - 2008 - FNMT-RCM /C=ES/O=FNMT-RCM/OU=AC RAIZ FNMT-RCM + /C=ES/O=FNMT-RCM/OU=Ceres/2.5.4.97=VATES-Q2826004J/CN=AC RAIZ FNMT-RCM SERVIDORES SEGUROS -GeoTrust Inc. - /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA - /C=US/O=GeoTrust Inc./OU=(c) 2007 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G2 - GlobalSign nv-sa + /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Root E46 + /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Root R46 /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA Unizeto Technologies S.A. /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA + /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA 2 - -VeriSign, Inc. - /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2008 VeriSign, Inc. - For authorized use only/CN=VeriSign Universal Root Certification Authority Index: cert.pem === RCS file: /cvs/src/lib/libcrypto/cert.pem,v retrieving revision 1.22 diff -u -p -r1.22 cert.pem --- cert.pem12 Feb 2021 12:16:53 - 1.22 +++ cert.pem10 Jun 2021 10:38:59 - @@ -62,150 +62,6 @@ Q0CgFzzr6juwcqajuUpLXhZI9LK8yIySxZ2frHI2 jLMi6Et8Vcad+qMUu2WFbm5PEn4KPJ2V -END CERTIFICATE- -### AC Camerfirma S.A. - -=== /C=EU/L=Madrid (see current address at)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Chambers of Commerce Root - 2008 -Certificate: -Data: -Version: 3 (0x2) -Serial Number: -a3:da:42:7e:a4:b1:ae:da -Signature Algorithm: sha1WithRSAEncryption -Validity -Not Before: Aug 1 12:29:50 2008 GMT -Not After : Jul 31 12:29:50 2038 GMT -Subject: C=EU, L=Madrid (see current address at)/serialNumber=A82743287, O=AC Camerfirma S.A., CN=Chambers of Commerce Root - 2008 -X509v3 extensions: -X509v3 Basic Constraints: critical -CA:TRUE, pathlen:12 -X509v3 Subject Key Identifier: -F9:24:AC:0F:B2:B5:F8:79:C0:FA:60:88:1B:C4:D9:4D:02:9E:17:19 -X509v3 Authority Key Identifier: - keyid:F9:24:AC:0F:B2:B5:F8:79:C0:FA:60:88:1B:C4:D9:4D:02:9E:17:19 -DirName:/C=EU/L=Madrid (see current address at)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Chambers of Commerce Root - 2008 -serial:A3:DA:42:7E:A4:B1:AE:DA - -X509v3 Key Usage: critical -Certificate Sign, CRL Sign -X509v3 Certificate Policies: -Policy: X509v3 Any Policy - CPS: - -SHA1 Fingerprint=78:6A:74:AC:76:AB:14:7F:9C:6A:30:50:BA:9E:A8:7E:FE:9A:CE:3C -SHA256 Fingerprint=06:3E:4A:FA:C4:91:DF:D3:32:F3:08:9B:85:42:E9:46:17:D8:93:D7:FE:94:4E:10:A7:93:7E:E2:9D:96:93:C0 --BEGIN CERTIFICATE- -MIIHTzCCBTegAwIBAgIJAKPaQn6ksa7aMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYD -VQQGEwJFVTFDMEEGA1UEBxM6TWFkcmlkIChzZWUgY3VycmVudCBhZGRyZXNzIGF0 -IHd3dy5jYW1lcmZpcm1hLmNvbS9hZGRyZXNzKTESMBAGA1UEBRMJQTgyNzQzMjg3 -MRswGQYDVQQKExJBQyBDYW1lcmZpcm1hIFMuQS4xKTAnBgNVBAMTIENoYW1iZXJz -IG9mIENvbW1lcmNlIFJvb3QgLSAyMDA4MB4XDTA4MDgwMTEyMjk1MFoXDTM4MDcz -MTEyMjk1MFowga4xCzAJBgNVBAYTAkVVMUMwQQYDVQQHEzpNYWRyaWQgKHNlZSBj -dXJyZW50IGFkZHJlc3MgYXQgd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3MpMRIw -EAYDVQQFEwlBODI3NDMyODcxGzAZBgNVBAoTEkFDIENhbWVyZmlybWEgUy5BLjEp -MCcGA1UEAxMgQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdCAtIDIwMDgwggIiMA0G -CSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCvAMtwNyuAWko6bHiUfaN/Gh/2NdW9 -28sNRHI+JrKQUrpjOyhYb6WzbZSm891kDFX29ufyIiKAXuFixrYp4YFs8r/lfTJq -VKAyGVn+H4vXPWCGhSRv4xGzdz4gljUha7MI2XAuZPeEklPWDrCQiorjh40G072Q -DuKZoRuGDtqaCrsLYVAGUvGef3bsyw/QHg3PmTA9HMRFEFis1tPo1+XqxQEHd9ZR -5gN/ikilTWh1uem8nk4ZcfUyS5xtYBkL+8ydddy/Js2Pk3g5eXNeJQ7KXOt3EgfL -ZEFHcpOrUMPrCXZkNNI5t3YRCQ12RcSprj1qr7V9ZS+UWBDsXHyvfuK2GNnQm05a -Sd+pZgvMPMZ4fKecHePOjlO+Bd5gD2vlGts/4+EhySnB8esHnFIbAURRPHsl18Tl -UlRdJQfKFiC4reRB7noI/plvg6aRArBsNlVq5331lubKgdaX8ZSD6e2wsWsSaR6s -+12pxZjptFtYer49okQ6Y1nUCyXeG0+95QGezdIp1Z8XGQpvvwyQ0wlf2eOKNcx5
  ospfd seq out of order in ls_upd floods
  Sometimes I see authentication errors from ospfd, mainly (though possibly not entirely always) on a 30 minute cycle, e.g. these log entries 2021-06-03T05:30:04.952Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T05:51:43.785Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T05:51:43.785Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T05:56:03.248Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T05:56:03.248Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T05:59:58.978Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T08:21:43.851Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T08:21:43.851Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T08:26:03.434Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T08:26:03.434Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T08:29:59.087Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T08:30:04.097Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T08:51:43.858Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T08:51:43.858Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T08:56:03.470Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T08:56:03.470Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T09:00:01.033Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T09:00:06.043Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T09:21:43.876Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T09:21:43.876Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T09:26:03.518Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T09:26:03.518Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T09:30:00.060Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T09:30:05.070Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T09:51:43.893Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T09:51:43.893Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T09:56:03.555Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T09:56:03.555Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T09:59:59.086Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T11:00:05.088Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated 2021-06-03T11:21:43.932Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T11:21:43.932Z ospfd[76044]: recv_packet: authentication error, interface vlan760 2021-06-03T11:26:03.675Z ospfd[76044]: auth_validate: decreasing seq num, interface vlan760 2021-06-03T11:26:03.675Z ospfd[76044]: recv_packet: authentication error, interface vlan760 The cyclical nature suggests it's in the ls_upd floods and looking at packets confirms that, note the ls_upd where 8715337 and 8715336 are sent out of order: 11:26:02.246716 xxx.xx.xxx.28 > 224.0.0.5: OSPFv2-hello 52: rtrid yyy.yy.yyy.13 backbone auth MD5 key-id 1 seq 8715334 38681, len 88) 11:26:03.249345 xxx.xx.xxx.28 > 224.0.0.5: OSPFv2-hello 52: rtrid yyy.yy.yyy.13 backbone auth MD5 key-id 1 seq 8715335 38060, len 88) 11:26:03.584768 xxx.xx.xxx.28 > 224.0.0.5: OSPFv2-ls_upd 628: rtrid yyy.yy.yyy.13 backbone auth MD5 key-id 1 seq 8715337 off 0 len 16 { S 864D age 9 ase 10.2.62.0 asbr yyy.yy.yyy.9 mask 255.255.255.0 type 1 tos 0 metric 100 } { S 864D age 9 ase 10.2.66.0 asbr yyy.yy.yyy.9 mask 255.255.255.0 type 1 tos 0 metric 100 } { E S 80013EB3 age 9 rtr yyy.yy.yyy.9 E { net 185.91.102.64 mask 255.255.255.248 tos 0 metric 10 } { net 10.88.15.0 mask 255.255.255.224 tos 0 metric 10 } { net xxx.xx.xxx.64 mask 255.255.255.255 tos 0 metric 10 } { net yyy.yy.yyy.72 mask 255.255.255.248 tos 0 metric 10 } { net zzz.zzz.44.0 mask 255.255.255.192 tos 0 metric 10 } { net zzz.zzz.43.96 mask 255.255.255.240 tos 0 metric 10 } { net zzz.zzz.43.64 mask 255.255.255.224 tos 0 metric 10 } { net zzz.zzz.43.128 mask 255.255.255.240 tos 0 metric 10 } { net zzz.zzz.43.32 mask 255.255.255.224 tos 0 metric 10 } { net zzz.zzz.41.176 mask 255.255.255.248 tos 0 metric 10 } { net zzz.zzz.41.160 mask 255.255.255.240 tos 0 metric 10 } { net zzz.zzz.41.144 mask 255.255.255.240 tos 0 metric 10 } { net zzz.zzz.41.32 mask 255.255.255.224 tos 0
  Re: Pull Request
  OpenBSD does not use pull requests. Please send your diff, with explanation, in an email to this mailing list. -- Sent from a phone, apologies for poor formatting. On 31 May 2021 11:56:27 Reuven Plevinsky wrote:
  Re: [PATCH] [src] sys/dev/usb/usbdevs - add "SHARKOON Technologies GmbH" vendor ID
  On 2021/05/24 16:27, Raf Czlonka wrote: > On Mon, May 24, 2021 at 04:10:00PM BST, Theo de Raadt wrote: > > But does it matter? > > Did this[0] matter? > [0] > Yes, that one is used in a driver.
  Re: bcmintc(4) diff for raspberry pi3
  On 2021/05/22 12:06, Mark Kettenis wrote: > Can't find my raspberry pi3 right now. But here is a diff that avoids > spinning with interrupts disabled while trying to grab the kernel lock > for it. I'd appreciate it if somebody could give this a spin for me. > Just checking whether it works normally for a bit would be fine. Seems OK so far. booting sd0a:/bsd: 8935756+1804632+570032+831592 [648870+109+1086336+636102]=0xf99638 type 0x0 pa 0x0 va 0x0 pages 0x1 attr 0x8 type 0x7 pa 0x1000 va 0x1000 pages 0x1ff attr 0x8 type 0x2 pa 0x20 va 0x20 pages 0x4000 attr 0x8 type 0x7 pa 0x420 va 0x420 pages 0x3cf5 attr 0x8 type 0x9 pa 0x7ef5000 va 0x7ef5000 pages 0x16 attr 0x8 type 0x7 pa 0x7f0b000 va 0x7f0b000 pages 0x3119d attr 0x8 type 0x2 pa 0x390a8000 va 0x390a8000 pages 0xd5b attr 0x8 type 0x4 pa 0x39e03000 va 0x39e03000 pages 0x1 attr 0x8 type 0x2 pa 0x39e04000 va 0x39e04000 pages 0x3 attr 0x8 type 0x7 pa 0x39e07000 va 0x39e07000 pages 0x1 attr 0x8 type 0x2 pa 0x39e08000 va 0x39e08000 pages 0x100 attr 0x8 type 0x1 pa 0x39f08000 va 0x39f08000 pages 0x2a attr 0x8 type 0x0 pa 0x39f32000 va 0x39f32000 pages 0x7 attr 0x8 type 0x4 pa 0x39f39000 va 0x39f39000 pages 0x1 attr 0x8 type 0x6 pa 0x39f3a000 va 0x5144e2a000 pages 0x1 attr 0x8008 type 0x4 pa 0x39f3b000 va 0x39f3b000 pages 0x2 attr 0x8 type 0x0 pa 0x39f3d000 va 0x39f3d000 pages 0x1 attr 0x8 type 0x6 pa 0x39f3e000 va 0x5144e2e000 pages 0x3 attr 0x8008 type 0x4 pa 0x39f41000 va 0x39f41000 pages 0x1 attr 0x8 type 0x6 pa 0x39f42000 va 0x5144e32000 pages 0x4 attr 0x8008 type 0x0 pa 0x39f46000 va 0x39f46000 pages 0x1 attr 0x8 type 0x4 pa 0x39f47000 va 0x39f47000 pages 0x1 attr 0x8 type 0x0 pa 0x39f48000 va 0x39f48000 pages 0x1 attr 0x8 type 0x4 pa 0x39f49000 va 0x39f49000 pages 0x2 attr 0x8 type 0x0 pa 0x39f4b000 va 0x39f4b000 pages 0x1 attr 0x8 type 0x4 pa 0x39f4c000 va 0x39f4c000 pages 0x2 attr 0x8 type 0x2 pa 0x39f4e000 va 0x39f4e000 pages 0x1402 attr 0x8 type 0x5 pa 0x3b35 va 0x514624 pages 0x10 attr 0x8008 type 0x2 pa 0x3b36 va 0x3b36 pages 0xa0 attr 0x8 type 0xb pa 0x3f10 va 0x514625 pages 0x1 attr 0x8000 [ using 2372384 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2021 OpenBSD. All rights reserved. OpenBSD 6.9-current (GENERIC.MP) #3: Sat May 22 14:49:21 BST 2021 st...@mala.spacehopper.org:/sys/arch/arm64/compile/GENERIC.MP real mem = 956895232 (912MB) avail mem = 895025152 (853MB) random: good seed from bootblocks mainbus0 at root: Raspberry Pi 3 Model B Rev 1 cpu0: CRC32,ASID161: CRC32,ASID162: CRC32,ASID16 cpu3: CRC32,ASID16 efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20210400 apm0 at mainbus0 simplefb0 at mainbus0: 656x416, 32bpp wsdisplay0 at simplefb0 mux 1 wsdisplay0: screen 0-5 added (std, vt100 emulation) "system" at mainbus0 not configured "axi" at mainbus0 not configured simplebus0 at mainbus0: "soc" bcmclock0 at simplebus0 bcmmbox0 at simplebus0 bcmgpio0 at simplebus0 bcmaux0 at simplebus0 bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10 bcmintc0 at simplebus0 pluart0 at simplebus0: console bcmsdhost0 at simplebus0: 250 MHz base clock sdmmc0 at bcmsdhost0: 4-bit, sd high-speed, mmc high-speed, dma dwctwo0 at simplebus0 bcmdog0 at simplebus0 bcmrng0 at simplebus0 bcmtemp0 at simplebus0 "local_intc" at simplebus0 not configured sdhc0 at simplebus0 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc1 at sdhc0: 4-bit, sd high-speed, mmc high-speed "firmware" at simplebus0 not configured "power" at simplebus0 not configured "mailbox" at simplebus0 not configured "gpiomem" at simplebus0 not configured "fb" at simplebus0 not configured "vcsm" at simplebus0 not configured "virtgpio" at simplebus0 not configured "clocks" at mainbus0 not configured "phy" at mainbus0 not configured "arm-pmu" at mainbus0 not configured agtimer0 at mainbus0: 19200 kHz "leds" at mainbus0 not configured "fixedregulator_3v3" at mainbus0 not configured "fixedregulator_5v0" at mainbus0 not configured "bootloader" at mainbus0 not configured dt: 443 probes usb0 at dwctwo0: USB revision 2.0 sdmmc0: can't enable card uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev 2.00/1.00
  Re: [patch] tcpdump: Sync DNS types with IANA
  On 2021/05/20 08:36, Theo Buehler wrote: > On Thu, May 20, 2021 at 07:05:24AM +0100, Stuart Henderson wrote: > > When I have time (I'm hopeful for next week but not sure yet) I'll > > see how this goes with a ports bulk build. > > This diff changes usr.sbin/tcpdump/nameser.h rather than > I don't think this affects any ports. Oops, sorry Matthew, I read this too quickly and missed that it was for tcpdump. > Surely the T_XXX -> ns_t_xxx change and similar would be needed in > /usr/src/include/arpa/nameser.h? Yes that's what I was thinking this was touching.. > The two headers have diverged a bit and there may be a case for keeping > them in sync (I don't know), but changing only tcpdump's copy doesn't > make sense to me, especially as "upstream" still uses T_XXX. > > I don't know why tcpdump uses both its own copy and . >
  Re: [patch] tcpdump: Sync DNS types with IANA
  When I have time (I'm hopeful for next week but not sure yet) I'll see how this goes with a ports bulk build. On 2021/05/19 22:44, Matthew Martin wrote: > On Wed, May 19, 2021 at 08:01:00AM +0100, Stuart Henderson wrote: > > For the love of $deity if we're updating this file can we please change > > these T_XXX to the ns_t_xxx used by everything else so we don't have to > > patch everything in ports using them? > > In that case judging from a quick look at the patches in the ports tree > the C_ constants should get renamed to ns_c_ as well. The below patch > works for tcpdump, but I presume broader testing will now be needed. > > > diff --git nameser.h nameser.h > index ddb5e065c4a..f766989ab92 100644 > --- nameser.h > +++ nameser.h > @@ -109,84 +109,113 @@ > /* > * Type values for resources and queries > */ > -#define T_A 1 /* host address */ > -#define T_NS 2 /* authoritative server */ > -#define T_MD 3 /* mail destination */ > -#define T_MF 4 /* mail forwarder */ > -#define T_CNAME 5 /* connonical name */ > -#define T_SOA6 /* start of authority zone */ > -#define T_MB 7 /* mailbox domain name */ > -#define T_MG 8 /* mail group member */ > -#define T_MR 9 /* mail rename name */ > -#define T_NULL 10 /* null resource record */ > -#define T_WKS11 /* well known service */ > -#define T_PTR12 /* domain name pointer */ > -#define T_HINFO 13 /* host information */ > -#define T_MINFO 14 /* mailbox information */ > -#define T_MX 15 /* mail routing information */ > -#define T_TXT16 /* text strings */ > -#define T_RP17 /* responsible person */ > -#define T_AFSDB 18 /* AFS cell database */ > -#define T_X2519 /* X_25 calling address */ > -#define T_ISDN 20 /* ISDN calling address */ > -#define T_RT 21 /* router */ > -#define T_NSAP 22 /* NSAP address */ > -#define T_NSAP_PTR 23 /* reverse lookup for NSAP */ > -#define T_SIG24 /* security signature */ > -#define T_KEY25 /* security key */ > -#define T_PX 26 /* X.400 mail mapping */ > -#define T_GPOS 27 /* geographical position > (withdrawn) */ > -#define T_ 28 /* IP6 Address */ > -#define T_LOC29 /* Location Information */ > -#define T_NXT30 /* Next Valid Name in Zone */ > -#define T_EID31 /* Endpoint identifier */ > -#define T_NIMLOC 32 /* Nimrod locator */ > -#define T_SRV33 /* Server selection */ > -#define T_ATMA 34 /* ATM Address */ > -#define T_NAPTR 35 /* Naming Authority PoinTeR */ > -#define T_KX 36 /* Key Exchanger */ > -#define T_CERT 37 /* certificate */ > -#define T_A6 38 /* IP6 address */ > -#define T_DNAME 39 /* non-terminal redirection */ > -#define T_SINK 40 /* SINK */ > -#define T_OPT41 /* EDNS0 option (meta-RR) */ > -#define T_APL42 /* APL */ > -#define T_DS 43 /* Delegation Signer */ > -#define T_SSHFP 44 /* SSH Key Fingerprint */ > -#define T_IPSECKEY 45 /* IPsec keying material */ > -#define T_RRSIG 46 /* RRSIG */ > -#define T_NSEC 47 /* NSEC */ > -#define T_DNSKEY 48 /* DNSKEY */ > +#define ns_t_a 1 /* host address */ > +#define ns_t_ns 2 /* authoritative server */ > +#define ns_t_md 3 /* mail destination */ > +#define ns_t_mf 4 /* mail forwarder */ > +#define ns_t_cname 5 /* connonical name */ > +#define ns_t_soa 6 /* start of authority zone */ > +#define ns_t_mb 7 /* mailbox domain name */ > +#define ns_t_mg 8 /* mail group member */ > +#define ns_t_mr 9 /* mail rename name */ > +#d
  Re: Very little patch : ref getrtable in rdomain
  System calls are not a stable interface in OpenBSD. And aren't they now blocked except from libc or am I mistaken? The way to do this from Perl is to write an extension in C. You can probably crib from src/gnu/usr.bin/perl/cpan/OpenBSD-Pledge. -- Sent from a phone, apologies for poor formatting. On 19 May 2021 16:16:02 "Sven F." wrote: On Wed, May 19, 2021 at 10:55 AM Sven F. wrote: Index: rdomain.4 === RCS file: /cvs/src/share/man/man4/rdomain.4,v retrieving revision 1.17 diff -u -p -r1.17 rdomain.4 --- rdomain.4 24 Sep 2020 11:05:32 - 1.17 +++ rdomain.4 19 May 2021 14:51:37 - @@ -139,7 +139,8 @@ Delete rdomain 4 again: .Xr route 4 , .Xr pf.conf 5 , .Xr ifconfig 8 , -.Xr route 8 +.Xr route 8, +.Xr getrtable 2 .Sh HISTORY .Ox support for PS: Is it possible to setrtable in perl script ? syscall(310, XX);
  Re: [patch] tcpdump: Sync DNS types with IANA
  For the love of $deity if we're updating this file can we please change these T_XXX to the ns_t_xxx used by everything else so we don't have to patch everything in ports using them? -- Sent from a phone, apologies for poor formatting. On 19 May 2021 04:24:40 Matthew Martin wrote: Sync the DNS types with IANA[1] and upstream[2]. With this the Type65 queries show up as HTTPS. Removed the UNSPECA type parsing as IANA has that query type number assigned to NID now. Also added a const on ns_class2str. 1: 2: diff --git nameser.h nameser.h index ddb5e065c4a..616e0028cff 100644 --- nameser.h +++ nameser.h @@ -145,25 +145,47 @@ #define T_ATMA 34 /* ATM Address */ #define T_NAPTR 35 /* Naming Authority PoinTeR */ #define T_KX36 /* Key Exchanger */ -#define T_CERT 37 /* certificate */ +#define T_CERT 37 /* Certificates in the DNS */ #define T_A638 /* IP6 address */ #define T_DNAME 39 /* non-terminal redirection */ -#define T_SINK 40 /* SINK */ +#define T_SINK 40 /* unknown */ #define T_OPT 41 /* EDNS0 option (meta-RR) */ -#define T_APL 42 /* APL */ +#define T_APL 42 /* lists of address prefixes */ #define T_DS43 /* Delegation Signer */ -#define T_SSHFP44 /* SSH Key Fingerprint */ +#define T_SSHFP44 /* SSH Fingerprint */ #define T_IPSECKEY 45 /* IPsec keying material */ -#define T_RRSIG46 /* RRSIG */ -#define T_NSEC 47 /* NSEC */ -#define T_DNSKEY 48 /* DNSKEY */ +#define T_RRSIG46 /* new security signature */ +#define T_NSEC 47 /* provable insecure information */ +#define T_DNSKEY 48 /* new security key */ +#define T_DHCID49 /* DHCP IDentifier */ +#define T_NSEC350 /* Next SECure record v3 */ +#define T_NSEC3PARAM 51 /* NSEC3 PARAMeter */ +#define T_TLSA 52 /* TLS Authentication */ +#define T_SMIMEA 53 /* S/MIME Authentication */ +/* Unassigned */ +#define T_HIP 55 /* Host Identity Protocol */ +#define T_NINFO56 /* zone status information */ +#define T_RKEY 57 /* Record encryption KEY */ +#define T_TALINK 58 /* Trust Anchor LINK */ +#define T_CDS 59 /* Child Delegation Signer */ +#define T_CDNSKEY 60 /* Child DNSKEY */ +#define T_OPENPGPKEY 61 /* OpenPGP KEY */ +#define T_CSYNC62 /* Child to parent SYNCronization */ +#define T_ZONEMD 63 /* ZONE data Message Digest */ +#define T_SVCB 64 /* SerViCe Binding */ +#define T_HTTPS65 /* HTTPS binding */ /* non standard */ #define T_SPF 99 /* sender policy framework */ #define T_UINFO 100 /* user (finger) information */ #define T_UID 101 /* user ID */ #define T_GID 102 /* group ID */ #define T_UNSPEC103 /* Unspecified format (binary data) */ -#define T_UNSPECA 104 /* "unspecified ascii". Ugly MIT hack */ +#define T_NID 104 /* Node IDentifier */ +#define T_L32 105 /* Locator 32-bit */ +#define T_L64 106 /* Locator 64-bit */ +#define T_LP 107 /* Locator Pointer */ +#define T_EUI48108 /* an EUI-48 address */ +#define T_EUI64109 /* an EUI-64 address */ /* Query type values which do not appear in resource records */ #define T_TKEY 249 /* Transaction Key [RFC2930] */ #define T_TSIG 250 /* Transaction Signature [RFC2845] */ @@ -172,6 +194,13 @@ #define T_MAILB 253 /* transfer mailbox records */ #define T_MAILA 254 /* transfer mail agent records */ #define T_ANY 255 /* wildcard match */ +#define T_URI 256 /* uri records [RFC7553] */ +#define T_CAA 257 /* Certification Authority Authorization */ +#define T_AVC 258 /* Application Visibility and Control */ +#define T_DOA 259 /* Digital Object Architecture */ +#define T_AMTRELAY 260 /* Automatic Multicast Tunneling RELAY */ +#define T_TA 32768 /* DNSSEC Trust
  Re: iked(8): support for intermediate CAs and multiple CERT payloads
  On 2021/05/14 21:14, Tobias Heider wrote: > On Thu, May 13, 2021 at 02:39:37PM +0900, > > Hi Katsuhiro, > > thank you for the diff! > As Stuart said this is a very welcome addition and the diff looks good to me. > > Unfortunately I don't have a Windows machine here to test with, so it would be > nice if anyone reading this could give it a try on their Windows setup. > > I will try running a few more tests with Strongswan clients and commit it > once I'm sure everything still works. > > - Tobias > Tested with Android strongswan. If I write the intermediate and root certificates to ca/ca.crt and the server certificate to certs/$HOSTNAME.crt then I'm able to connect. I haven't tested Windows yet, I'll try to locate a machine to test with at the weekend. The certificate arrangement is a little awkward to work with typical ACME infrastructure used with standard TLS servers: For a standard server the root certificate would not normally need to be present at all; only server and intermediate certs are needed (though possibly this may be different for IKEv2). As such, ACME clients don't normally fetch this certificate so it must be retrieved separately. Also typically for a TLS server, any intermediates would be stored alongside the server certificate (fullchain.pem in the usual acme-client config). Storing that in a separate file isn't difficult ("chain" rather than "full chain" for acme-client) but, combined with the above need to store the CA in that same file, it does mean some extra fiddling is required. So to use this diff as-is with acme-client, something like this is needed (I haven't tested the whole thing put together but I think it's right), domain key "/etc/iked/private/local.key" domain certificate "/etc/iked/certs/hostname.crt" domain chain certificate "/etc/iked/ca/chain.crt" ftp -o /etc/iked/ca/ca.p7c $(openssl x509 -in /etc/iked/ca/chain.crt -text -noout | grep 'CA Issuers' | cut -d: -f2-) (cat /etc/iked/ca/chain.crt; openssl pkcs7 -inform DER -in /etc/iked/ca/ca.p7c -print_certs) > /etc/iked/ca/ca.crt At least it's going to need some doc to show what goes where. But it would be much simpler to work with if it would at least accept "full chain" in the single certs/hostname.crt file.
  Re: iked(8): support for intermediate CAs and multiple CERT payloads
  I can't test at the moment, but as you asked for comments too: this is *very* welcome, it's an important missing feature. Thanks! -- Sent from a phone, apologies for poor formatting. On 13 May 2021 06:40:49
  Re: patch: add support for RTLD_NODELETE
  We are due a _SYSTEM_VERSION bump for the clang update, it can ride alongside that -- Sent from a phone, apologies for poor formatting. On 10 May 2021 08:01:18 Sebastien Marie wrote: Hi, The following diff adds support for RTLD_NODELETE in ld.so(1). It helps Qt programs which is using RTLD_NODELETE per default for loading plugins. Without this patch, qgis (for example) is crashing systematically on exit. With it, it is fine. If RTLD_NODELETE isn't POSIX, it is widely deployed: at least linux, freebsd, dragonfly, netbsd, solaris, illumos, apple, and fuchsia have it. I built a full release on i386 with it and built several packages (most of dependencies of gqis which is including qt5). One drawback will be for ports: a build with the diff might change built code as RTLD_NODELETE will be present in headers. So it might deserves a libc bump to correctly update installed ports. Comments or OK ? -- Sebastien Marie diff 393e7b397988bb6abe46729de1794883d2b9d5cf /home/semarie/repos/openbsd/src blob - 431065f3eab32299ad39766592e72a1765c8e8dc file + include/dlfcn.h --- include/dlfcn.h +++ include/dlfcn.h @@ -42,6 +42,7 @@ #define RTLD_GLOBAL 0x100 #define RTLD_LOCAL 0x000 #define RTLD_TRACE 0x200 +#define RTLD_NODELETE 0x400 /* * Special handle arguments for dlsym(). blob - b8d5512e32bf50351b432a539106b1695a51f10f file + libexec/ld.so/dlfcn.c --- libexec/ld.so/dlfcn.c +++ libexec/ld.so/dlfcn.c @@ -54,7 +54,7 @@ dlopen(const char *libname, int flags) int failed = 0; int obj_flags; - if (flags & ~(RTLD_TRACE|RTLD_LAZY|RTLD_NOW|RTLD_GLOBAL)) { + if (flags & ~(RTLD_TRACE|RTLD_LAZY|RTLD_NOW|RTLD_GLOBAL|RTLD_NODELETE)) { _dl_errno = DL_INVALID_MODE; return NULL; } @@ -89,6 +89,9 @@ dlopen(const char *libname, int flags) _dl_link_dlopen(object); + if (flags & RTLD_NODELETE) + object->obj_flags |= DF_1_NODELETE; + if (OBJECT_REF_CNT(object) > 1) { /* if opened but grpsym_vec has not been filled in */ if (object->grpsym_vec.len == 0) blob - afdf60ff428680eabc76f667442934511a8576fb file + share/man/man3/dlfcn.3 --- share/man/man3/dlfcn.3 +++ share/man/man3/dlfcn.3 @@ -124,6 +124,19 @@ each of the above values together. If an object was opened with RTLD_LOCAL and later opened with RTLD_GLOBAL, then it is promoted to RTLD_GLOBAL. .Pp +Additionally, the following flag may be ORed into the mode argument: +.Pp +.Bl -tag -width "RTLD_NODELETE" -compact -offset indent +.It Sy RTLD_NODELETE +Prevents unload of the loaded object on +.Fn dlclose . +The same behaviour may be requested by +.Fl z +.Cm nodelete +option of the static linker +.Xr ld 1 . +.El +.Pp The main executable's symbols are normally invisible to .Fn dlopen symbol resolution.
  Re: Time to commit FUSE changes
  On 2021/05/07 17:14, Helg wrote: > Hi tech@ > > Now that 6.9 has been released I'd like to commit my changes to replace > libfuse from base with the reference implementation from ports. > > Can I please have an OK? I'll commit the ports changes at the same time > (separate email already sent to ports@). If you would like more info > please let me know. I've submitted this before and there are already a > few of you that are aware and have been a great help to me. > > The main changes are to fuse_device.c and fusebuf.h where the protocol > is implemented. The other big change of course is to delete all of libfuse. I am OK with those though I have only tested things and not read over the src diff particularly thoroughly. It involves a base library moving to ports and machines with new kernels using FUSE-based software will need updated packages to work. I think this is not a problem to commit now as A) port build machines for the more common arch have moved past release and B) only a handful of ports link to this at all and even fewer of those *really* use it (there are a number of ports which are used for another purpose which also have FUSE support but that's not their main focus).
  Re: services(5): add default ftps ports
  On 2021/05/04 12:07, Jan Klemkow wrote: > Hi, > > Add missing ftps defaults ports to servies(5). > > OK? > > bye, > Jan > > Index: services > === > RCS file: /cvs/src/etc/services,v > retrieving revision 1.99 > diff -u -p -r1.99 services > --- services 18 Feb 2021 02:30:29 - 1.99 > +++ services 4 May 2021 10:01:35 - > @@ -318,6 +318,10 @@ krb_prop 754/tcp hprop # Kerberos slav > krbupdate760/tcp kreg# BSD Kerberos registration > supfilesrv 871/tcp # SUP server > swat 901/tcp # Samba Web Administration Tool > +ftps-data989/tcp # ftp data over TLS/SSL > +ftps-data989/udp # ftp data over TLS/SSL > +ftps 990/tcp # ftp control over TLS/SSL > +ftps 990/udp # ftp control over TLS/SSL I'm OK with adding the TCP ones (though ftp-over-tls always makes me want to rant...). It's not going to run on UDP though so I think those should not be added. Every new entry in this file reduces the range available for dynamic port selection, so it would seem a good idea to cull a few if we're adding some. Here are some likely candidates; - removed a few UDP entries for protocols that won't use it - dropped some obsolete protocols - moved smtps/465 to the standards section (rfc8314) - moved the IANA UDP/TCP policy from a comment in /etc/services to the manual, and added a pointer to the baddynamic sysctls Index: share/man/man5/services.5 === RCS file: /cvs/src/share/man/man5/services.5,v retrieving revision 1.13 diff -u -p -r1.13 services.5 --- share/man/man5/services.5 3 Mar 2019 17:04:17 - 1.13 +++ share/man/man5/services.5 5 May 2021 09:56:49 - @@ -63,6 +63,20 @@ end of the line are not interpreted by t .Pp Service names may contain any printable character other than a field delimiter, newline, or comment character. +.Pp +To protect service ports from being used for dynamic port assignment, +.Xr rc 8 +reads +.Nm +at boot and uses the contents to populate +.Va net.inet.tcp.baddynamic +and +.Va net.inet.udp.baddynamic . +.Pp +While it is the policy of IANA to assign a single well-known port number +for both TCP and UDP, to avoid reducing the dynamic port range unnecessarily, +the unused entries are not always listed in +.Nm . .Sh FILES .Bl -tag -width /etc/services -compact .It Pa /etc/services Index: etc/services === RCS file: /cvs/src/etc/services,v retrieving revision 1.99 diff -u -p -r1.99 services --- etc/services18 Feb 2021 02:30:29 - 1.99 +++ etc/services5 May 2021 09:56:49 - @@ -3,10 +3,6 @@ # Network services, Internet style # # -# Note that it is presently the policy of IANA to assign a single well-known -# port number for both TCP and UDP; hence, most entries here have two entries -# even if the protocol doesn't support UDP operations. -# tcpmux 1/tcp # TCP port service multiplexer echo 7/tcp @@ -64,10 +60,7 @@ csnet-ns 105/tcp cso-ns # also used by csnet-ns 105/udp cso-ns rtelnet107/tcp # Remote Telnet rtelnet107/udp -pop2 109/tcp postoffice # POP version 2 -pop2 109/udp pop3 110/tcp # POP version 3 -pop3 110/udp sunrpc 111/tcp portmap rpcbind sunrpc 111/udp portmap rpcbind auth 113/tcp authentication tap ident @@ -87,7 +80,6 @@ netbios-dgm 138/udp netbios-ssn139/tcp # NETBIOS session service netbios-ssn139/udp imap 143/tcp imap2 # Internet Message Access Proto -imap 143/udp imap2 # Internet Message Access Proto bftp 152/tcp # Background File Transfer Proto snmp 161/udp # Simple Net Mgmt Proto snmp-trap 162/udp snmptrap# Traps for SNMP @@ -100,11 +92,9 @@ xdmcp 177/udp nextstep 178/tcp NeXTStep NextStep # NeXTStep window nextstep 178/udp NeXTStep NextStep # server bgp179/tcp # Border Gateway Proto. -bgp179/udp prospero 191/tcp # Cliff Neuman's Prospero prospero 191/udp irc194/tcp # Internet Relay Chat -irc194/udp smux 199/tcp # SNMP Unix Multiplexer smux
  Re: Diff for www:FAQ ports/ports
  thanks, committed. On 2021/05/02 15:46, b...@stephane-huc.net wrote: > Hi, > > Here a diff for www page: FAQ ports/ports > > Hi, see this typo error on the page. > > Right? > > > Index: faq/ports/ports.html > === > RCS file: /cvs/www/faq/ports/ports.html,v > retrieving revision 1.57 > diff -u -r1.57 ports.html > --- faq/ports/ports.html 4 Dec 2020 17:08:16 - 1.57 > +++ faq/ports/ports.html 2 May 2021 13:42:42 - > @@ -759,7 +759,7 @@ > available (for example, if the main port is neomutt-20201127, > the debug package will be debug-neomutt-20201127). > These contain debug symbols which have been separated into a different > -ile; GDB knows how to load it automatically. > +file; GDB knows how to load it automatically. > The debug package must match the main package. > If you are using snapshots, you may need to reinstall to ensure that > they are from the same build. >
  Re: monotonic time going back by wrong skews
  On 2021/04/05 09:34, Scott Cheloha wrote: > > On Apr 5, 2021, at 09:07, Stuart Henderson wrote: > > > >) > > This is probably NUMA latency when synchronizing between packages. Interesting, just updated a dual socket R610 (Intel(R) Xeon(R) CPU L5520 @ 2.27GHz, 2394.39 MHz, 06-1a-05, smt 0/1, core 0-3, package 0/1) to 6.9 and remembered about this. In that case there's no "disabling user TSC". Production server so not a good one for running debug kernels etc..but thought it was worth drafting a quick mail to mention that it's not all NUMA machines.
  Re: Respect X-Forwarded-Proto in httpd
  On 2021/04/27 16:23, Raymond E. Pasco wrote: > On Tue Apr 27, 2021 at 3:40 PM EDT, Stuart Henderson wrote: > >). > > I think this header is usually set by administrators in a configuration > file, at least for nginx; something that aims to be more out-of-the-box > like Caddy sets it automatically. > > My understanding is that common reverse proxies can be told to rewrite > the Location header in this and similar cases, but I haven't looked > closely at it. > It's the other way round, this (or proto= in the newer standardised Forwarded header) would be set by a reverse proxy to indicate the protocol that the client request came in on so that something running on the webserver could react accordingly (either in URL construction or to issue a redirect to https if wanted).
  Re: Respect X-Forwarded-Proto in httpd
  On 2021/04/27 10:40, Vincent Lee wrote: > > Hi all, > > Consider the following situation. A reverse proxy which performs TLS > termination is deployed in front of httpd, which listens unencrypted on > localhost. > > There is code in httpd to handle the case where a directory is accessed, > but the path named does not end with a slash. In this case, httpd > issues a 301 redirect to the path with a slash appended. > The logic here sets the protocol of the redirect path based on > whether the httpd virtual server is configured with TLS, but this isn't > enough because it will cause redirects to plain http when there is a > reverse proxy in front of httpd that performs TLS termination. > This will either cause an extra redirect round trip to get back to HTTPS, > or break the site if it's not publicly served on plain HTTP. > > Instead, we should be reading X-Forwarded-Proto, which most reverse proxies > add to inform the backing server what the original protocol was. > (relayd doesn't expose this to my knowledge, but I will look into doing so) > > The below attached diff does this for httpd. This is my first diff to the > project, so please give feedback on whether I've done everything right.).
  Re: enable dt(4)
  On 2021/04/26 17:13, Sebastien Marie wrote: > On Mon, Apr 26, 2021 at 12:35:11PM +0200, Patrick Wildt wrote: > > Hi, > > > > as proposed by bluhm@ recently, this is the diff to enable dt(4) in > > GENERIC. The overhead should be small, and I have been using it on > > arm64 to successfully debug issues for a while now. > > I would be fine with dt(4) enabled too. > > > I can't vouch that it builds for all architectures... Did anyone do > > that? Number 1 rule: don't break Theo's build. > > One test would be to build on i386 (with full release process): we are > near the limit currently, so it could overflow the available disk > space very easily. Disk space only really matters for ramdisk kernels, doesn't it? > Regarding usefulness on archs, dt(4) has proper frames-skip support > for amd64, prowerpc64 and sparc64 only (others archs would default to > "don't skip frames in stack traces"). > > Thanks. > -- > Sebastien Marie >
  Re: Unlock top part of uvm_fault()
  On 2021/04/22 15:38, Martin Pieuchot wrote: > Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for > both amd64 and sparc64. That means the kernel lock will only be taken > for lower faults and some amap/anon code will now run without it. > > I'd be interested to have this tested and see how much does that impact > the build time of packages. > > We should be able to do the switch on an arch-by-arch basis. It's > easier for me to develop & debug on these two architectures so I started > with them. If you want to unlock another architecture and report back, > I'd be glad. i386 with the below diff has survived a ports bulk build; machines are quad core but I only run builds on 3 concurrent to keep a cap on RAM use. Hard to say if there's any change in build time as they're a bit variable anyway; seems to be not much change either way. Perhaps this is more important with larger numbers of cores though. Index: arch/i386/i386/trap.c === RCS file: /cvs/src/sys/arch/i386/i386/trap.c,v retrieving revision 1.151 diff -u -p -r1.151 trap.c --- arch/i386/i386/trap.c 27 Oct 2020 19:17:12 - 1.151 +++ arch/i386/i386/trap.c 22 Apr 2021 20:20:58 - @@ -126,10 +126,7 @@ upageflttrap(struct trapframe *frame, ui union sigval sv; int signal, sicode, error; - KERNEL_LOCK(); error = uvm_fault(>p_vmspace->vm_map, va, 0, access_type); - KERNEL_UNLOCK(); - if (error == 0) { uvm_grow(p, va); return 1; @@ -203,9 +200,7 @@ kpageflttrap(struct trapframe *frame, ui if (curcpu()->ci_inatomic == 0 || map == kernel_map) { onfault = pcb->pcb_onfault; pcb->pcb_onfault = NULL; - KERNEL_LOCK(); error = uvm_fault(map, va, 0, access_type); - KERNEL_UNLOCK(); pcb->pcb_onfault = onfault; if (error == 0 && map != kernel_map)
  Re: ugen(4) communication issues with UPS (nut) blazer_usb and nutdrv_qx
  On 2021/04/22 22:52, xs wrote: > - I've seen mentions of usb_quirks.c for usbhid driver in > /usr/local/share/doc/pkg-readmes/nut > ``` > The option with fewest side-effects is to add the following entries to > the table in /sys/dev/usb/usb_quirks.c and build a new kernel: > > { USB_VENDOR_APC, USB_PRODUCT_APC_UPS, ANY, { UQ_BAD_HID }}, > { USB_VENDOR_APC, USB_PRODUCT_APC_UPS5G, ANY, { UQ_BAD_HID }}, > ``` > > - Would it be useful ? No. That is for the case where a USB attaches to the uhid/upd drivers; sometimes a device can still work with NUT when that happens, but often not. > - Is this related: > ? Since it's attaching to ugen: no. > - What should I try to get this USB communication reliable ? Did it work any better with an older version? Userland access to USB devices is definitely not perfect in OpenBSD. btw, dmesg was missing from your mail.
  Re: POSIX_C_SOURCE 200809L, XOPEN_SOURCE 700 and bsd_locale_fallbacks errors
  On 2021/04/13 19:36, Rafael Sadowski wrote: > Based on my cmake pull-request(1) to fix the cmake build on OpenBSD, the > following question has arisen which is worth analysing? > > "It seems OpenBSD has a strange behavior because macro _POSIX_C_SOURCE is a > standard! @sizeofvoid What are the errors raised if _POSIX_C_SOURCE or > _XOPEN_SOURCE are defined?" -- Marc Chevrier is this the same problem as ? > [1]: > > The following code includes the if-defs from cmake with a simple sstream > include. > > $ cat define_test.cxx > #if !defined(_WIN32) && !defined(__sun) > // POSIX APIs are needed > // NOLINTNEXTLINE(bugprone-reserved-identifier) > # define _POSIX_C_SOURCE 200809L > #endif > #if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(__NetBSD__) > // For isascii > // NOLINTNEXTLINE(bugprone-reserved-identifier) > # define _XOPEN_SOURCE 700 > #endif > > #include > int main () { return 0; } > > $ clang++ -std=c++17 define_test.cxx # also with c++11/14 >:17: error: use of undeclared > identifier 'vasprintf'; did you mean 'vsprintf'? > int __res = vasprintf(__s, __format, __va); > ^ > /usr/include/c++/v1/cstdio:124:9: note: 'vsprintf' declared here > using ::vsprintf; > ^ >:27: error: cannot initialize > a parameter of type 'char *' with an lvalue of type 'char **' > int __res = vasprintf(__s, __format, __va); > ^~~ > /usr/include/stdio.h:269:21: note: passing argument to parameter here > int vsprintf(char *, const char *, __va_list); > ^ > 2 errors generated > > Looks like, if "_XOPEN_SOURCE 700" or "_POSIX_C_SOURCE 200809L" is defined we > run in this compile error. The question is, is that deliberate? >
  Re: libressl pc files
  [this is re:] On 2021/04/12 13:25, Todd C. Miller wrote: > This is a bit of a mess. LibreSSL portable puts the LibreSSL version > number in the pc files. In-tree LibreSSL uses 1.0.0 which is clearly > wrong--using SHLIB_VERSION_NUMBER for the version makes absolutely > no sense to me. The pc files used by OpenSSL also use the release > version. The simplest thing would be for us to use the LibreSSL > version too. > > For third-party code that uses "pkg-config --atleast-version=foo", > it might be more useful to list what version of OpenSSL we are > "compatible" with but I don't think that is really workable since > there is no one-to-one comparison. My preference would be to just > extract the version from LIBRESSL_VERSION_TEXT in opensslv.h. > > - todd That sounds reasonable. I also found suggesting the same approach with LIBRESSL_VERSION_TEXT (and a 2015 mail of mine with a related problem). I don't really expect problems (and can do ports tests at least on i386) but for safety let's look at this after unlock.
  Re: wcwidth of soft hyphen
  On 2021/04/06 13:09, Martijn van Duren wrote: > I´m also not convinced that the other wcwidth implementations might be > on to something and that the unicode consortium is having inertia > problems. The difficulty is that it isn't *possible* to give a single correct answer for the width of SHY, it varies and can only be identified when other information about the terminal is taken into account (how the terminal behaves and whether the word currently printed is being wrapped), which is out of scope for wcwidth(3). So no surprise different people come up with a different way to handle it. > If you want to show a hyphen in your text, use a hyphen. If you want to > indicate where a word might be broken up in a hyphenated way across two > lines if the software knows the localized grammar rules use a SHY. > Also thanks to sthen@ for pointing out where the confusion comes from: > we´re using UTF-8 here, not ISO-8859-1, so we must make sure that we > use the UTF-8 definitions. but, guess what happens when text is converted from ISO-8859-1 to UTF-8... $ printf '\xad' | iconv -f iso-8859-1 -t utf-8 | hexdump -C c2 ad |..|
  Re: wcwidth of soft hyphen
  On 2021/04/05 12:45, Theo de Raadt wrote: > So, your argument is that displays should remain broken forever. > > > The bug in NetBSD and Linux should be fixed, but that's off-topic here. > > If you cannot explain how this problem is going to be fixed (reversed) > in these opposing ecosystems (and it is not just Linux and NetBSD), then > you've closed the argument with a cop-out. > > It cannot be off-topic. > > It is an interop problem which must be settled. > > From time to time, defacto standards arise which have inertia that > is too great to fight. > > Your position seems to me that original standard are etched in stone and > it is impossible to have new defacto standards arise, and if interop > issues arrive, screw everyone -- can't they see there is a stone? Some terminal emulators are using iso-8859-1 semantics of soft hyphen, unicode did things differently but those terminals haven't changed. xterm printed as hyphen mlterm printed as hyphen putty printed as hyphen urxvt overprinted on previous character st not printed, no space kitty not printed, no space cool-retro-term not printed, no space sakura printed as space There's some more about this on, it's all a mess. Pragmatically the simplest fix for the original problem might be if irssi filtered out soft-hyphen characters like mutt does in its "is_display_corrupting_utf8()" function:
  Re: monotonic time going back by wrong skews
  On 2021/04/06 07:27, Marcus MERIGHI wrote: > Morning! > > scottchel...@gmail.com (Scott Cheloha), 2021.04.05 (Mon) 22:25 (CEST): > > To be clear, userland TSC is disabled on this machine, yes? And this > > is a physical server, not a VM? > > $ sysctl |grep tsc > kern.timecounter.hardware=tsc > > Do you want me to disable this? This is different and is for the kernel timecounter source. The message "disabling user TSC" relates to using TSC on the CPU currently executing code directly in userland, bypassing the call into the kernel and avoiding some locking. Without userland TSC it calls into the kernel to fetch time, using whatever source the kernel is using (which could be TSC or acpihpet or i8254 etc). I think (but am not 100% sure) that when used as the kernel source, TSC is always queried from the boot processor so it doesn't matter about differences between cores. Whereas from userland it uses the TSC in whichever cpu is running the current process so this is important (a static skew is corrected but if the cpu clocks don't advance in sync with each other that will cause problems and means that this metjod can't bebuswd). > yasuoka@ found a dmesg with > > cpu11: disabling user TSC (skew=240) > cpu11: smt 0, core 3, package 1 > > from this server (on ports@). I do not see such messages in the current > dmesg. If you use the diff with "if (abs(diff) < abs(val))" to change how the skew is calculated, it may well not trigger the "disabling user TSC" so check dmesg with either plain -current, or just the diff to add debug.
  Re: monotonic time going back by wrong skews) 2 SMT per core, 6 core per package, 2 packages. s-c-p in the below are smt/core/package for each cpu, i.e. cpu0: smt 0, core 0, package 0 cpu1: smt 0, core 0, package 1 cpu2: smt 0, core 1, package 0 cpu3: smt 0, core 1, package 1 etc. cpu s-c-p Min MaxMedian AvgStddev 1 0-0-1 -65 498 157 152.071 28.014331 2 0-1-0 -2213-4 -4.91 7.8085128 3 0-1-1 -42 507 112116.39 27.882671 4 0-2-0 -14 7-2-0.272 4.7497975 5 0-2-1 3 380 137 138.336 18.935249 6 0-3-0 -2517-5-4.035 6.9143028 7 0-3-1 -136 2998687.687 22.889101 8 0-4-0 -24 4 -10 -8.81 5.0030921 9 0-4-1 -355 353-6-25.56 69.909611 10 0-5-0 7412726.838 7.2798869 11 0-5-1 -313 16319 7.541 62.852118 12 1-0-0 -3015-3 -6.58 9.1155193 13 1-0-1 -331 439 17.5 0.494 67.932708 14 1-1-0 -3012-9-9.583 6.0745379 15 1-1-1 -358 432 -15 -28.774 74.476155 16 1-2-0 -2814-9-9.666 6.8339701 17 1-2-1 -339 459-9 -31.638 77.072817 18 1-3-0 -2919-8-7.896 7.3815765 19 1-3-1 -211 289 -101 -59.981 63.882655 20 1-4-0 -2128-1-1.064 7.7156617 21 1-4-1 -338 417 -24.5 -31.543 77.017062 22 1-5-0-1391716.359 5.3022857 23 1-5-1 -352 44728 8.155 69.831278 Grouping them by package/smt: N Min Max Median AvgStddev cpu-p0-smt0 5000 -25 41 -31.7622 14.367997 cpu-p0-smt1 6000 -30 39 -5-3.0716667 11.631154 cpu-p1-smt0 6000-355 507 100 79.410833 79.21407 cpu-p1-smt1 6000-358 4594-23.881167 75.312631 CPU has ITSC, I do not have any "clock going backwards" with monotime.c with kern.timecounter.hardware=tsc. r620-E5_2630v2-2p6c2t.tgz Description: application/tar-gz
  usbdevs huawei tidying
  This removes a bunch of extra "HUAWEI Mobile", add model numbers according to our macros (some are used on more than one device but should be close enough), add radio type where I could figure it out. ok? Index: usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.735 diff -u -p -r1.735 usbdevs --- usbdevs 28 Mar 2021 12:06:35 - 1.735 +++ usbdevs 30 Mar 2021 18:35:06 - @@ -2281,32 +2281,32 @@ product HTC SMARTPHONE 0x0a51 SmartPhon product HTC ANDROID0x0ffe Android phone /* HUAWEI products */ -product HUAWEI E6180x1001 HUAWEI Mobile E618 -product HUAWEI E2200x1003 HUAWEI Mobile Modem -product HUAWEI MOBILE 0x1008 HUAWEI Mobile Modem -product HUAWEI EM770W 0x1404 HUAWEI Mobile Modem -product HUAWEI E1750 0x1406 HUAWEI Mobile Modem -product HUAWEI E1800x140c HUAWEI Mobile E180 -product HUAWEI E5100x1411 HUAWEI Mobile E510 -product HUAWEI E1810x1414 HUAWEI Mobile E181 -product HUAWEI E1752 0x1417 HUAWEI Mobile Modem -product HUAWEI E1820x1429 HUAWEI Mobile Modem -product HUAWEI E3372 0x1442 HUAWEI Mobile Modem -product HUAWEI E1610x1446 HUAWEI Mobile Modem -product HUAWEI K3765 0x1465 HUAWEI Mobile K3765 -product HUAWEI E1820 0x14ac HUAWEI Mobile Modem -product HUAWEI K4511 0x14b7 HUAWEI Mobile Modem K4511 -product HUAWEI K4510 0x14c5 HUAWEI Mobile Modem -product HUAWEI K3772 0x14cf HUAWEI Mobile K3772 -product HUAWEI E353_INIT 0x14fe HUAWEI Mobile E353 Initial -product HUAWEI E392_INIT 0x1505 HUAWEI Mobile E392 Initial -product HUAWEI K3765_INIT 0x1520 HUAWEI Mobile K3765 Initial -product HUAWEI K3772_INIT 0x1526 HUAWEI Mobile K3772 Initial -product HUAWEI MU609 0x1573 HUAWEI Mobile ME906 +product HUAWEI E6180x1001 E618 HSDPA +product HUAWEI E2200x1003 E220 HSDPA +product HUAWEI MOBILE 0x1008 Modem +product HUAWEI EM770W 0x1404 EM770W WCDMA +product HUAWEI E1750 0x1406 E1750 HSDPA +product HUAWEI E1800x140c E180 HSDPA +product HUAWEI E5100x1411 E510 HSDPA/DVB-T +product HUAWEI E1810x1414 E181 HSDPA +product HUAWEI E1752 0x1417 E1752 HSDPA +product HUAWEI E1820x1429 E182 HSDPA +product HUAWEI E3372 0x1442 E3372 LTE +product HUAWEI E1610x1446 E161 HSDPA +product HUAWEI K3765 0x1465 K3765 HSDPA +product HUAWEI E1820 0x14ac E1820 HSDPA +product HUAWEI K4511 0x14b7 K4511 HSDPA +product HUAWEI K4510 0x14c5 K4510 HSDPA +product HUAWEI K3772 0x14cf K3772 LTE +product HUAWEI E353_INIT 0x14fe E353 Initial +product HUAWEI E392_INIT 0x1505 E392 Initial +product HUAWEI K3765_INIT 0x1520 K3765 Initial +product HUAWEI K3772_INIT 0x1526 K3772 Initial +product HUAWEI MU609 0x1573 ME906 LTE product HUAWEI ME906S 0x15c1 ME906s LTE -product HUAWEI E173S 0x1c05 HUAWEI Mobile E173s -product HUAWEI E173S_INIT 0x1c0b HUAWEI Mobile E173s Initial -product HUAWEI E3030x1f01 HUAWEI Mobile E303 +product HUAWEI E173S 0x1c05 E173s HSDPA +product HUAWEI E173S_INIT 0x1c0b E173s Initial +product HUAWEI E3030x1f01 E303 HSDPA /* Huawei 3Com products */ product HUAWEI3COM WUB320G 0x0009 Aolynk WUB320g
  Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)
  On 2021/03/28 13:40, Patrick Wildt wrote: > Am Sun, Mar 28, 2021 at 10:53:53AM +0100 schrieb Stuart Henderson: > >? > > Yes, please do. ok patrick@ Thanks, done. Since it looks like we're going to need additional quirks to get Huawei to work and having three separate vid/pid tables seems silly, here's a diff to change to using a single pid/vid table covering the matches and the existing fccauth quirk. Tested with EM7455 (fcc auth required; works as before) and Huawei (attaches to the correct config descriptor; packet transfer not working but this is not unexpected). Index: if_umb.c === RCS file: /cvs/src/sys/dev/usb/if_umb.c,v retrieving revision 1.38 diff -u -p -r1.38 if_umb.c --- if_umb.c28 Mar 2021 12:08:58 - 1.38 +++ if_umb.c28 Mar 2021 13:10:56 - @@ -224,34 +224,34 @@ umb_quirk { struct usb_devno dev; - int confno; + u_int32_tumb_flags; + int umb_confno; + int umb_match; }; -const struct umb_products umb_devs[] = { - { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E }, 2 }, - { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S }, 3 }, +const struct umb_quirk umb_quirks[] = { + { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E }, + 0, + 2, + UMATCH_VENDOR_PRODUCT + }, + + { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S }, + 0, + 3, + UMATCH_VENDOR_PRODUCT + }, + + { { USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_EM7455 }, + UMBFLG_FCC_AUTH_REQUIRED, + 0, + 0 + }, }; #define umb_lookup(vid, pid) \ - ((const struct umb_products *)usb_lookup(umb_devs, vid, pid)) - -/* - * These devices require an "FCC Authentication" command. - */ -const struct usb_devno umb_fccauth_devs[] = { - { USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_EM7455 }, -}; + ((const struct umb_quirk *)usb_lookup(umb_quirks, vid, pid)) uint8_t umb_qmi_alloc_cid[] = { 0x01, @@ -283,10 +283,12 @@ int umb_match(struct device *parent, void *match, void *aux) { struct usb_attach_arg *uaa = aux; + const struct umb_quirk *quirk; usb_interface_descriptor_t *id; - if (umb_lookup(uaa->vendor, uaa->product) != NULL) - return UMATCH_VENDOR_PRODUCT; + quirk = umb_lookup(uaa->vendor, uaa->product); + if (quirk != NULL && quirk->umb_match) + return (quirk->umb_match); if (!uaa->iface) return UMATCH_NONE; if ((id = usbd_get_interface_descriptor(uaa->iface)) == NULL) @@ -317,6 +319,7 @@ umb_attach(struct device *parent, struct { struct umb_softc *sc =
  Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)? > I added this product to usbdevs as a short string; the other Huawei > devices all say "HUAWEI Mobile xyz" rather than just "xyz" in the device > string which I think should be trimmed as well, probably worth doing > that on top. > > > Index: share/man/man4/umb.4 > === > RCS file: /cvs/src/share/man/man4/umb.4,v > retrieving revision 1.11 > diff -u -p -r1.11 umb.4 > --- share/man/man4/umb.4 12 May 2020 13:03:52 - 1.11 > +++ share/man/man4/umb.4 25 Mar 2021 00:03:58 - > @@ -44,8 +44,10 @@ PIN again even if the system was reboote > The following devices should work: > .Pp > .Bl -tag -width Ds -offset indent -compact > +.It Dell DW5821e > .It Ericsson H5321gw and N5321gw > .It Fibocom L831-EAU > +.\" .It Huawei ME906s -- attaches but may need more work > .It Medion Mobile S4222 (MediaTek OEM) > .It Sierra Wireless EM7345 > .It Sierra Wireless EM7455 > Index: sys/dev/usb/if_umb.c > === > RCS file: /cvs/src/sys/dev/usb/if_umb.c,v > retrieving revision 1.37 > diff -u -p -r1.37 if_umb.c > --- sys/dev/usb/if_umb.c 29 Jan 2021 17:06:19 - 1.37 > +++ sys/dev/usb/if_umb.c 24 Mar 2021 23:52:13 - > @@ -225,6 +225,28 @@ usb_devno dev; > + int confno; > +}; > +const struct umb_products umb_devs[] = { > + { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E }, 2 }, > + { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S }, 3 }, > +}; > + > +#define umb_lookup(vid, pid) \ > + ((const struct umb_products *)usb_lookup(umb_devs, vid, pid)) > + > +/* > * These devices require an "FCC Authentication" command. > */ > const struct usb_devno umb_fccauth_devs[] = { > @@ -263,6 +285,8 @@ umb_match(struct device *parent, void *m > struct usb_attach_arg *uaa = aux; > usb_interface_descriptor_t *id; > > + if (umb_lookup(uaa->vendor, uaa->product) != NULL) > + return UMATCH_VENDOR_PRODUCT; > if (!uaa->iface) > return UMATCH_NONE; > if ((id = usbd_get_interface_descriptor(uaa->iface)) == NULL) > @@ -315,6 +339,43 @@ umb_attach(struct device *parent, struct > sc->sc_ctrl_ifaceno = uaa->ifaceno; > ml_init(>sc_tx_ml); > > + if (uaa->configno < 0) { > + /* > + * In case the device was matched by VID/PID instead of > + * InterfaceClass/InterfaceSubClass, we have to pick the > + * correct configuration ourself. > + */ > + uaa->configno = umb_lookup(uaa->vendor, uaa->product)->confno; > + DPRINTF("%s: switching to config #%d\n", DEVNAM(sc), > + uaa->configno); >
  Re: disable PPP_BSDCOMP by default
  On 2021/03/25 20:53, Balder Oddson wrote: > On Thu, Mar 25, 2021 at 07:09:37PM +0100, Balder Oddson wrote: > > Compression in PPP was great in the age of ISDN to increase speeds. > > The more common use cases, and trends concerning TLS1.3 advancements. > > > > Having this enabled by default, and infrequently used could lead to > > unintended consequences around how the data is passed around. > > > Off list it has been suggested that this is ridiciolous. > And perhaps this is, especially for the justifications given, thought be > sufficient. > > From a UNIX architectural perspectiv, adhering to things like > "everything is a file". > > PPP device are not physical devices that can be used for a PPP > connection, where it is more trivial with a practice to do compression > and decompression before presenting the payload to the kernel so its > forced to go through the usual barriers. > > Back in the day, when everything was a PPP connection for most people, > this made good sense and also gave good performance. > > Having code in the kernel that is even better than say, base64 that can > detangle a malicious payload isn't the point here. There shouldn't be > targetable code in the kernel for these kinds of tasks that can be > exploited. And the task should preferably be something outside of kernel > space or in a real device driver. I don't quite understand what you're saying here but it sounds like you're trying to remove one of the copies of libz is used so it can't be accessed from the kernel, is that it? What's the point, there are others? Do you want to remove hibernate as well? > Not having read the code, case in point on principle, I'm arguing that > there should be solid reasoning to enable it by default, as those with a > need for it can certainly enable it and build a kernel. It's not that simple, using a custom kernel means you can't use syspatches so are more likely to stay on a vulnerable version if a kernel bug is fixed. > Maybe this isn't a huge concern for the network parts of the code, but > as soon as there is multiprocessing and desktop applications involved, > it becomes increasingly unattractive. What's the technical reasons for > this code in 2020? > > option INET6 # IPv6 > > option IPSEC # IPsec > > -option PPP_BSDCOMP # PPP BSD compression > > -option PPP_DEFLATE > > +#optionPPP_BSDCOMP # PPP BSD compression > > +#optionPPP_DEFLATE # Disabled by default, TLS1.3 trends This comment doesn't make any sense > > option PIPEX # Ppp IP EXtension, for npppd > > option MROUTING# Multicast router > > option MPLS# Multi-Protocol Label Switching > > -- > Balder Oddson >