pax mtime

2021-10-15 Thread Stuart Henderson
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
https://pypi.io/packages/source/w/wheel/wheel-0.36.2.tar.gz

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

2021-10-11 Thread Stuart Henderson
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

2021-10-10 Thread Stuart Henderson
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:
> 
> https://marc.info/?l=openbsd-tech=163388435528203=2

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

2021-10-09 Thread Stuart Henderson
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

2021-10-09 Thread Stuart Henderson
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)

2021-10-05 Thread Stuart Henderson
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
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/Attic/sysctl.3#rev1.178
> 
> 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

2021-10-01 Thread Stuart Henderson
On 2021/10/01 14:43, Stuart Henderson wrote:
> On 2021/10/01 09:29, abyx...@mnetic.ch wrote:
> > I'm getting a daily crash (call to fatalx). No clue what triggers it and 
> > the logging is really sparse. I couldn't follow what the code in ca.c is 
> > actually doing (what the hash belongs to that is triggering the crash). A 
> > snip from /var/log/daemon is reproduced below. There are no other log 
> > messages in any logs around the same time frame as the relayd shutdown. 
> > Also, that fd passing failed for https is concerning. Any suggestions in 
> > debugging this? OpenBSD 6.9, dmesg at bottom. 
> > 
> > 
> > grep relayd /var/log/daemon
> > 876:Sep 30 15:07:39 mnetic relayd[222]: adding 1 hosts from table 
> > axolotlfeeds:7053 (no check)
> > 877:Sep 30 15:07:39 mnetic relayd[44589]: adding 1 hosts from table 
> > axolotlfeeds:7053 (no check)
> > 878:Sep 30 15:07:39 mnetic relayd[57595]: adding 1 hosts from table 
> > axolotlfeeds:7053 (no check)
> > 909:Oct  1 00:42:20 mnetic relayd[95946]: ca: ca_dispatch_relay: invalid 
> > relay hash 
> > 'SHA256:f545fa75bd01d82c05359e21ae769d525c2971b8221a8e50e415fe3e62ea6553'
> > 910:Oct  1 00:42:20 mnetic relayd[44589]: relay: pipe closed
> > 911:Oct  1 00:42:20 mnetic relayd[8473]: hce exiting, pid 8473
> > 912:Oct  1 00:42:20 mnetic relayd[15293]: pfe exiting, pid 15293
> > 913:Oct  1 00:42:20 mnetic relayd[29437]: ca exiting, pid 29437
> > 914:Oct  1 00:42:20 mnetic relayd[52845]: ca exiting, pid 52845
> > 915:Oct  1 00:42:20 mnetic relayd[99285]: parent terminating, pid 99285
> > 916:Oct  1 00:42:20 mnetic relayd[222]: relay exiting, pid 222
> > 917:Oct  1 00:42:20 mnetic relayd[57595]: relay exiting, pid 57595
> > 921:Oct  1 09:12:59 mnetic relayd[2129]: startup
> > 922:Oct  1 09:12:59 mnetic relayd[2129]: config_setrelay: fd passing failed 
> > for `https': Too many open files
>   
>  ^^^
> 
> By default the limit for relayd is controlled by the openfiles settings
> for the "daemon" class in /etc/login.conf. You can check current use
> with fstat | grep -c relayd. If you need to raise it you can add
> something like this to the file, replacing XXX with "what you normally
> see when it's busy plus some extra leeway" and then "rcctl restart
> relayd" so it takes effect.
> 
> relayd:\
> :openfiles-max=XXX:\
> :openfiles-cur=XXX:\
> :tc=default:

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

2021-10-01 Thread Stuart Henderson
On 2021/10/01 09:29, abyx...@mnetic.ch wrote:
> I'm getting a daily crash (call to fatalx). No clue what triggers it and the 
> logging is really sparse. I couldn't follow what the code in ca.c is actually 
> doing (what the hash belongs to that is triggering the crash). A snip from 
> /var/log/daemon is reproduced below. There are no other log messages in any 
> logs around the same time frame as the relayd shutdown. Also, that fd passing 
> failed for https is concerning. Any suggestions in debugging this? OpenBSD 
> 6.9, dmesg at bottom. 
> 
> 
> grep relayd /var/log/daemon
> 876:Sep 30 15:07:39 mnetic relayd[222]: adding 1 hosts from table 
> axolotlfeeds:7053 (no check)
> 877:Sep 30 15:07:39 mnetic relayd[44589]: adding 1 hosts from table 
> axolotlfeeds:7053 (no check)
> 878:Sep 30 15:07:39 mnetic relayd[57595]: adding 1 hosts from table 
> axolotlfeeds:7053 (no check)
> 909:Oct  1 00:42:20 mnetic relayd[95946]: ca: ca_dispatch_relay: invalid 
> relay hash 
> 'SHA256:f545fa75bd01d82c05359e21ae769d525c2971b8221a8e50e415fe3e62ea6553'
> 910:Oct  1 00:42:20 mnetic relayd[44589]: relay: pipe closed
> 911:Oct  1 00:42:20 mnetic relayd[8473]: hce exiting, pid 8473
> 912:Oct  1 00:42:20 mnetic relayd[15293]: pfe exiting, pid 15293
> 913:Oct  1 00:42:20 mnetic relayd[29437]: ca exiting, pid 29437
> 914:Oct  1 00:42:20 mnetic relayd[52845]: ca exiting, pid 52845
> 915:Oct  1 00:42:20 mnetic relayd[99285]: parent terminating, pid 99285
> 916:Oct  1 00:42:20 mnetic relayd[222]: relay exiting, pid 222
> 917:Oct  1 00:42:20 mnetic relayd[57595]: relay exiting, pid 57595
> 921:Oct  1 09:12:59 mnetic relayd[2129]: startup
> 922:Oct  1 09:12:59 mnetic relayd[2129]: config_setrelay: fd passing failed 
> for `https': Too many open files

   ^^^

By default the limit for relayd is controlled by the openfiles settings
for the "daemon" class in /etc/login.conf. You can check current use
with fstat | grep -c relayd. If you need to raise it you can add
something like this to the file, replacing XXX with "what you normally
see when it's busy plus some extra leeway" and then "rcctl restart
relayd" so it takes effect.

relayd:\
:openfiles-max=XXX:\
:openfiles-cur=XXX:\
:tc=default:


> 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
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> 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)

