Re: relayd and TLS client cert verification
Ashe Connor(a...@kivikakk.ee) on 2018.11.26 05:29:45 +:
> On Fri, Nov 23, 2018 at 04:41:21PM +0100, Sebastian Benoit wrote:
> > > It appears that relayd doesn't support TLS client certificate validation
> > > (in the manner that httpd does with "tls client ca [cafile]"). Would
> > > there be interest in a patch that added such support?
> >
> > yes, a patch to support client certificates would be welcome.
> >
> > /Benno
>
> Wonderful. Here's a first pass at such a patch.
>
> Ashe
Sorry to keep you waiting.
The parse and config bits look good.
And the use of tls* looks ok to me too, but I would like to have someone
more familiar with it to give an ok though.
As for style, please make lines not longer than 80 chars.
> Index: usr.sbin/relayd/config.c
> ===
> RCS file: /home/kivikakk/cvsync/root/src/usr.sbin/relayd/config.c,v
> retrieving revision 1.36
> retrieving revision 1.36.6.1
> diff -u -p -r1.36 -r1.36.6.1
> --- usr.sbin/relayd/config.c 29 Nov 2017 15:24:50 - 1.36
> +++ usr.sbin/relayd/config.c 24 Nov 2018 16:15:37 - 1.36.6.1
> @@ -900,6 +900,15 @@ config_setrelay(struct relayd *env, stru
> rlay->rl_conf.name);
> return (-1);
> }
> + if (rlay->rl_tls_client_ca_fd != -1 &&
> + config_setrelayfd(ps, id, n,
> + rlay->rl_conf.id, RELAY_FD_CLIENTCACERT,
> + rlay->rl_tls_client_ca_fd) == -1) {
> + log_warn("%s: fd passing failed for "
> + "`%s'", __func__,
> + rlay->rl_conf.name);
> + return (-1);
> + }
> /* Prevent fd exhaustion in the parent. */
> if (proc_flush_imsg(ps, id, n) == -1) {
> log_warn("%s: failed to flush "
> @@ -945,6 +954,10 @@ config_setrelay(struct relayd *env, stru
> close(rlay->rl_tls_ca_fd);
> rlay->rl_tls_ca_fd = -1;
> }
> + if (rlay->rl_tls_client_ca_fd != -1) {
> + close(rlay->rl_tls_client_ca_fd);
> + rlay->rl_tls_client_ca_fd = -1;
> + }
>
> return (0);
> }
> @@ -968,6 +981,7 @@ config_getrelay(struct relayd *env, stru
> rlay->rl_tls_cert_fd = -1;
> rlay->rl_tls_ca_fd = -1;
> rlay->rl_tls_cacert_fd = -1;
> + rlay->rl_tls_client_ca_fd = -1;
>
> if (ps->ps_what[privsep_process] & CONFIG_PROTOS) {
> if (rlay->rl_conf.proto == EMPTY_ID)
> @@ -1084,6 +1098,9 @@ config_getrelayfd(struct relayd *env, st
> break;
> case RELAY_FD_CAFILE:
> rlay->rl_tls_cacert_fd = imsg->fd;
> + break;
> + case RELAY_FD_CLIENTCACERT:
> + rlay->rl_tls_client_ca_fd = imsg->fd;
> break;
> }
>
> Index: usr.sbin/relayd/parse.y
> ===
> RCS file: /home/kivikakk/cvsync/root/src/usr.sbin/relayd/parse.y,v
> retrieving revision 1.230
> retrieving revision 1.230.2.2
> diff -u -p -r1.230 -r1.230.2.2
> --- usr.sbin/relayd/parse.y 1 Nov 2018 00:18:44 - 1.230
> +++ usr.sbin/relayd/parse.y 24 Nov 2018 16:15:37 - 1.230.2.2
> @@ -175,7 +175,7 @@ typedef struct {
> %token SNMP SOCKET SPLICE SSL STICKYADDR STYLE TABLE TAG TAGGED TCP
> TIMEOUT TLS
> %token TO ROUTER RTLABEL TRANSPARENT TRAP UPDATES URL VIRTUAL WITH TTL
> RTABLE
> %token MATCH PARAMS RANDOM LEASTSTATES SRCHASH KEY CERTIFICATE
> PASSWORD ECDHE
> -%token EDH TICKETS CONNECTION CONNECTIONS ERRORS STATE CHANGES CHECKS
> +%token EDH TICKETS CONNECTION CONNECTIONS ERRORS STATE CHANGES CHECKS
> CLIENT
> %token STRING
> %token NUMBER
> %type hostname interface table value optstring
> @@ -1246,6 +1246,16 @@ tlsflags : SESSION TICKETS { proto->tick
> }
> free($3);
> }
> + | CLIENT CA STRING {
> + if (strlcpy(proto->tlsclientca, $3,
> + sizeof(proto->tlsclientca)) >=
> + sizeof(proto->tlsclientca)) {
> + yyerror("tlsclientca truncated");
> + free($3);
> + YYERROR;
> + }
> + free($3);
> + }
> | NO flag { proto->tlsflags &= ~($2); }
> | flag { proto->tlsflags |= $1; }
> ;
> @@ -1687,6 +1697,7 @@ relay : RELAY STRING {
>
Re: make build as root fails when SUDO=doas
On Wed, Dec 12, 2018 at 11:12:17AM +0100, Alexander Bluhm wrote:
> On Tue, Dec 11, 2018 at 11:00:30PM +0100, Marc Espie wrote:
> > Ah, so actually just
> > rm -f ${SUDO_CLEAN}
> >
> > should be fine ?
>
> Regress jumps from root to non-root in a very inconsistent way. It
> could be improved, but that would be a lot of work. The result
> will not be perfect as tests have very different needs for permissions.
> So I would recommend to leave it as it is unless someone volunteers
> to refactor all the tests.
>
> If a test creates a file as root with an ugly ${SUDO} hack, it
> should use the same hack to clean it. Then the test is self
> contained. Care should be taken that the make clean hack does not
> affect the make build.
>
> So I like espie@'s suggestion to try rm first without ${SUDO} for
> people running make build, and then with ${SUDO} for people who
> have left overs from testing.
>
> bluhm
Well, apart from the bike-shedding, it seems like the most correct
short-term solution.
So I will commit it tomorrow, unless someone has an actual better idea.
Re: pcap_dispatch() returning zero
ping
On Dec 08 13:56:09, h...@stare.cz wrote:
> The return value of pcap_dispatch() is described in pcap.3 as follows:
>
> The number of packets read is returned.
> Zero is returned when EOF is reached in a savefile.
> A return of -1 indicates an error in which case ...
>
> It will also return zero on the last short read (as "EOF is reached").
> So if you read the packets in chunks of 100, like
>
> while ((r = pcap_dispatch(src, 100, callback, NULL)) > 0) {
> /* ... */
> }
> if (r == 0) {
> /* EOF */
> } else if (r == -1) {
> /* ERROR */
> }
>
> and the file contains 120 packets, you will have
> r == 100 the first time (reading 100 packets) and
> r == 0 the second time (reading 20 packets).
>
> It seems there is no way for the caller to know
> how many packets were actually there in the last short read
> besides counting the packets himself in the callback().
>
> Is that intended? It seems more natural, and less surprising,
> to have it return the actual number of packets. That would make
> the sequence above 100, then 20, then 0 (like read(2) does).
>
> Anyway, should this be explicitly mentioned in the manpage?
>
> Jan
>
>
> Index: pcap.3
> ===
> RCS file: /cvs/src/lib/libpcap/pcap.3,v
> retrieving revision 1.48
> diff -u -p -r1.48 pcap.3
> --- pcap.33 Jun 2018 10:45:15 - 1.48
> +++ pcap.38 Dec 2018 12:53:59 -
> @@ -345,7 +345,11 @@ and a
> .Fa u_char
> pointer to the packet data.
> The number of packets read is returned.
> -Zero is returned when EOF is reached in a savefile.
> +Zero is returned when EOF is reached in a savefile;
> +this includes a short read near the end of savefile,
> +when less than
> +.Fa cnt
> +packets are available.
> A return of \-1 indicates an error in which case
> .Fn pcap_perror
> or
>
Re: request for testing: patch for boot loader out of mem
Two more tests on the same machine: 1) 320Gb disk, it works: OpenBSD 6.4-current (GENERIC.MP) #1: Thu Dec 13 03:10:57 CET 2018 sickn...@openbsd.sick-net:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2130313216 (2031MB) avail mem = 2056515584 (1961MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9f400 (48 entries) bios0: vendor American Megatrends Inc. version "080015" date 06/02/2009 bios0: ECS GF8100VM-M5 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET INFO NVHD SSDT acpi0: wakeup devices SMB0(S4) USB0(S4) USB2(S3) US15(S4) US12(S3) NMAC(S5) P0P1(S4) HDAC(S4) MXR0(S4) BR11(S4) BR12(S4) BR13(S4) BR14(S4) BR15(S4) BR16(S4) BR17(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) II X2 250 Processor, 3000.52 MHz, 10-06-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) II X2 250 Processor, 3000.02 MHz, 10-06-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 2500 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (IXVE) acpiprt3 at acpi0: bus 2 (MXR0) acpiprt4 at acpi0: bus -1 (BR11) acpiprt5 at acpi0: bus 3 (BR12) acpiprt6 at acpi0: bus 4 (BR13) acpiprt7 at acpi0: bus -1 (BR14) acpiprt8 at acpi0: bus -1 (BR15) acpiprt9 at acpi0: bus -1 (BR16) acpiprt10 at acpi0: bus -1 (BR17) acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS acpitz0 at acpi0: critical temperature is 110 degC acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 "*pnp0c14" at acpi0 not configured acpibtn0 at acpi0: PWRB cpu0: 3000 MHz: speeds: 3000 2300 1800 800 MHz pci0 at mainbus0 bus 0 "NVIDIA MCP77 Memory" rev 0xa2 at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 1 function 0 "NVIDIA MCP77 ISA" rev 0xa2 nviic0 at pci0 dev 1 function 1 "NVIDIA MCP77 SMBus" rev 0xa1 iic0 at nviic0 spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-5300CL5 spdmem1 at iic0 addr 0x51: 1GB DDR2 SDRAM non-parity PC2-5300CL5 iic1 at nviic0 "NVIDIA MCP77 Memory" rev 0xa1 at pci0 dev 1 function 2 not configured "NVIDIA MCP77 Co-processor" rev 0xa2 at pci0 dev 1 function 3 not configured "NVIDIA MCP77 Memory" rev 0xa1 at pci0 dev 1 function 4 not configured ohci0 at pci0 dev 2 function 0 "NVIDIA MCP77 USB" rev 0xa1: apic 2 int 15, version 1.0, legacy support ehci0 at pci0 dev 2 function 1 "NVIDIA MCP77 USB" rev 0xa1: apic 2 int 10 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 4 function 0 "NVIDIA MCP77 USB" rev 0xa1: apic 2 int 10, version 1.0, legacy support ehci1 at pci0 dev 4 function 1 "NVIDIA MCP77 USB" rev 0xa1: apic 2 int 11 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1 pciide0 at pci0 dev 6 function 0 "NVIDIA MCP77 IDE" rev 0xa1: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 ignored (disabled) azalia0 at pci0 dev 7 function 0 "NVIDIA MCP77 HD Audio" rev 0xa1: apic 2 int 15 azalia0: codecs: VIA/0xe721 audio0 at azalia0 ppb0 at pci0 dev 8 function 0 "NVIDIA MCP77 PCI" rev 0xa1 pci1 at ppb0 bus 1 ahci0 at pci0 dev 9 function 0 "NVIDIA MCP77 AHCI" rev 0xa2: apic 2 int 9, AHCI 1.2 ahci0: port 0: 3.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed t10.ATA_MAXTOR_STM3320820AS_5QF
Re: make build as root fails when SUDO=doas
Marc Espie wrote:
> Well, apart from the bike-shedding, it seems like the most correct
> short-term solution.
>
> So I will commit it tomorrow, unless someone has an actual better idea.
Nobody answered if SUDO_CLEAN is actualy set. I checked. It's not.
Index: Makefile
===
RCS file: /cvs/src/regress/usr.bin/ssh/Makefile,v
retrieving revision 1.98
diff -u -p -r1.98 Makefile
--- Makefile22 Nov 2018 08:48:32 - 1.98
+++ Makefile14 Dec 2018 20:56:11 -
@@ -209,7 +209,6 @@ c-${s}:
clean: ${CLEAN_SUBDIR}
rm -f ${CLEANFILES}
- test -z "${SUDO}" || ${SUDO} rm -f ${SUDO_CLEAN}
rm -rf .putty
.include
Re: make build as root fails when SUDO=doas
On Fri, Dec 14, 2018 at 03:57:12PM -0500, Ted Unangst wrote:
> Marc Espie wrote:
> > Well, apart from the bike-shedding, it seems like the most correct
> > short-term solution.
> >
> > So I will commit it tomorrow, unless someone has an actual better idea.
>
> Nobody answered if SUDO_CLEAN is actualy set. I checked. It's not.
>
> Index: Makefile
> ===
> RCS file: /cvs/src/regress/usr.bin/ssh/Makefile,v
> retrieving revision 1.98
> diff -u -p -r1.98 Makefile
> --- Makefile 22 Nov 2018 08:48:32 - 1.98
> +++ Makefile 14 Dec 2018 20:56:11 -
> @@ -209,7 +209,6 @@ c-${s}:
>
> clean: ${CLEAN_SUBDIR}
> rm -f ${CLEANFILES}
> - test -z "${SUDO}" || ${SUDO} rm -f ${SUDO_CLEAN}
> rm -rf .putty
>
> .include
Oh, I had a slightly older version.
So, yep, it was just dtucker@ half-committing some clean-up.
Okay to finish fixing it. :)
Re: [PATCH] Gemini Lake SoC pcidevs
On 12/13/18, Heppler, J. Scott wrote: > I have an HP Stream 14 with an n4000 Gemini Lake mobile processor. > The amd64_current does not find the eMMC storage > Would it be of value to the project to apply the patch, generate an > install image using release(8), test and submit the dmesg? dmesg is welcome. I think a kernel with SDMMC_DEBUG enabled would be more helpful to find out what is failing with the eMMC chip.
Re: [PATCH] Gemini Lake SoC pcidevs
On Fri, Dec 14, 2018 at 10:34:51PM -0500, James Hastings wrote: > On 12/13/18, Heppler, J. Scott wrote: > > I have an HP Stream 14 with an n4000 Gemini Lake mobile processor. > > The amd64_current does not find the eMMC storage > > Would it be of value to the project to apply the patch, generate an > > install image using release(8), test and submit the dmesg? > > dmesg is welcome. > I think a kernel with SDMMC_DEBUG enabled would be more helpful > to find out what is failing with the eMMC chip. > For acpi attached sdhc the contents of /var/db/acpi would be more helpful. Most likely someone needs to write another gpio driver along the lines of chvgpio(4) and bytgpio(4) for INT3453 due to gpio signalled interrupts.
