Re: OpenBSD on AMD Ryzen7 2700 Asrock B450 chipset
AMD Ryzen product errata https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf On 11/2/2018 11:03 AM, Denis wrote: > OpenBSD6.4amd64 first install on latest AMD Ryzen7 2700 +Asrock B450 > chipset based mainboard. > > Hardware is relatively new. Can test any compatibility issues/fixes on it. > > I have an issue during installation from USB2 flash connected to USB3 > port of the mainboard. Installation works smoothly once flashdrive > connected to USB2 controller. > > .. > Installing base65.tgz 66% > mass0: Invalid CSW: sig 0x43425355 should be 0x53425355 > tp: Reading from file: Input/output error > gzip: stdin: Input/output error > tar: End of archive volume 1 reached > > There are a lot of "unconfigured" hardware is present in dmesg: > > OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > real mem = 34271694848 (32684MB) > avail mem = 33229246464 (31689MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe68e0 (23 entries) > bios0: vendor American Megatrends Inc. version "P1.10" date 06/19/2018 > bios0: ASRock B450 Gaming-ITX/ac > acpi0 at bios0: rev 2 > acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG > AAFT HPET SSDT UEFI IVRS SSDT SSDT WSMT > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 7 2700 Eight-Core Processor, 3194.62 MHz, 17-08-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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully > associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully > associative > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > ioapic0 at mainbus0: apid 17 pa 0xfec0, version 21, 24 pins, can't remap > ioapic1 at mainbus0: apid 18 pa 0xfec01000, version 21, 32 pins, can't remap > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 1 (GPP0) > acpiprt2 at acpi0: bus -1 (GPP1) > acpiprt3 at acpi0: bus -1 (GPP3) > acpiprt4 at acpi0: bus -1 (GPP4) > acpiprt5 at acpi0: bus -1 (GPP5) > acpiprt6 at acpi0: bus -1 (GPP6) > acpiprt7 at acpi0: bus -1 (GPP7) > acpiprt8 at acpi0: bus 38 (GPP8) > acpiprt9 at acpi0: bus -1 (GPP9) > acpiprt10 at acpi0: bus -1 (GPPA) > acpiprt11 at acpi0: bus -1 (GPPB) > acpiprt12 at acpi0: bus -1 (GPPC) > acpiprt13 at acpi0: bus -1 (GPPD) > acpiprt14 at acpi0: bus -1 (GPPE) > acpiprt15 at acpi0: bus -1 (GPPF) > acpiprt16 at acpi0: bus 42 (GP17) > acpiprt17 at acpi0: bus 43 (GP18) > acpiprt18 at acpi0: bus 3 (GPP2) > acpicpu at acpi0 not configured > "PNP0B00" at acpi0 not configured > "PNP0C0C" at acpi0 not configured > "AMDI0030" at acpi0 not configured > "AMDIF030" at acpi0 not configured > "PNP0C14" at acpi0 not configured > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "AMD AMD64 17h Root Complex" rev 0x00 > "AMD AMD64 17h IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured > pchb1 at pci0 dev 1 function 0 "AMD AMD64 17h PCIE" rev 0x00 > ppb0 at pci0 dev 1 function 1 "AMD AMD64 17h PCIE" rev 0x00: msi > pci1 at ppb0 bus 1 > nvme0 at pci1 dev 0 function 0 "Samsung SM981/PM981 NVMe" rev 0x00: msi, > NVMe 1.2 > nvme0: PM981 NVMe Samsung 1024GB > scsibus0 at nvme0: 1 targets > sd0 at scsibus0 targ 0 lun 0: SCSI4 0/direct > fixed > sd0: 976762MB, 512 bytes/sector, 2000409264 sectors > ppb1 at pci0 dev 1 function 3 "AMD AMD64 17h PCIE" rev 0x00: msi > pci2 at ppb1 bus 3 > xhci0 at pci2 dev 0 function 0 vendor "AMD", unknown product 0x43d5 rev > 0x01: msi, xHCI 1.16 > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev > 3.00/1.00 addr 1 > ahci0 at pci2 dev 0 function 1 vendor "AMD", unknown product 0x43c8 rev > 0x01: msi, AHCI 1.3.1 > scsibus1 at ahci0: 32 targets > ppb2 at pci2 dev 0 function 2 vendor "AMD", unknown product 0x43c6 rev 0x01 > pci3 at ppb2 bus 29 > ppb3 at pci3 dev 0 function 0
unveil dhclient (privileged process)
Hi,
dhclient(8)'s privileged process cannot be pledged yet due to some route
related sysctl(2)'s, but it seems it only needs to access two files. One is
/etc/resolv.conf with write/create permissions and saved_argv[0] (usually
/sbin/dhclient) with execute since we may receive a SIGHUP and it will need to
re-exec itself. We could go further and keep /etc/resolv.conf veiled if we
superseed both domain-name and domain-name-servers in the config file, but it
seems a bit overkill, and with the simple diff below I didn't have any
problems.
Comments? OK? Cluebat stick?
Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.581
diff -u -p -u -r1.581 dhclient.c
--- dhclient.c 4 Nov 2018 19:10:34 - 1.581
+++ dhclient.c 5 Nov 2018 12:02:51 -
@@ -2234,6 +2234,13 @@ fork_privchld(struct interface_info *ifi
if ((routefd = socket(AF_ROUTE, SOCK_RAW, 0)) == -1)
fatal("socket(AF_ROUTE, SOCK_RAW)");
+ if (unveil("/etc/resolv.conf", "wc") == -1)
+ fatal("unveil");
+ if (unveil(saved_argv[0], "x") == -1)
+ fatal("unveil");
+ if (unveil(NULL, NULL) == -1)
+ fatal("unveil");
+
while (quit == 0) {
pfd[0].fd = priv_ibuf->fd;
pfd[0].events = POLLIN;
Re: tcsh -- build without sbrk
On Mon, Nov 05, 2018 at 08:43:56AM -0500, Daniel Dickman wrote: > > > > On Nov 5, 2018, at 8:30 AM, Marc Espie wrote: > > > > Or we could just finally remove brk and sbrk from the libc ? > > > > > > you won’t get very far. they are still needed in base (gcc, clang, mkhybrid). The big question is, are they still *needed* or do those tools just *use them if they find them*.
Re: tcsh -- build without sbrk
On Mon, Nov 05, 2018 at 09:15:28AM -0500, Daniel Dickman wrote: >gcc uses them for precompiled headers (PCH) which is a local diff added >by kurt@ in 2009. its likely nothing in base uses PCH but i don't know >what in ports needs this: This has always been a mess. I suspect it's not really important these days because pch only make sense for large C++ codebases, which are definitely not going to be happy with the gcc from base anyway. There is also some snippet using sbrk to avoid malloc in gmon.c. That might be more of an issue... >[3]https://github.com/openbsd/src/commit/cfee5d1 > >choices there would be to disable PCH support or maybe there's a >different way to reimplement without brk/sbrk. >clang looks like they have a HAVE_SBRK ifdef or something like that. so >usage can likely be turned off but i don't know this codebase that well >so that's just an assumption. Yep, I'll have to look.
Re: tcsh -- build without sbrk
On Mon, Nov 05, 2018 at 11:31:53AM +, Stuart Henderson wrote: > On 2018/11/04 10:29, Daniel Dickman wrote: > > The below overrides the cached autoconf value that says that we have > > sbrk(2) on our system and pretends like we don't have it. > > > > With this we can build tcsh without a need for sbrk(2). > > > > ok? > > Should we just remove or change the entry in infrastructure/db/config.site > instead? > > This is where it shows up. > It looks worthwhile to try. Or we could just finally remove brk and sbrk from the libc ? Now that emacs21 is dead, is there any need for those functions ? Archeology shows them in POSIX 1997, marked as "legacy" at that point. I don't see them even mentioned in POSIX 2017
Re: tcsh -- build without sbrk
>> On Nov 5, 2018, at 8:30 AM, Marc Espie wrote: >> >> Or we could just finally remove brk and sbrk from the libc ? >> >> > >you won???t get very far. they are still needed in base (gcc, clang, mkhybrid). The goal isn't to remove it. Rather, we want to neuter one semantic component, such that uvm can become simpler. A similar thing happened to vfork ages ago.
Re: tcsh -- build without sbrk
> On Nov 5, 2018, at 8:47 AM, Marc Espie wrote: > >> On Mon, Nov 05, 2018 at 08:43:56AM -0500, Daniel Dickman wrote: >> >> >>> On Nov 5, 2018, at 8:30 AM, Marc Espie wrote: >>> >>> Or we could just finally remove brk and sbrk from the libc ? >>> >>> >> >> you won’t get very far. they are still needed in base (gcc, clang, mkhybrid). > > The big question is, are they still *needed* or do those tools just *use them > if they find them*. mkhybrid is an easy diff. gcc uses them for precompiled headers (PCH) which is a local diff added by kurt@ in 2009. its likely nothing in base uses PCH but i don’t know what in ports needs this: https://github.com/openbsd/src/commit/cfee5d1 choices there would be to disable PCH support or maybe there’s a different way to reimplement without brk/sbrk. clang looks like they have a HAVE_SBRK ifdef or something like that. so usage can likely be turned off but i don’t know this codebase that well so that’s just an assumption.
Re: unveil dhclient (privileged process)
As per krw@ I probably should add a #define to /sbin/dhclient and use
that instead of saved_argv and you wouldn't have that error but you'd still
have to make install.
On 22:53 Mon 05 Nov , Remi Locherer wrote:
> On Mon, Nov 05, 2018 at 12:30:08PM +, Ricardo Mestre wrote:
> > Hi,
> >
> > dhclient(8)'s privileged process cannot be pledged yet due to some route
> > related sysctl(2)'s, but it seems it only needs to access two files. One is
> > /etc/resolv.conf with write/create permissions and saved_argv[0] (usually
> > /sbin/dhclient) with execute since we may receive a SIGHUP and it will need
> > to
> > re-exec itself. We could go further and keep /etc/resolv.conf veiled if we
> > superseed both domain-name and domain-name-servers in the config file, but
> > it
> > seems a bit overkill, and with the simple diff below I didn't have any
> > problems.
> >
> > Comments? OK? Cluebat stick?
>
> First I thougt the diff does not work:
>
> typhoon ..n/dhclient$ doas obj/dhclient -d iwm0
> fatal in iwm0 [priv]: unveil: No such file or directory
> iwm0: DHCPREQUEST to 255.255.255.255
> iwm0: unpriv_ibuf: ERR|HUP|NVAL
>
>
> It does not work because "obj" is a symlink here. When called without
> a symlink in the path it works as expected. The error message is a bit
> awkward.
>
> >
> > Index: dhclient.c
> > ===
> > RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
> > retrieving revision 1.581
> > diff -u -p -u -r1.581 dhclient.c
> > --- dhclient.c 4 Nov 2018 19:10:34 - 1.581
> > +++ dhclient.c 5 Nov 2018 12:02:51 -
> > @@ -2234,6 +2234,13 @@ fork_privchld(struct interface_info *ifi
> > if ((routefd = socket(AF_ROUTE, SOCK_RAW, 0)) == -1)
> > fatal("socket(AF_ROUTE, SOCK_RAW)");
> >
> > + if (unveil("/etc/resolv.conf", "wc") == -1)
> > + fatal("unveil");
> > + if (unveil(saved_argv[0], "x") == -1)
> > + fatal("unveil");
> > + if (unveil(NULL, NULL) == -1)
> > + fatal("unveil");
> > +
> > while (quit == 0) {
> > pfd[0].fd = priv_ibuf->fd;
> > pfd[0].events = POLLIN;
> >
>
Re: bgpd: use rtable bgpd was started in
On Mon, Nov 05, 2018 at 08:49:08PM +0100, Denis Fondras wrote:
> I wanted to run bgpd in a specific rdomain.
> First routes could not be selected then I patched rde.c and routes magically
> appeared in the right routing table.
>
> Is this as simple as the provided diff or am I overlooking something ?
You are overlooking something. Both RIBs are F_RIB_NOFIB |
F_RIB_NOEVALUATE, so the routes are not evaluated, selected or sent to the
parent. This should be a no-op, so I think something else happened to make
the routes appear.
> Denis
>
> Index: rde.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.445
> diff -u -p -r1.445 rde.c
> --- rde.c 4 Nov 2018 12:34:54 - 1.445
> +++ rde.c 5 Nov 2018 14:00:01 -
> @@ -217,8 +217,8 @@ rde_main(int debug, int verbose)
> peer_init(peerhashsize);
>
> /* make sure the default RIBs are setup */
> - rib_new("Adj-RIB-In", 0, F_RIB_NOFIB | F_RIB_NOEVALUATE);
> - rib_new("Adj-RIB-Out", 0, F_RIB_NOFIB | F_RIB_NOEVALUATE);
> + rib_new("Adj-RIB-In", getrtable(), F_RIB_NOFIB | F_RIB_NOEVALUATE);
> + rib_new("Adj-RIB-Out", getrtable(), F_RIB_NOFIB | F_RIB_NOEVALUATE);
>
> out_rules = calloc(1, sizeof(struct filter_head));
> if (out_rules == NULL)
>
--
:wq Claudio
Re: unveil dhclient (privileged process)
On Mon, Nov 05, 2018 at 12:30:08PM +, Ricardo Mestre wrote:
> Hi,
>
> dhclient(8)'s privileged process cannot be pledged yet due to some route
> related sysctl(2)'s, but it seems it only needs to access two files. One is
> /etc/resolv.conf with write/create permissions and saved_argv[0] (usually
> /sbin/dhclient) with execute since we may receive a SIGHUP and it will need to
> re-exec itself. We could go further and keep /etc/resolv.conf veiled if we
> superseed both domain-name and domain-name-servers in the config file, but it
> seems a bit overkill, and with the simple diff below I didn't have any
> problems.
>
> Comments? OK? Cluebat stick?
First I thougt the diff does not work:
typhoon ..n/dhclient$ doas obj/dhclient -d iwm0
fatal in iwm0 [priv]: unveil: No such file or directory
iwm0: DHCPREQUEST to 255.255.255.255
iwm0: unpriv_ibuf: ERR|HUP|NVAL
It does not work because "obj" is a symlink here. When called without
a symlink in the path it works as expected. The error message is a bit
awkward.
>
> Index: dhclient.c
> ===
> RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
> retrieving revision 1.581
> diff -u -p -u -r1.581 dhclient.c
> --- dhclient.c4 Nov 2018 19:10:34 - 1.581
> +++ dhclient.c5 Nov 2018 12:02:51 -
> @@ -2234,6 +2234,13 @@ fork_privchld(struct interface_info *ifi
> if ((routefd = socket(AF_ROUTE, SOCK_RAW, 0)) == -1)
> fatal("socket(AF_ROUTE, SOCK_RAW)");
>
> + if (unveil("/etc/resolv.conf", "wc") == -1)
> + fatal("unveil");
> + if (unveil(saved_argv[0], "x") == -1)
> + fatal("unveil");
> + if (unveil(NULL, NULL) == -1)
> + fatal("unveil");
> +
> while (quit == 0) {
> pfd[0].fd = priv_ibuf->fd;
> pfd[0].events = POLLIN;
>
bgpd: use rtable bgpd was started in
I wanted to run bgpd in a specific rdomain.
First routes could not be selected then I patched rde.c and routes magically
appeared in the right routing table.
Is this as simple as the provided diff or am I overlooking something ?
Denis
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.445
diff -u -p -r1.445 rde.c
--- rde.c 4 Nov 2018 12:34:54 - 1.445
+++ rde.c 5 Nov 2018 14:00:01 -
@@ -217,8 +217,8 @@ rde_main(int debug, int verbose)
peer_init(peerhashsize);
/* make sure the default RIBs are setup */
- rib_new("Adj-RIB-In", 0, F_RIB_NOFIB | F_RIB_NOEVALUATE);
- rib_new("Adj-RIB-Out", 0, F_RIB_NOFIB | F_RIB_NOEVALUATE);
+ rib_new("Adj-RIB-In", getrtable(), F_RIB_NOFIB | F_RIB_NOEVALUATE);
+ rib_new("Adj-RIB-Out", getrtable(), F_RIB_NOFIB | F_RIB_NOEVALUATE);
out_rules = calloc(1, sizeof(struct filter_head));
if (out_rules == NULL)
Recent "elliptic curve" -> "supported groups" change in libssl
Hi, As someone with interests in kernel development and a lot of spare time, I want to work on OS patches. I just installed OpenBSD 6.4 in a clean development VM and started building the -current branch from CVS to get up to date with the latest commits. I noticed that the build was failing with an error in usr.bin/openssl/c_sb.c line 703 caused by a missing #define. I traced the cause back to this commit earlier today updating libssl's TLS support for RFC 7919 compliance: https://github.com/openbsd/src/commit/2cdb2b1d3f3f9272c0a1acf5fe1f067f3db09e29#diff-e050d3ba43ebfa12f82b36086dca3ea3 It renames the Elliptic Curves extensions to Supported Groups, including the TLSEXT_TYPE_elliptic_curves #define which became TLSEXT_TYPE_supported_groups. Simple, right? I updated the #define and extname to match the new supported groups name and continued building. Everything was fine and I was able to access HTTPS web pages and retrieve packages. However, when I went to create the diff afterward, I got an error from CVS... -- ssh_dispatch_run_fatal: Connection to 129.128.197.20 port 22: invalid elliptic curve value -- Uh-oh. I'm going to assume that this is connected to the elliptic curve diff. I tried a couple different anoncvs mirrors with no effect. Just wondering if this was a known problem with -current or something hokey going on with my system. Katherine
Re: Recent "elliptic curve" -> "supported groups" change in libssl
On Tuesday 06 November 2018 00:39:11 Luigi30 wrote: > Hi, > > As someone with interests in kernel development and a lot of spare > time, I want to work on OS patches. I just installed OpenBSD 6.4 in a > clean development VM and started building the -current branch from CVS > to get up to date with the latest commits. > > I noticed that the build was failing with an error in > usr.bin/openssl/c_sb.c line 703 caused by a missing #define. I traced > the cause back to this commit earlier today updating libssl's TLS > support for RFC 7919 compliance: > https://github.com/openbsd/src/commit/2cdb2b1d3f3f9272c0a1acf5fe1f067f3db09e > 29#diff-e050d3ba43ebfa12f82b36086dca3ea3 > > It renames the Elliptic Curves extensions to Supported Groups, > including the TLSEXT_TYPE_elliptic_curves #define which became > TLSEXT_TYPE_supported_groups. Simple, right? I updated the #define and > extname to match the new supported groups name and continued building. > Everything was fine and I was able to access HTTPS web pages and > retrieve packages. Thanks - fixed. > However, when I went to create the diff afterward, I got an error from > CVS... > > -- > ssh_dispatch_run_fatal: Connection to 129.128.197.20 port 22: invalid > elliptic curve value > -- > > Uh-oh. I'm going to assume that this is connected to the elliptic > curve diff. I tried a couple different anoncvs mirrors with no effect. > Just wondering if this was a known problem with -current or something > hokey going on with my system. You've probably run into another bug that was introduced and reverted. Please update and try again.
Re: unveil dhclient (privileged process)
something like the below? I added a new define for /etc/resolv.conf since it's
now used on 2 different places and hardcoded the executable path to avoid
strange errors if running from a symlink directory as pointed out by remi@
Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.581
diff -u -p -u -r1.581 dhclient.c
--- dhclient.c 4 Nov 2018 19:10:34 - 1.581
+++ dhclient.c 6 Nov 2018 07:34:55 -
@@ -2234,6 +2234,13 @@ fork_privchld(struct interface_info *ifi
if ((routefd = socket(AF_ROUTE, SOCK_RAW, 0)) == -1)
fatal("socket(AF_ROUTE, SOCK_RAW)");
+ if (unveil(_PATH_RESOLV_CONF, "wc") == -1)
+ fatal("unveil");
+ if (unveil("/sbin/dhclient", "x") == -1)
+ fatal("unveil");
+ if (unveil(NULL, NULL) == -1)
+ fatal("unveil");
+
while (quit == 0) {
pfd[0].fd = priv_ibuf->fd;
pfd[0].events = POLLIN;
Index: dhcpd.h
===
RCS file: /cvs/src/sbin/dhclient/dhcpd.h,v
retrieving revision 1.257
diff -u -p -u -r1.257 dhcpd.h
--- dhcpd.h 2 Nov 2018 16:15:55 - 1.257
+++ dhcpd.h 6 Nov 2018 07:34:55 -
@@ -153,6 +153,7 @@ struct interface_info {
};
#define_PATH_DHCLIENT_CONF "/etc/dhclient.conf"
+#define_PATH_RESOLV_CONF "/etc/resolv.conf"
#define_PATH_LEASE_DB "/var/db/dhclient.leases"
/* options.c */
Index: kroute.c
===
RCS file: /cvs/src/sbin/dhclient/kroute.c,v
retrieving revision 1.156
diff -u -p -u -r1.156 kroute.c
--- kroute.c13 Jun 2018 01:37:54 - 1.156
+++ kroute.c6 Nov 2018 07:34:55 -
@@ -594,7 +594,6 @@ write_resolv_conf(void)
void
priv_write_resolv_conf(char *contents)
{
- const char *path = "/etc/resolv.conf";
ssize_t n;
size_t sz;
int fd;
@@ -602,21 +601,21 @@ priv_write_resolv_conf(char *contents)
if (contents == NULL)
return;
- fd = open(path, O_WRONLY | O_CREAT | O_TRUNC,
+ fd = open(_PATH_RESOLV_CONF, O_WRONLY | O_CREAT | O_TRUNC,
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
if (fd == -1) {
- log_warn("%s: open(%s)", log_procname, path);
+ log_warn("%s: open(%s)", log_procname, _PATH_RESOLV_CONF);
return;
}
sz = strlen(contents);
n = write(fd, contents, sz);
if (n == -1)
- log_warn("%s: write(%s)", log_procname, path);
+ log_warn("%s: write(%s)", log_procname, _PATH_RESOLV_CONF);
else if ((size_t)n < sz)
log_warnx("%s: write(%s): %zd of %zu bytes", log_procname,
- path, n, sz);
+ _PATH_RESOLV_CONF, n, sz);
close(fd);
}
Re: ldap(1) add SAFE-INIT-CHAR
On Tue, Nov 06, 2018 at 08:21:57AM +0100, Martijn van Duren wrote:
> ping
>
> On 10/24/18 10:27 AM, Martijn van Duren wrote:
> > In my previous ldap mail I proclaimed that we should encode whitespace.
> > Reading rfc2849 a bit further, encoding a string with leading space is
> > mandatory by SAFE-INIT-CHAR. This is needed because of the definition
> > of value-spec, which allows additional space, colon, and less-than
> > after the colon separating the AttributeDescription.
> >
> > The code below adds these definitions. I also changed the outlen
> > calculation because it at least fails b64_ntop on inlen == 1.
> >
> > OK?
See inline.
> > martijn@
> >
> > Index: ldapclient.c
> > ===
> > RCS file: /cvs/src/usr.bin/ldap/ldapclient.c,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 ldapclient.c
> > --- ldapclient.c23 Oct 2018 08:28:34 - 1.5
> > +++ ldapclient.c24 Oct 2018 08:21:27 -
> > @@ -404,8 +404,13 @@ ldapc_printattr(struct ldapc *ldap, cons
> > * in SAFE-STRINGs. String value that do not match the
> > * criteria must be encoded as Base64.
> > */
> > - for (cp = (const unsigned char *)value;
> > - encode == 0 &&*cp != '\0'; cp++) {
> > + cp = (const unsigned char *)value;
> > + /* !SAFE-INIT-CHAR: SAFE-CHAR minus %x20 %x3A %x3C */
> > + if (*cp == ' ' ||
> > + *cp == ':' ||
> > + *cp == '<')
> > + encode = 1;
> > + for (; encode == 0 &&*cp != '\0'; cp++) {
^ missing space
> > /* !SAFE-CHAR %x01-09 / %x0B-0C / %x0E-7F */
> > if (*cp > 127 ||
> > *cp == '\0' ||
The *cp == '\0' check here is strange since that is part of the for loop
termination check.
> > @@ -421,7 +426,7 @@ ldapc_printattr(struct ldapc *ldap, cons
> > }
> > } else {
> > inlen = strlen(value);
> > - outlen = inlen * 2 + 1;
> > + outlen = (((inlen + 2) / 3) * 4) + 1;
I'm surprised that there is no macro to calculate the length of a base64
string. Anyway math is right.
> >
> > if ((out = calloc(1, outlen)) == NULL ||
> > b64_ntop(value, inlen, out, outlen) == -1) {
> >
>
OK claudio
--
:wq Claudio
Re: join(1) add UTF-8 support
ping
On 10/24/18 11:34 AM, Martijn van Duren wrote:
> This adds UTF-8 support for join(1). Since we don't support collation we
> can skip that part of POSIX. This patch does add support for splitting
> columns on UTF-8 characters.
>
> Using schwarze@'s favorite UTF-8 character:
> $ cat /tmp/z1
> aßbßc
> $ cat /tmp/z2
> aßdße
> $ ./join -tß /tmp/z1 /tmp/z2
> aßbßcßdße
>
> All regression tests pass, and lightly tested.
>
> OK?
>
> martijn@
>
> Index: join.c
> ===
> RCS file: /cvs/src/usr.bin/join/join.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 join.c
> --- join.c23 Oct 2018 08:41:45 - 1.30
> +++ join.c24 Oct 2018 09:32:54 -
> @@ -34,10 +34,14 @@
> */
>
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> #include
> +#include
>
> #define MAXIMUM(a, b)(((a) > (b)) ? (a) : (b))
>
> @@ -81,11 +85,12 @@ int joinout = 1; /* show lines with mat
> int needsep; /* need separator character */
> int spans = 1; /* span multiple delimiters (-t) */
> char *empty; /* empty field replacement string (-e) */
> -char *tabchar = " \t"; /* delimiter characters (-t) */
> +wchar_t tabchar[] = L" \t"; /* delimiter characters (-t) */
>
> int cmp(LINE *, u_long, LINE *, u_long);
> void fieldarg(char *);
> void joinlines(INPUT *, INPUT *);
> +char *mbssep(char **, const wchar_t *);
> void obsolete(char **);
> void outfield(LINE *, u_long, int);
> void outoneline(INPUT *, LINE *);
> @@ -101,6 +106,8 @@ main(int argc, char *argv[])
> int aflag, ch, cval, vflag;
> char *end;
>
> + setlocale(LC_CTYPE, "");
> +
> if (pledge("stdio rpath", NULL) == -1)
> err(1, "pledge");
>
> @@ -161,8 +168,10 @@ main(int argc, char *argv[])
> break;
> case 't':
> spans = 0;
> - if (strlen(tabchar = optarg) != 1)
> + if (mbtowc(tabchar, optarg, MB_CUR_MAX) !=
> + strlen(optarg))
> errx(1, "illegal tab character specification");
> + tabchar[1] = L'\0';
> break;
> case 'v':
> vflag = 1;
> @@ -333,7 +342,7 @@ slurp(INPUT *F)
> /* Split the line into fields, allocate space as necessary. */
> lp->fieldcnt = 0;
> bp = lp->line;
> - while ((fieldp = strsep(, tabchar)) != NULL) {
> + while ((fieldp = mbssep(, tabchar)) != NULL) {
> if (spans && *fieldp == '\0')
> continue;
> if (lp->fieldcnt == lp->fieldalloc) {
> @@ -358,6 +367,36 @@ slurp(INPUT *F)
> free(line);
> }
>
> +char *
> +mbssep(char **stringp, const wchar_t *wcdelim)
> +{
> + char *s, *p;
> + size_t ndelim;
> + int i;
> + /* tabchar is never more than 2 */
> + char mbdelim[2][MB_LEN_MAX + 1];
> + size_t mblen[2];
> +
> + if ((s = *stringp) == NULL)
> + return NULL;
> + ndelim = wcslen(wcdelim);
> + for (i = 0; i < ndelim; i++) {
> + if ((mblen[i] = wctomb(mbdelim[i], wcdelim[i])) == -1)
> + errc(1, EILSEQ, "wctomb");
> + }
> + for (p = s; *p != '\0'; p++) {
> + for (i = 0; i < ndelim; i++) {
> + if (strncmp(p, mbdelim[i], mblen[i]) == 0) {
> + *p = '\0';
> + *stringp = p + mblen[i];
> + return s;
> + }
> + }
> + }
> + *stringp = NULL;
> + return s;
> +}
> +
> int
> cmp(LINE *lp1, u_long fieldno1, LINE *lp2, u_long fieldno2)
> {
> @@ -463,7 +502,7 @@ void
> outfield(LINE *lp, u_long fieldno, int out_empty)
> {
> if (needsep++)
> - putchar((int)*tabchar);
> + putwchar(*tabchar);
> if (!ferror(stdout)) {
> if (lp->fieldcnt <= fieldno || out_empty) {
> if (empty != NULL)
>
Re: ldap(1) add SAFE-INIT-CHAR
ping
On 10/24/18 10:27 AM, Martijn van Duren wrote:
> In my previous ldap mail I proclaimed that we should encode whitespace.
> Reading rfc2849 a bit further, encoding a string with leading space is
> mandatory by SAFE-INIT-CHAR. This is needed because of the definition
> of value-spec, which allows additional space, colon, and less-than
> after the colon separating the AttributeDescription.
>
> The code below adds these definitions. I also changed the outlen
> calculation because it at least fails b64_ntop on inlen == 1.
>
> OK?
>
> martijn@
>
> Index: ldapclient.c
> ===
> RCS file: /cvs/src/usr.bin/ldap/ldapclient.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 ldapclient.c
> --- ldapclient.c 23 Oct 2018 08:28:34 - 1.5
> +++ ldapclient.c 24 Oct 2018 08:21:27 -
> @@ -404,8 +404,13 @@ ldapc_printattr(struct ldapc *ldap, cons
>* in SAFE-STRINGs. String value that do not match the
>* criteria must be encoded as Base64.
>*/
> - for (cp = (const unsigned char *)value;
> - encode == 0 &&*cp != '\0'; cp++) {
> + cp = (const unsigned char *)value;
> + /* !SAFE-INIT-CHAR: SAFE-CHAR minus %x20 %x3A %x3C */
> + if (*cp == ' ' ||
> + *cp == ':' ||
> + *cp == '<')
> + encode = 1;
> + for (; encode == 0 &&*cp != '\0'; cp++) {
> /* !SAFE-CHAR %x01-09 / %x0B-0C / %x0E-7F */
> if (*cp > 127 ||
> *cp == '\0' ||
> @@ -421,7 +426,7 @@ ldapc_printattr(struct ldapc *ldap, cons
> }
> } else {
> inlen = strlen(value);
> - outlen = inlen * 2 + 1;
> + outlen = (((inlen + 2) / 3) * 4) + 1;
>
> if ((out = calloc(1, outlen)) == NULL ||
> b64_ntop(value, inlen, out, outlen) == -1) {
>