2021-09-30 Thread Stuart Henderson
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:
> 
>   https://www.openbsd.org/errata68.html
>   https://www.openbsd.org/errata69.html
> 

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 ftp.usa.openbsd.org, ftp.hostserver.de,
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)

2021-09-30 Thread Stuart Henderson
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)

2021-09-24 Thread Stuart Henderson
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)..
https://marc.info/?t=12021803142=1=2



Re: Should 80MB of RAM be enough for kernel relinking on i386?

2021-09-23 Thread Stuart Henderson
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

2021-09-22 Thread Stuart Henderson
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.
> > > https://marc.info/?l=openbsd-cvs=161213948819452=2
> > 
> > It's also on http://www.openbsd.org/faq/upgrade69.html
> 
> 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

2021-09-17 Thread Stuart Henderson
Moved to tech@. Full original mail at 
https://marc.info/?l=openbsd-misc=163187837530385=2

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

2021-09-10 Thread Stuart Henderson
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

2021-09-10 Thread Stuart Henderson
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

2021-09-09 Thread Stuart Henderson
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

   If the size
   of the kinfo_proc structure increases in size in a future release of
   OpenBSD, the library will only return the requested amount of data for each
   array entry and programs that use kvm_getprocs() will continue to function
   without the need for recompilation. 

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-68.9.0/third_party/python/psutil/psutil/_psutil_bsd.c
240:vms = (long)(kp.p_vm_dsize + kp.p_vm_ssize + kp.p_vm_tsize) * 
pagesize;
248:memdata = (long)kp.p_vm_dsize * pagesize;

u/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-68.9.0/third_party/python/psutil/psutil/_psutil_bsd.c
240:vms = (long)(kp.p_vm_dsize + kp.p_vm_ssize + kp.p_vm_tsize) * 
pagesize;
248:memdata = (long)kp.p_vm_dsize * pagesize;

u/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/zabbix-4.0.19/src/libs/zbxsysinfo/openbsd/proc.c
45:#define ZBX_P_VM_DSIZE   p_vm_dsize
53:#define ZBX_P_VM_DSIZE   kp_eproc.e_vm.vm_dsize
262:value = proc[i].ZBX_P_VM_TSIZE + proc[i].ZBX_P_VM_DSIZE 
+ proc[i].ZBX_P_VM_SSIZE;

u/zabbix-4.0.19-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/zabbix-4.0.19/src/libs/zbxsysinfo/openbsd/proc.c
45:#define ZBX_P_VM_DSIZE   p_vm_dsize
53:#define ZBX_P_VM_DSIZE   kp_eproc.e_vm.vm_dsize
262:value = proc[i].ZBX_P_VM_TSIZE + proc[i].ZBX_P_VM_DSIZE 
+ proc[i].ZBX_P_VM_SSIZE;

u/zabbix-4.0.19-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/zabbix-4.0.19/src/libs/zbxsysinfo/openbsd/proc.c
45:#define ZBX_P_VM_DSIZE   p_vm_dsize
53:#define ZBX_P_VM_DSIZE   kp_eproc.e_vm.vm_dsize
262:value = proc[i].ZBX_P_VM_TSIZE + proc[i].ZBX_P_VM_DSIZE 
+ proc[i].ZBX_P_VM_SSIZE;

u/zabbix-4.0.19-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/zabbix-4.0.19/src/libs/zbxsysinfo/openbsd/proc.c
45:#define ZBX_P_VM_DSIZE   p_vm_dsize
53:#define ZBX_P_VM_DSIZE   kp_eproc.e_vm.vm_dsize
262:value = proc[i].ZBX_P_VM_TSIZE + proc[i].ZBX_P_VM_DSIZE 

Re: OpenSSH: RSA/SHA1 disabled by default

2021-09-07 Thread Stuart Henderson
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

2021-09-07 Thread Stuart Henderson
On 2021/09/07 14:40, Martijn van Duren wrote:
> On Mon, 2021-08-30 at 10:08 +1000, Damien Miller wrote:
> > Hi,
> > 
> > RSA/SHA1, a.k.a the "ssh-rsa" signature type is now disabled by default
> > in OpenSSH.
> > 
> > While The SSH protocol confusingly uses overlapping names for key and
> > signature algorithms, this does not stop the use of RSA keys and there
> > is no need to regenerate "ssh-rsa" keys - most servers released in the
> > last five years will automatically negotiate the use of RSA/SHA-256/512
> > signatures.
> > 
> > This has been coming for a long time, but I do expect it will be
> > distruptive for some people as there are likely to be some devices
> > out there that cannot be upgraded to support the safer algorithms.
> > 
> > In these cases, it is possible to selectively re-enable RSA/SHA1
> > support by specifying PubkeyAcceptedAlgorithms=+ssh-rsa in the
> > ssh_config(5) or sshd_config(5) for the endpoint.
> > 
> > Please report any problems here, to bugs@ or to openssh@
> > 
> > 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

2021-09-02 Thread Stuart Henderson
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)

2021-09-01 Thread Stuart Henderson
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)

2021-08-30 Thread Stuart Henderson
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

2021-08-29 Thread Stuart Henderson
On 2021/08/28 22:28, Stuart Henderson wrote:
> Spotted this at the end of a sysupgrade run. No issue with the reboot but
> it doesn't look quite right, in particular the newfs_msdos is a bit scary.
> 
> [...]
> Installing xshare70.tgz 100% |**|  4505 KB00:36   
>  
> Installing xfont70.tgz  100% |**| 39344 KB01:47   
>  
> Installing xserv70.tgz  100% |**| 12346 KB00:11   
>  
> Location of sets? (disk http nfs or 'done') [done] done
> Making all device nodes... done.
> sh: /sbin/fsck_msdos: not found
> newfs_msdos: /dev/rsd0i is mounted on /mnt/boot

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

2021-08-28 Thread Stuart Henderson
Spotted this at the end of a sysupgrade run. No issue with the reboot but
it doesn't look quite right, in particular the newfs_msdos is a bit scary.

[...]
Installing xshare70.tgz 100% |**|  4505 KB00:36
Installing xfont70.tgz  100% |**| 39344 KB01:47
Installing xserv70.tgz  100% |**| 12346 KB00:11
Location of sets? (disk http nfs or 'done') [done] done
Making all device nodes... done.
sh: /sbin/fsck_msdos: not found
newfs_msdos: /dev/rsd0i is mounted on /mnt/boot
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

2021-08-28 Thread Stuart Henderson
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 -
@@ -351,7 +351,7 @@ main(int argc, char *argv[])
rcvsock4 = rcvsock6 = sndsock4 = sndsock6 = -1;
v4sock_errno = v6sock_errno = 0;
 
-   conf->waittime = 5 * 1000;
+   conf->waittime = 3 * 1000;
 
if ((rcvsock6 = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6)) == -1)
v6sock_errno = errno;
@@ -554,9 +554,9 @@ main(int argc, char *argv[])
err(1, "setsockopt SO_RTABLE");
break;
case 'w':
-   conf->waittime = strtonum(optarg, 2, INT_MAX, );
+   conf->waittime = strtonum(optarg, 1, INT_MAX, );
if (errstr)
-   errx(1, "wait must be >1 sec.");
+   errx(1, "wait must be >=1 sec.");
conf->waittime *= 1000;
break;
case 'x':



Re: wg(4) ipv6 ospf6d

2021-08-28 Thread Stuart Henderson
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:
> > > > Trying to announce a network on a wg(4) interface via ospf6d, just
> > > > using passive to pick up the prefix, i.e.
> > > >
> > > > interface wg0 { passive }
> > > >
> > > > It's failing with "/etc/ospf6d.conf:10: unnumbered interface wg0".
> > > >
> > > > With -v I get 'interface with index 27 not found' (this is "normal"
> > > > with ospf6d) and the routable address does show up e.g. "if_newaddr:
> > > > ifindex 27, addr 2a03::xx:xx::/64" before giving the
> > > > unnumbered interface error. There is normally no link-local address
> > > > for wg.
> > > >
> > > > 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?
> > > >
> > > 
> > > 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)

2021-08-28 Thread Stuart Henderson
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

2021-08-25 Thread Stuart Henderson
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

2021-08-25 Thread Stuart Henderson
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:
> https://datatracker.ietf.org/doc/html/rfc5340#section-2.5
> 
> 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

2021-08-25 Thread Stuart Henderson
Trying to announce a network on a wg(4) interface via ospf6d, just
using passive to pick up the prefix, i.e.

interface wg0 { passive }

It's failing with "/etc/ospf6d.conf:10: unnumbered interface wg0".

With -v I get 'interface with index 27 not found' (this is "normal"
with ospf6d) and the routable address does show up e.g. "if_newaddr:
ifindex 27, addr 2a03::xx:xx::/64" before giving the
unnumbered interface error. There is normally no link-local address
for wg.

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?



Re: allow KARL with config(8)'d kernels

2021-08-25 Thread Stuart Henderson
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

2021-08-23 Thread Stuart Henderson
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
> > https://man.openbsd.org/pf.conf#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.
> 
> > however, with this simple config
> > 
> > queue std on re0 bandwidth 100M
> > queue lan parent std bandwidth 100M
> > queue internet parent std bandwidth 900K flows 512 default
> > match proto udp from em0:network to any port 53 queue dns
> > 
> > when reloading the file with pfctl, I get the following error:
> > /etc/pf.conf:27: queue dns is not defined
> > 
> > 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

2021-08-23 Thread Stuart Henderson
On 2021/08/23 19:03, Solene Rapenne wrote:
> pf.conf says this in QUEUEING
> https://man.openbsd.org/pf.conf#QUEUEING
> 
> > If the referenced queue does not exist on the outgoing interface,
> > the default queue for that interface is used.
> 
> however, with this simple config
> 
> queue std on re0 bandwidth 100M
> queue lan parent std bandwidth 100M
> queue internet parent std bandwidth 900K flows 512 default
> match proto udp from em0:network to any port 53 queue dns
> 
> when reloading the file with pfctl, I get the following error:
> /etc/pf.conf:27: queue dns is not defined

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

2021-08-20 Thread Stuart Henderson

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 -
> > @@ -351,7 +351,7 @@ main(int argc, char *argv[])
> > rcvsock4 = rcvsock6 = sndsock4 = sndsock6 = -1;
> > v4sock_errno = v6sock_errno = 0;
> >
> > -   conf->waittime = 5 * 1000;
> > +   conf->waittime = 1000;
> >
> > if ((rcvsock6 = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6)) == -1)
> > v6sock_errno = errno;
> > @@ -554,9 +554,9 @@ main(int argc, char *argv[])
> > err(1, "setsockopt SO_RTABLE");
> > break;
> > case 'w':
> > -   conf->waittime = strtonum(optarg, 2, INT_MAX,
);
> > +   conf->waittime = strtonum(optarg, 1, INT_MAX,
);
> > if (errstr)
> > -   errx(1, "wait must be >1 sec.");
> > +   errx(1, "wait must be >=1 sec.");
> > conf->waittime *= 1000;
> > break;
> > case 'x':
> >
> >
>
> --
> I'm not entirely sure you are real.
>
>






Re: [patch] traceroute timeouts

2021-08-20 Thread Stuart Henderson
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

2021-08-18 Thread Stuart Henderson
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

2021-08-11 Thread Stuart Henderson
On 2021/08/11 19:34, Martijn van Duren wrote:
> On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> > On 2021/08/11 16:35, Martijn van Duren wrote:
> > > Following snmpd, remove the public default community and move to snmpv3
> > > by default. This is also what net-snmp does. I originally chose this
> > > default because that's what snmpctl did and it allowed for easier
> > > interoperability with snmpd(8).
> > 
> > v3 by default makes sense to me.
> > 
> > I'm not sure how much it buys to remove the default community in snmp(1),
> > though, there doesn't seem a lot of benefit to removing it?
> 
> 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 snmp_get="snmp get -v2c -ccommunity"
> 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

2021-08-11 Thread Stuart Henderson
On 2021/08/11 16:35, Martijn van Duren wrote:
> Following snmpd, remove the public default community and move to snmpv3
> by default. This is also what net-snmp does. I originally chose this
> default because that's what snmpctl did and it allowed for easier
> interoperability with snmpd(8).

v3 by default makes sense to me.

I'm not sure how much it buys to remove the default community in snmp(1),
though, there doesn't seem a lot of benefit to removing it?

(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

2021-08-09 Thread Stuart Henderson
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

2021-08-09 Thread Stuart Henderson
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

2021-08-09 Thread Stuart Henderson
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

2021-08-08 Thread Stuart Henderson
On 2021/08/08 10:05, Martijn van Duren wrote:
> > +++ etc/examples/snmpd.conf 7 Aug 2021 21:45:44 -
> > @@ -1,24 +1,26 @@
> >  # $OpenBSD: snmpd.conf,v 1.1 2014/07/11 21:20:10 deraadt Exp $
> >  
> > -listen_addr="127.0.0.1"
> > +# Default is to listen to all addresses for SNMPv3 only; "listen on"
> > +# can be used multiple times. See snmpd.conf(5) for more options.
> > +#listen on 0.0.0.0 snmpv2c # All IPv4 addresses with SNMPv2c
> > +#listen on :: snmpv2c snmpv3   # All IPv6 addresses, both v2c + v3
> > +#listen on 127.0.0.1   # IPv4 localhost only, v3
> 
> 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.

> > +#user "user1" auth hmac-sha1 authkey "password123" enc aes enckey 
> > "321drowssap"
> > +#user "user2" auth hmac-sha256 authkey "password456" enc aes enckey 
> > "654drowssap"
> > +
> > +# Specify one or more trap receivers with optional parameters
> > +#trap receiver nms.localdomain.local community 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

2021-08-07 Thread Stuart Henderson
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
+++ etc/examples/snmpd.conf 7 Aug 2021 21:45:44 -
@@ -1,24 +1,26 @@
 # $OpenBSD: snmpd.conf,v 1.1 2014/07/11 21:20:10 deraadt Exp $
 
-listen_addr="127.0.0.1"
+# Default is to listen to all addresses for SNMPv3 only; "listen on"
+# can be used multiple times. See snmpd.conf(5) for more options.
+#listen on 0.0.0.0 snmpv2c # All IPv4 addresses with SNMPv2c
+#listen on :: snmpv2c snmpv3   # All IPv6 addresses, both v2c + v3
+#listen on 127.0.0.1   # IPv4 localhost only, v3
 
-# 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
+#user "user1" auth hmac-sha1 authkey "password123" enc aes enckey "321drowssap"
+#user "user2" auth hmac-sha256 authkey "password456" enc aes enckey 
"654drowssap"
+
+# Specify one or more trap receivers with optional parameters
+#trap receiver nms.localdomain.local community 

Re: Fix unsafe snmpd defaults

2021-08-05 Thread Stuart Henderson
On 2021/08/03 23:46, Martijn van Duren wrote:
> On Tue, 2021-08-03 at 21:58 +0100, Stuart Henderson wrote:
> > On 2021/08/03 22:07, Martijn van Duren wrote:
> > > On Tue, 2021-08-03 at 18:24 +0100, Stuart Henderson wrote:
> > > > On 2021/06/15 17:39, Stuart Henderson wrote:
> > > > > > Then again, I don't get the feeling many people use snmpd at this 
> > > > > > time
> > > > > > and maybe it's a good moment to bite the bullet and go for safest
> > > > > > defaults possible at this time. But if that's the case I would like 
> > > > > > to
> > > > > > follow up with a diff to changes the default auth to hmac-sha512,
> > > > > > because snmp drops trailing bytes of the result and enc to aes 
> > > > > > instead
> > > > > > of des.
> > > > > 
> > > > > This is the change that feels most likely to affect existing SNMPv3 
> > > > > users.
> > > > > Support in management software beyond aes/sha1 is a bit lacking and 
> > > > > prone
> > > > > to incompatibility (I had issues with net-snmp and snmpd using 
> > > > > hmac-sha256
> > > > > though it seems it will work with hmac-sha512..)
> > > > 
> > > > BTW, having updated a few machines now, I am finding the change to
> > > > sha2-256 by default to be a complete pain, especially considering that
> > > > /etc/examples/snmpd.conf uses "enc aes" but has no setting for auth
> > > > so relies on defaults for that..
> > > > 
> > > I can't do a lot with "a complete pain".
> > > 
> > > Does something like the diff below make things more intuitive? If not,
> > > could you be a little more concrete?
> > > 
> > > martijn@
> > > 
> > > Index: snmpd.conf
> > > ===
> > > RCS file: /cvs/src/etc/examples/snmpd.conf,v
> > > retrieving revision 1.1
> > > diff -u -p -r1.1 snmpd.conf
> > > --- snmpd.conf  11 Jul 2014 21:20:10 -  1.1
> > > +++ snmpd.conf  3 Aug 2021 20:05:53 -
> > > @@ -18,7 +18,9 @@ system services 74
> > >  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
> > >  
> > > -# 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"
> > > +# Create two SNMPv3 USM users:
> > > +# User with default crypto values
> > > +#user "defaultuser" authkey "password123" enckey "321drowssap"
> > > +# User with backwards compatible crypto:
> > > +# Only enable and use when client absolutely can't deal with modern 
> > > defaults.
> > > +#user "compatuser" authkey "password456" auth hmac-md5 enckey 
> > > "654drowssap" enc des
> > > 
> > > 
> > 
> > Given the lack of support for SHA2-256 in much management software until
> > recently AES+SHA is a pretty common configuration. And given the old 
> > snmpd.conf
> > example I think that is often done by copying/editing so just "enc aes" is 
> > there
> > with no auth setting. Wondering if that part might not have been such a good
> > change and what anyone else thinks..
> > 
> 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

2021-08-04 Thread Stuart Henderson
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 https://http.cat/308 is a bit confusing :)



Re: Add versioned lib to system perl's @INC for non-packaged modules

2021-08-04 Thread Stuart Henderson
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 defaults

2021-08-03 Thread Stuart Henderson
On 2021/08/03 22:07, Martijn van Duren wrote:
> On Tue, 2021-08-03 at 18:24 +0100, Stuart Henderson wrote:
> > On 2021/06/15 17:39, Stuart Henderson wrote:
> > > > Then again, I don't get the feeling many people use snmpd at this time
> > > > and maybe it's a good moment to bite the bullet and go for safest
> > > > defaults possible at this time. But if that's the case I would like to
> > > > follow up with a diff to changes the default auth to hmac-sha512,
> > > > because snmp drops trailing bytes of the result and enc to aes instead
> > > > of des.
> > > 
> > > This is the change that feels most likely to affect existing SNMPv3 users.
> > > Support in management software beyond aes/sha1 is a bit lacking and prone
> > > to incompatibility (I had issues with net-snmp and snmpd using hmac-sha256
> > > though it seems it will work with hmac-sha512..)
> > 
> > BTW, having updated a few machines now, I am finding the change to
> > sha2-256 by default to be a complete pain, especially considering that
> > /etc/examples/snmpd.conf uses "enc aes" but has no setting for auth
> > so relies on defaults for that..
> > 
> I can't do a lot with "a complete pain".
> 
> Does something like the diff below make things more intuitive? If not,
> could you be a little more concrete?
> 
> martijn@
> 
> Index: snmpd.conf
> ===
> RCS file: /cvs/src/etc/examples/snmpd.conf,v
> retrieving revision 1.1
> diff -u -p -r1.1 snmpd.conf
> --- snmpd.conf11 Jul 2014 21:20:10 -  1.1
> +++ snmpd.conf3 Aug 2021 20:05:53 -
> @@ -18,7 +18,9 @@ system services 74
>  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
>  
> -# 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"
> +# Create two SNMPv3 USM users:
> +# User with default crypto values
> +#user "defaultuser" authkey "password123" enckey "321drowssap"
> +# User with backwards compatible crypto:
> +# Only enable and use when client absolutely can't deal with modern defaults.
> +#user "compatuser" authkey "password456" auth hmac-md5 enckey "654drowssap" 
> enc des
> 
> 

Given the lack of support for SHA2-256 in much management software until
recently AES+SHA is a pretty common configuration. And given the old snmpd.conf
example I think that is often done by copying/editing so just "enc aes" is there
with no auth setting. Wondering if that part might not have been such a good
change and what anyone else thinks..



Re: Fix unsafe snmpd defaults

2021-08-03 Thread Stuart Henderson
On 2021/06/15 17:39, Stuart Henderson wrote:
> > Then again, I don't get the feeling many people use snmpd at this time
> > and maybe it's a good moment to bite the bullet and go for safest
> > defaults possible at this time. But if that's the case I would like to
> > follow up with a diff to changes the default auth to hmac-sha512,
> > because snmp drops trailing bytes of the result and enc to aes instead
> > of des.
> 
> This is the change that feels most likely to affect existing SNMPv3 users.
> Support in management software beyond aes/sha1 is a bit lacking and prone
> to incompatibility (I had issues with net-snmp and snmpd using hmac-sha256
> though it seems it will work with hmac-sha512..)

BTW, having updated a few machines now, I am finding the change to
sha2-256 by default to be a complete pain, especially considering that
/etc/examples/snmpd.conf uses "enc aes" but has no setting for auth
so relies on defaults for that..



Re: iked(8): Increase the default Child SA data lifetime limit

2021-08-03 Thread Stuart Henderson
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

2021-08-03 Thread Stuart Henderson
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)

2021-08-01 Thread Stuart Henderson
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

2021-07-25 Thread Stuart Henderson
On 2021/07/25 13:25, Mark Kettenis wrote:
> > Date: Sun, 25 Jul 2021 12:08:09 +0100
> > From: Stuart Henderson 
> > 
> > On 2021/07/25 14:55, Jonathan Matthew wrote:
> > > On Thu, Jul 22, 2021 at 10:45:17PM -0400, Ashton Fagg wrote:
> > > > I have two devices here based on the JMicron JMB585 chipset. This diff
> > > > adds the required pcidev IDs and sets disables native command queuing in
> > > > the driver. FreeBSD does something similar for this device:
> > > > 
> > > > https://github.com/freebsd/freebsd-src/commit/16b766eed443043f4216d50e40ba283e74f992c2
> > > 
> > > Can you explain how you came to the conclusion that you'd need to
> > > disable NCQ?  The FreeBSD commit you link to doesn't appear to do that
> > > as they're not applying the AHCI_Q_NONCQ flag to these devices.
> > > Does it not work with NCQ enabled?
> > > 
> > 
> > That FreeBSD commit prevents using their "hw.ahci.force" tunable on the
> > device, it's used for attaching as AHCI to certain known chips even if
> > they're set in legacy IDE mode.
> > 
> > Does it work to just add the vid/pid to the ahci_devices[] array
> > without a specific attach function? (like PCI_PRODUCT_ASMEDIA_ASM1061_SATA).
> 
> 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

2021-07-25 Thread Stuart Henderson
On 2021/07/25 14:55, Jonathan Matthew wrote:
> On Thu, Jul 22, 2021 at 10:45:17PM -0400, Ashton Fagg wrote:
> > I have two devices here based on the JMicron JMB585 chipset. This diff
> > adds the required pcidev IDs and sets disables native command queuing in
> > the driver. FreeBSD does something similar for this device:
> > 
> > https://github.com/freebsd/freebsd-src/commit/16b766eed443043f4216d50e40ba283e74f992c2
> 
> Can you explain how you came to the conclusion that you'd need to
> disable NCQ?  The FreeBSD commit you link to doesn't appear to do that
> as they're not applying the AHCI_Q_NONCQ flag to these devices.
> Does it not work with NCQ enabled?
> 

That FreeBSD commit prevents using their "hw.ahci.force" tunable on the
device, it's used for attaching as AHCI to certain known chips even if
they're set in legacy IDE mode.

Does it work to just add the vid/pid to the ahci_devices[] array
without a specific attach function? (like PCI_PRODUCT_ASMEDIA_ASM1061_SATA).



Re: dhcpleased: default route with classless static routes option

2021-07-17 Thread Stuart Henderson
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

2021-07-10 Thread Stuart Henderson
On 2021/07/09 17:22, Stuart Henderson wrote:
> On 2021/07/09 16:33, Stuart Henderson wrote:
> > Notes so far:
> > 
> > > +xmmc*)
> > > + dev=${U%.*}
> > > + func=${U#*.}
> > > + M xmmc$U c 101 $(($(($dev*16))+$func)) 660
> > > + ;;
> > 
> > "sh MAKEDEV xmmc" isn't enough, it needs "sh MAKEDEV xmmc.0"
> > 
> > > + ret = EIO;
> > > + syslog(LOG_ERR, "FCC unlock not implemented, yet");
> > 
> > Thus ends my initial experimentation ;)
> > 
> 
> oh; it's just in xmmctl of course! With the horrible python thing, I have
> a working connection.

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

2021-07-09 Thread Stuart Henderson
On 2021/07/09 16:33, Stuart Henderson wrote:
> Notes so far:
> 
> > +xmmc*)
> > +   dev=${U%.*}
> > +   func=${U#*.}
> > +   M xmmc$U c 101 $(($(($dev*16))+$func)) 660
> > +   ;;
> 
> "sh MAKEDEV xmmc" isn't enough, it needs "sh MAKEDEV xmmc.0"
> 
> > +   ret = EIO;
> > +   syslog(LOG_ERR, "FCC unlock not implemented, yet");
> 
> Thus ends my initial experimentation ;)
> 

oh; it's just in xmmctl of course! With the horrible python thing, I have
a working connection.



Re: xmm(4): WIP diff for Intel XMM7360 LTE modem

2021-07-09 Thread Stuart Henderson
Notes so far:

> +xmmc*)
> + dev=${U%.*}
> + func=${U#*.}
> + M xmmc$U c 101 $(($(($dev*16))+$func)) 660
> + ;;

"sh MAKEDEV xmmc" isn't enough, it needs "sh MAKEDEV xmmc.0"

> + ret = EIO;
> + syslog(LOG_ERR, "FCC unlock not implemented, yet");

Thus ends my initial experimentation ;)



Re: systat(1) counter overflow

2021-07-03 Thread Stuart Henderson
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

2021-07-02 Thread Stuart Henderson
On 2021/07/02 13:43, Stuart Henderson wrote:
> Go has its own translated copy of structs from system headers (e.g.
> in golang.org/x/sys/unix/zsysctl_openbsd_*) and these are bundled in
> many ports that use go (even core system libraries are not exempt from
> "vendoring" or having old versions used by software using modules).
> Obviously uvmexp isn't used in all of the software which includes these
> files though.

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

2021-07-02 Thread Stuart Henderson
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).

Go has its own translated copy of structs from system headers (e.g.
in golang.org/x/sys/unix/zsysctl_openbsd_*) and these are bundled in
many ports that use go (even core system libraries are not exempt from
"vendoring" or having old versions used by software using modules).
Obviously uvmexp isn't used in all of the software which includes these
files though.

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

2021-06-25 Thread Stuart Henderson
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:
https://www.kernel.org/doc/html/latest/process/email-clients.html#claws-mail-gui

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

2021-06-23 Thread Stuart Henderson
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

2021-06-20 Thread Stuart Henderson
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 https://man.openbsd.org/snmpd;>snmpd(8) have been tightened.
+You may need to adjust
+https://man.openbsd.org/snmpd.conf.5;>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

2021-06-20 Thread Stuart Henderson
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

2021-06-20 Thread Stuart Henderson
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

2021-06-15 Thread Stuart Henderson
> > > - if the concern is amplification attacks then setting the minlevel to
> > >   authpriv is too high, since you'll silently break logins for users
> > >   that miss the enckey parameter.
> > >   I changed this to always default to seclevel auth.
> > 
> > I do still think enc is the safer default (i.e. "the user has to do
> > something to weaken things") though I don't strongly object to auth
> > instead of enc.
> 
> 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 wrong..

> Then again, I don't get the feeling many people use snmpd at this time
> and maybe it's a good moment to bite the bullet and go for safest
> defaults possible at this time. But if that's the case I would like to
> follow up with a diff to changes the default auth to hmac-sha512,
> because snmp drops trailing bytes of the result and enc to aes instead
> of des.

This is the change that feels most likely to affect existing SNMPv3 users.
Support in management software beyond aes/sha1 is a bit lacking and prone
to incompatibility (I had issues with net-snmp and snmpd using hmac-sha256
though it seems it will work with hmac-sha512..)

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

2021-06-14 Thread Stuart Henderson
On 2021/06/14 19:40, Martijn van Duren wrote:
> On Mon, 2021-06-14 at 12:55 +0100, Stuart Henderson wrote:
> > By default, snmpd responds to the frequently abused community strings
> > "public" and "private".
> > 
> > To prevent this, at present you must either use "seclevel auth" or
> > "seclevel enc" (if you would like to only use SNMPv3), set an explicit
> > string for the read-only community, or set either an explicit string
> > or "disabled" for the read-write community.
> > 
> > I would like to remove the defaults. If somebody really wants to use
> > the strings "public" or "private" they can set them themselves. The
> > internet doesn't need any more unintentional UDP amplifiers than
> > necessary.
> 
> I fully agree.
> > 
> > Additionally if somebody goes to the trouble of configuring SNMPv3,
> > the common use case is to want authentication+encryption; anything
> > wider than that, it's reasonable to expect the user to make it
> > explicit, so I've changed it to "seclevel enc" by default iff an
> > SNMPv3 user is created.
> 
> > This works as expected in the use-cases I've tried. Any concerns/
> > comments/OKs? (I'll write an faq/current.html entry if it goes in).
> > 
> > Note, it's not possible to require auth+enc for SNMPv3 requests while
> > also allowing SNMPv1/2; that isn't new and I haven't changed it.
> > 
> I think that your approach is a nice first stab, but is incomplete.

thanks for looking.

> - if the concern is amplification attacks then setting the minlevel to
>   authpriv is too high, since you'll silently break logins for users
>   that miss the enckey parameter.
>   I changed this to always default to seclevel auth.

I do still think enc is the safer default (i.e. "the user has to do
something to weaken things") though I don't strongly object to auth
instead of enc.

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

2021-06-14 Thread Stuart Henderson
By default, snmpd responds to the frequently abused community strings
"public" and "private".

To prevent this, at present you must either use "seclevel auth" or
"seclevel enc" (if you would like to only use SNMPv3), set an explicit
string for the read-only community, or set either an explicit string
or "disabled" for the read-write community.

I would like to remove the defaults. If somebody really wants to use
the strings "public" or "private" they can set them themselves. The
internet doesn't need any more unintentional UDP amplifiers than
necessary.

Additionally if somebody goes to the trouble of configuring SNMPv3,
the common use case is to want authentication+encryption; anything
wider than that, it's reasonable to expect the user to make it
explicit, so I've changed it to "seclevel enc" by default iff an
SNMPv3 user is created.

This works as expected in the use-cases I've tried. Any concerns/
comments/OKs? (I'll write an faq/current.html entry if it goes in).

Note, it's not possible to require auth+enc for SNMPv3 requests while
also allowing SNMPv1/2; that isn't new and I haven't changed it.

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

2021-06-10 Thread Stuart Henderson
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.
> 
> >  Staat der Nederlanden
> >/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden EV Root CA
> > -  /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G3
> 
> 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:

https://bugzilla.mozilla.org/show_bug.cgi?id=1693217

Validity in NSS was changed from web+email to just email:

https://hg.mozilla.org/projects/nss/rev/720a1118f16b60c218a308949554b2d21681c41f
https://bugzilla.mozilla.org/show_bug.cgi?id=1687822

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"

ihttps://hg.mozilla.org/releases/mozilla-beta/annotate/tip/security/nss/lib/ckfw/builtins/certdata.txt



cert.pem sync

2021-06-10 Thread Stuart Henderson
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 
www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma 
S.A./CN=Chambers of Commerce Root - 2008
-  /C=EU/L=Madrid (see current address at 
www.camerfirma.com/address)/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
 
 Staat der Nederlanden
   /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden EV Root CA
-  /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G3
 
 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 
www.camerfirma.com/address)/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 
www.camerfirma.com/address)/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 
www.camerfirma.com/address)/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: http://policy.camerfirma.com
-
-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

2021-06-05 Thread Stuart Henderson
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 off 0 len 16 E mask 
255.255.255.248 int 1 pri 1 dead 4 dr xxx.xx.xxx.28 bdr xxx.xx.xxx.25 nbrs 
yyy.yy.yyy.11 yyy.yy.yyy.8 [tos 0xc0] [ttl 1] (id 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 off 0 len 16 E mask 
255.255.255.248 int 1 pri 1 dead 4 dr xxx.xx.xxx.28 bdr xxx.xx.xxx.25 nbrs 
yyy.yy.yyy.11 yyy.yy.yyy.8 [tos 0xc0] [ttl 1] (id 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

2021-05-31 Thread Stuart Henderson
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:


https://github.com/reuvenP/src/commit/db909be68a3b03e68787de55d218388f33c4c4c6




Re: [PATCH] [src] sys/dev/usb/usbdevs - add "SHARKOON Technologies GmbH" vendor ID

2021-05-24 Thread Stuart Henderson
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] 
> https://cvsweb.openbsd.org/src/sys/dev/usb/usbdevs.diff?r1=1.698=1.699=date=h

Yes, that one is used in a driver.



Re: bcmintc(4) diff for raspberry pi3

2021-05-22 Thread Stuart Henderson
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.  https://www.OpenBSD.org

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.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 512KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4
cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu1: 512KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4
cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu2: 512KB 64b/line 16-way L2 cache
cpu2: CRC32,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4
cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu3: 512KB 64b/line 16-way L2 cache
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

2021-05-21 Thread Stuart Henderson
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

2021-05-20 Thread Stuart Henderson
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

2021-05-19 Thread Stuart Henderson
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

2021-05-19 Thread Stuart Henderson
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: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
2: https://github.com/the-tcpdump-group/tcpdump/pull/912

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

2021-05-14 Thread Stuart Henderson
On 2021/05/14 21:14, Tobias Heider wrote:
> On Thu, May 13, 2021 at 02:39:37PM +0900, Katsuhiro Ueno wrote:
> > Hi,
> > 
> > I would be happy if iked(8) supports intermediate CAs and sends the
> > entire certificate chain to the clients. The diff attached adds
> > supports for intermediate CAs and multiple CERT payloads to iked(8).
> > 
> > What I would like to do is to use a LetsEncrypt certificate as a
> > server certificate of IKEv2 EAP and establish VPN connections with
> > Windows clients. However, I could not complete it because of the
> > following reasons.
> > * LetsEncrypt server certificate is issued by an intermediate CA
> >   and therefore the certificate of the intermediate CA is needed to
> >   check the validity of the server certificate.
> > * Windows expects the IKEv2 server to send the intermediate CA's
> >   certificate in addition to the server certificate to check the
> >   validity.
> > * On the other hand, iked(8) is not capable of dealing with
> >   certificate chains and sending multiple certificates (multiple
> >   CERT payloads) to the clients.
> > Consequently, Windows fails to verify the certificate and therefore
> > VPN connection cannot be established.
> > 
> > To overcome this, I added an (ad-hoc) support for certificate chain
> > and multiple CERT payloads. The diff attached is the changes that I
> > made. It works fine for me but I am not sure whether or not it works
> > for everyone and everywhere. Tests and comments are greatly
> > appreciated.
> > 
> > Many thanks,
> > Katsuhiro Ueno
> 
> 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

2021-05-13 Thread Stuart Henderson
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 Katsuhiro Ueno  wrote:


Hi,

I would be happy if iked(8) supports intermediate CAs and sends the
entire certificate chain to the clients. The diff attached adds
supports for intermediate CAs and multiple CERT payloads to iked(8).

What I would like to do is to use a LetsEncrypt certificate as a
server certificate of IKEv2 EAP and establish VPN connections with
Windows clients. However, I could not complete it because of the
following reasons.
* LetsEncrypt server certificate is issued by an intermediate CA
 and therefore the certificate of the intermediate CA is needed to
 check the validity of the server certificate.
* Windows expects the IKEv2 server to send the intermediate CA's
 certificate in addition to the server certificate to check the
 validity.
* On the other hand, iked(8) is not capable of dealing with
 certificate chains and sending multiple certificates (multiple
 CERT payloads) to the clients.
Consequently, Windows fails to verify the certificate and therefore
VPN connection cannot be established.

To overcome this, I added an (ad-hoc) support for certificate chain
and multiple CERT payloads. The diff attached is the changes that I
made. It works fine for me but I am not sure whether or not it works
for everyone and everywhere. Tests and comments are greatly
appreciated.

Many thanks,
Katsuhiro Ueno




Re: patch: add support for RTLD_NODELETE

2021-05-10 Thread Stuart Henderson
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

2021-05-07 Thread Stuart Henderson
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

2021-05-05 Thread Stuart Henderson
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
 # 
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
 #
-# 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

2021-05-02 Thread Stuart Henderson
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

2021-04-30 Thread Stuart Henderson
On 2021/04/05 09:34, Scott Cheloha wrote:
> > On Apr 5, 2021, at 09:07, Stuart Henderson  wrote:
> > 
> > I've attached r620-E5_2630v2-2p6c2t.tgz, from Dell PE R620 with E5-2630v2.
> > This is a machine which has "disabling user TSC (skew=XXX)" reported for
> > some cores:
> > 
> > Nov  5 16:08:34 pweb /bsd: cpu11: disabling user TSC (skew=-107)
> > Nov  5 16:08:34 pweb /bsd: cpu13: disabling user TSC (skew=-101)
> 
> 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

2021-04-27 Thread Stuart Henderson
On 2021/04/27 16:23, Raymond E. Pasco wrote:
> On Tue Apr 27, 2021 at 3:40 PM EDT, Stuart Henderson wrote:
> > How does this work with other web servers? For example, I don't see the
> > string X-Forwarded-Proto in nginx or Apache httpd (and the use of other
> > X-Forwarded headers in them are only for adding to requests when running
> > as a proxy itself, or picking up the client IP from headers rather than
> > TCP).
> 
> 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

2021-04-27 Thread Stuart Henderson
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.

How does this work with other web servers? For example, I don't see the
string X-Forwarded-Proto in nginx or Apache httpd (and the use of other
X-Forwarded headers in them are only for adding to requests when running
as a proxy itself, or picking up the client IP from headers rather than
TCP).



Re: enable dt(4)

2021-04-26 Thread Stuart Henderson
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()

2021-04-24 Thread Stuart Henderson
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

2021-04-22 Thread Stuart Henderson
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:
>   https://www.mail-archive.com/tech@openbsd.org/msg62221.html ?

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

2021-04-13 Thread Stuart Henderson
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
https://marc.info/?t=15629383281=1=2
https://marc.info/?l=openbsd-bugs=157758838031146=2 ?

> [1]: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6000
> 
> 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
> In file included from define_test.cxx:16:
> In file included from /usr/include/c++/v1/sstream:173:
> In file included from /usr/include/c++/v1/ostream:140:
> In file included from /usr/include/c++/v1/locale:207:
> /usr/include/c++/v1/__bsd_locale_fallbacks.h:122: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;
> ^
> In file included from define_test.cxx:16:
> In file included from /usr/include/c++/v1/sstream:173:
> In file included from /usr/include/c++/v1/ostream:140:
> In file included from /usr/include/c++/v1/locale:207:
> /usr/include/c++/v1/__bsd_locale_fallbacks.h:122: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

2021-04-12 Thread Stuart Henderson
[this is re: https://marc.info/?l=openbsd-tech=160673147428172=2]

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 https://marc.info/?l=openbsd-tech=149244066604660=2
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

2021-04-06 Thread Stuart Henderson
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

2021-04-06 Thread Stuart Henderson
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 https://jkorpela.fi/shy.html,
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:

https://gitlab.com/muttmua/mutt/-/blob/master/mbyte.c#L528



Re: monotonic time going back by wrong skews

2021-04-06 Thread Stuart Henderson
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

2021-04-05 Thread Stuart Henderson
I've attached r620-E5_2630v2-2p6c2t.tgz, from Dell PE R620 with E5-2630v2.
This is a machine which has "disabling user TSC (skew=XXX)" reported for
some cores:

Nov  5 16:08:34 pweb /bsd: cpu11: disabling user TSC (skew=-107)
Nov  5 16:08:34 pweb /bsd: cpu13: disabling user TSC (skew=-101)

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

2021-03-30 Thread Stuart Henderson
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)

2021-03-28 Thread Stuart Henderson
On 2021/03/28 13:40, Patrick Wildt wrote:
> Am Sun, Mar 28, 2021 at 10:53:53AM +0100 schrieb Stuart Henderson:
> > On 2021/03/25 00:14, Stuart Henderson wrote:
> > > On 2021/03/25 00:30, Patrick Wildt wrote:
> > > > Without having looked at anything, it might be worth looking at the most
> > > > recent mail in this thread:
> > > > 
> > > > 'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'
> > > > 
> > > 
> > > oh, usb runs through all drivers looking for a VID/PID match before
> > > then running through all looking for a class match? I didn't realise
> > > (thought it would try driver-by-driver with first VID/PID then class)
> > > but that does make sense.
> > > 
> > > Updated diff below adding my pid/vid and tweaking some comments. My card
> > > attaches to umb with this. I've only added it commented-out to the manual
> > > for now until I see it actually pass traffic.
> > > 
> > > So this fixes Bryan's, at least improves mine (will look for another
> > > sim / sim-adapter tomorrow), and seems targetted enough to not risk
> > > fallout with existing working devices.
> > > 
> > > I think this makes sense to commit. OK with me if you'd like to commit
> > > it Gerhard (I think it was your diff originally).
> > 
> > So this isn't enough for the Huawei yet but it doesn't make things
> > any worse, and helps for DW5821e.
> > 
> > If Gerhard isn't around, can I commit this bit so I'm not wrangling
> > things which should be separate commits? OK?
> 
> 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 @@ const struct cfattach umb_ca = {
 
 int umb_delay = 4000;
 
-/*
- * Normally, MBIM devices are detected by their interface class and subclass.
- * But for some models that have multiple configurations, it is better to
- * match by vendor and product id so that we can select the desired
- * configuration ourselves, e.g. to override a class-based match to another
- * driver.
- *
- * OTOH, some devices identify themselves as an MBIM device but fail to speak
- * the MBIM protocol.
- */
-struct umb_products {
+struct 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)

2021-03-28 Thread Stuart Henderson
On 2021/03/25 00:14, Stuart Henderson wrote:
> On 2021/03/25 00:30, Patrick Wildt wrote:
> > Without having looked at anything, it might be worth looking at the most
> > recent mail in this thread:
> > 
> > 'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'
> > 
> 
> oh, usb runs through all drivers looking for a VID/PID match before
> then running through all looking for a class match? I didn't realise
> (thought it would try driver-by-driver with first VID/PID then class)
> but that does make sense.
> 
> Updated diff below adding my pid/vid and tweaking some comments. My card
> attaches to umb with this. I've only added it commented-out to the manual
> for now until I see it actually pass traffic.
> 
> So this fixes Bryan's, at least improves mine (will look for another
> sim / sim-adapter tomorrow), and seems targetted enough to not risk
> fallout with existing working devices.
> 
> I think this makes sense to commit. OK with me if you'd like to commit
> it Gerhard (I think it was your diff originally).

So this isn't enough for the Huawei yet but it doesn't make things
any worse, and helps for DW5821e.

If Gerhard isn't around, can I commit this bit so I'm not wrangling
things which should be separate commits? OK?

> 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 @@ const struct cfattach umb_ca = {
>  int umb_delay = 4000;
>  
>  /*
> + * Normally, MBIM devices are detected by their interface class and subclass.
> + * But for some models that have multiple configurations, it is better to
> + * match by vendor and product id so that we can select the desired
> + * configuration ourselves, e.g. to override a class-based match to another
> + * driver.
> + *
> + * OTOH, some devices identify themselves as an MBIM device but fail to speak
> + * the MBIM protocol.
> + */
> +struct umb_products {
> + struct 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

2021-03-25 Thread Stuart Henderson
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
> 



  1   2   3   4   5   6   7   8   9   10   >