Re: OpenBSD Errata: December 11th, 2019 (ldso)
Antoine Jacoutot wrote: > On Sun, Dec 15, 2019 at 09:07:50AM +1000, Stuart Longland wrote: > > On 15/12/19 9:04 am, Antoine Jacoutot wrote: > > > On Sun, Dec 15, 2019 at 08:43:02AM +1000, Stuart Longland wrote: > > >> On 14/12/19 7:49 pm, Frank Beuth wrote: > > >>> OpenBSD doesn't have unit tests (or if they are, they're not in the main > > >>> source tree). How does the project ensure that such wonderfully quick > > >>> fixes don't introduce new bugs? > > >> > > >> I think what helps too is the KISS approach taken in the design of the > > >> software… I think a concept that the Linux community is sadly losing > > >> sight of. > > >> > > >> Simple code is much easier to patch, review and maintain. > > > > > > Which should not be an excuse for a lacking test suite... > > > > Well, off you go then. :-) Get those butterflies¹ flapping. > > > > The other nice thing about OpenBSD is the source code is right there, so > > writing unit tests around that should be comparatively trivial. > > Absolutely. > Eagerly waiting for your contrib. I also noticed the commentary wasn't accompanied by a diff.
Re: OpenBSD Errata: December 11th, 2019 (ldso)
On Sun, Dec 15, 2019 at 09:07:50AM +1000, Stuart Longland wrote: > On 15/12/19 9:04 am, Antoine Jacoutot wrote: > > On Sun, Dec 15, 2019 at 08:43:02AM +1000, Stuart Longland wrote: > >> On 14/12/19 7:49 pm, Frank Beuth wrote: > >>> OpenBSD doesn't have unit tests (or if they are, they're not in the main > >>> source tree). How does the project ensure that such wonderfully quick > >>> fixes don't introduce new bugs? > >> > >> I think what helps too is the KISS approach taken in the design of the > >> software… I think a concept that the Linux community is sadly losing > >> sight of. > >> > >> Simple code is much easier to patch, review and maintain. > > > > Which should not be an excuse for a lacking test suite... > > Well, off you go then. :-) Get those butterflies¹ flapping. > > The other nice thing about OpenBSD is the source code is right there, so > writing unit tests around that should be comparatively trivial. Absolutely. Eagerly waiting for your contrib. -- Antoine
Re: OpenBSD Errata: December 11th, 2019 (ldso)
On 15/12/19 9:04 am, Antoine Jacoutot wrote: > On Sun, Dec 15, 2019 at 08:43:02AM +1000, Stuart Longland wrote: >> On 14/12/19 7:49 pm, Frank Beuth wrote: >>> OpenBSD doesn't have unit tests (or if they are, they're not in the main >>> source tree). How does the project ensure that such wonderfully quick >>> fixes don't introduce new bugs? >> >> I think what helps too is the KISS approach taken in the design of the >> software… I think a concept that the Linux community is sadly losing >> sight of. >> >> Simple code is much easier to patch, review and maintain. > > Which should not be an excuse for a lacking test suite... Well, off you go then. :-) Get those butterflies¹ flapping. The other nice thing about OpenBSD is the source code is right there, so writing unit tests around that should be comparatively trivial. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. 1. https://www.xkcd.com/378/
Re: OpenBSD Errata: December 11th, 2019 (ldso)
On Sun, Dec 15, 2019 at 08:43:02AM +1000, Stuart Longland wrote: > On 14/12/19 7:49 pm, Frank Beuth wrote: > > OpenBSD doesn't have unit tests (or if they are, they're not in the main > > source tree). How does the project ensure that such wonderfully quick > > fixes don't introduce new bugs? > > I think what helps too is the KISS approach taken in the design of the > software… I think a concept that the Linux community is sadly losing > sight of. > > Simple code is much easier to patch, review and maintain. Which should not be an excuse for a lacking test suite... -- Antoine
Re: OpenBSD Errata: December 11th, 2019 (ldso)
On 14/12/19 7:49 pm, Frank Beuth wrote: > OpenBSD doesn't have unit tests (or if they are, they're not in the main > source tree). How does the project ensure that such wonderfully quick > fixes don't introduce new bugs? I think what helps too is the KISS approach taken in the design of the software… I think a concept that the Linux community is sadly losing sight of. Simple code is much easier to patch, review and maintain. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Third server now locked up after reboot due to no keyboard attached
I have now another machine running OpenBSD not recover from a reboot. I thought I was having hardware issues with my two other servers (both zbox) and now this third one (Dell) with totally different hardware is having the same problem getting stuck at the boot> prompt. The problem goes away and boots continue normally if I attach a USB keyboard in all three cases. I feel like this problem started showing up around OpenBSD 6.4. Is this a known issue? When there is no keyboard attached the boot> prompt shows a box with a question mark in it looking like an unknown character. Picture showing this on bootx64 3.46: https://photos.app.goo.gl/7HAqQic6GArLGzaXA Here is the dmesg from my latest Dell server: OpenBSD 6.6 (GENERIC.MP) #3: Thu Nov 21 03:20:01 MST 2019 r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ GENERIC.MP real mem = 8487182336 (8094MB) avail mem = 8217251840 (7836MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe (71 entries) bios0: vendor Dell Inc. version "A02" date 11/14/2014 bios0: Dell Inc. OptiPlex 3020M acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SLIC SSDT SSDT SSDT HPET SSDT MCFG SSDT MSDM BGRT acpi0: wakeup devices UAR1(S3) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz, 2993.45 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz, 2993.08 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz, 2993.07 MHz, 06-3c-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz, 2993.07 MHz, 06-3c-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP03) acpiprt3 at acpi0: bus 3 (RP04) acpiprt4 at acpi0: bus -1 (PEG0) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0:
Re: [sh] Single quote in comment withing subshell buggy
On Sat, 14 Dec 2019 09:03:26 +, cho...@jtan.com wrote: > This is certainly not the best way to do this but it does the job: > > In particular it just reeks of kludge, which I'm not happy with > because according to the comment two-dozen lines up it's already a > kludge. The loop is lifted from the beginning of the same function, > where regular comments are skipped. That's not too awful. The $( ... ) parsing code in our ksh is not the greatest. - todd
Re: [sh] Single quote in comment withing subshell buggy
Hi Matthew, I'm unable to judge the patch, but appreciate your quick fix. Thanks a lot! I'm looking forward to the next release, in which it is contained. I just occurred to me, that the problem also exists for ". Is this covered with your patch as well? Richard cho...@jtan.com wrote: > Richard Ulmer writes: > > Hi, > > when there is a single ' in a comment within a subshell, I get this > > error: foo[6]: no closing quote > > > > Here is an example script to reproduce the problem: > > > > foo=$( > > # It's bar: > > echo bar > > ) > > echo $foo > > This is certainly not the best way to do this but it does the job: > > ~/src/ksh [OpenBSD 6.6] > [ksh]flask@void$ /bin/ksh > void$ foo=$( > > # quote: ' > > echo bar > > ) > > ^D > /bin/ksh: no closing quote > ~/src/ksh [OpenBSD 6.6] > [ksh]flask@void$ ./ksh > void$ foo=$( > > # quote: ' > > echo bar > > ) > void$ echo $foo > bar > void$ > > In particular it just reeks of kludge, which I'm not happy with > because according to the comment two-dozen lines up it's already a > kludge. The loop is lifted from the beginning of the same function, > where regular comments are skipped. > > Matthew > > --- lex.c.~1.78.~ Mon Jan 15 16:58:05 2018 > +++ lex.c Sat Dec 14 10:55:06 2019 > @@ -496,6 +496,12 @@ > statep->ls_scsparen.csstate = 4; > ignore_backslash_newline++; > break; > +case '#': > +ignore_backslash_newline++; > +while ((c = getsc()) != '\0' && c != > '\n') > +; > +ignore_backslash_newline--; > +break; > } > break; >
Re: OpenBSD Errata: December 11th, 2019 (ldso)
On Sat, Dec 14, 2019 at 10:49:31AM +0100, Frank Beuth wrote: > On Wed, Dec 11, 2019 at 01:51:18PM -0500, T.J. Townsend wrote: > > Errata patches for ld.so have been released for OpenBSD 6.5 and 6.6. > > > > ld.so may fail to remove the LD_LIBRARY_PATH environment variable for > > set-user-ID and set-group-ID executables in low memory conditions. > > The security advisory connected with this bug indicates the patch was > published within 3 hours of reporting: > https://www.openwall.com/lists/oss-security/2019/12/11/9 > > OpenBSD doesn't have unit tests (or if they are, they're not in the main > source tree). How does the project ensure that such wonderfully quick > fixes don't introduce new bugs? > We do have tests in src/regress. But remember: tests do not prove you code is correct. We look at code, that is a very important skill. The fix in this case isn't very complicated and can easily be verified. You can do that too! http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/loader.c.diff?r1=1.188=1.189=date=h -Otto
Re: regression tests (was: OpenBSD Errata: December 11th, 2019 (ldso))
On Sat, Dec 14, 2019, Frank Beuth wrote: > OpenBSD doesn't have unit tests (or if they are, they're not in the main Hmm, what about src/regress/ ? You are probably welcome to contribute tests :-) -- Address is valid for this mailing list only.
Re: OpenBSD Errata: December 11th, 2019 (ldso)
On Wed, Dec 11, 2019 at 01:51:18PM -0500, T.J. Townsend wrote: Errata patches for ld.so have been released for OpenBSD 6.5 and 6.6. ld.so may fail to remove the LD_LIBRARY_PATH environment variable for set-user-ID and set-group-ID executables in low memory conditions. The security advisory connected with this bug indicates the patch was published within 3 hours of reporting: https://www.openwall.com/lists/oss-security/2019/12/11/9 OpenBSD doesn't have unit tests (or if they are, they're not in the main source tree). How does the project ensure that such wonderfully quick fixes don't introduce new bugs?
Re: [sh] Single quote in comment withing subshell buggy
On Sat, Dec 14, 2019 at 09:03:26AM +, cho...@jtan.com wrote: > Richard Ulmer writes: > > Hi, > > when there is a single ' in a comment within a subshell, I get this > > error: foo[6]: no closing quote > > > > Here is an example script to reproduce the problem: > > > > foo=$( > > # It's bar: > > echo bar > > ) > > echo $foo > > This is certainly not the best way to do this but it does the job: > > ~/src/ksh [OpenBSD 6.6] > [ksh]flask@void$ /bin/ksh > void$ foo=$( > > # quote: ' > > echo bar > > ) > > ^D I think a better way would be to use UTF-8 single quote, For example codepoint 8217 ”RIGHT SINGLE QUOTATION MARK” foo=$( #It’s bar: echo bar ) -- Nils Ola Nilsson, email nils...@abc.se signature.asc Description: PGP signature
Re: [sh] Single quote in comment withing subshell buggy
Richard Ulmer writes: > Hi, > when there is a single ' in a comment within a subshell, I get this > error: foo[6]: no closing quote > > Here is an example script to reproduce the problem: > > foo=$( > # It's bar: > echo bar > ) > echo $foo This is certainly not the best way to do this but it does the job: ~/src/ksh [OpenBSD 6.6] [ksh]flask@void$ /bin/ksh void$ foo=$( > # quote: ' > echo bar > ) > ^D /bin/ksh: no closing quote ~/src/ksh [OpenBSD 6.6] [ksh]flask@void$ ./ksh void$ foo=$( > # quote: ' > echo bar > ) void$ echo $foo bar void$ In particular it just reeks of kludge, which I'm not happy with because according to the comment two-dozen lines up it's already a kludge. The loop is lifted from the beginning of the same function, where regular comments are skipped. Matthew --- lex.c.~1.78.~ Mon Jan 15 16:58:05 2018 +++ lex.c Sat Dec 14 10:55:06 2019 @@ -496,6 +496,12 @@ statep->ls_scsparen.csstate = 4; ignore_backslash_newline++; break; +case '#': +ignore_backslash_newline++; +while ((c = getsc()) != '\0' && c != '\n') +; +ignore_backslash_newline--; +break; } break;
Re: [sh] Single quote in comment within subshell buggy
On Sat, Dec 14, 2019, Richard Ulmer wrote: > foo=$( > # It's bar: > echo bar > ) > echo $foo Because I was curious I just tested it on a FreeBSD 11.2 box: no error with /bin/sh and /bin/ksh. -- Address is valid for this mailing list only.
[sh] Single quote in comment withing subshell buggy
Hi, when there is a single ' in a comment within a subshell, I get this error: foo[6]: no closing quote Here is an example script to reproduce the problem: foo=$( # It's bar: echo bar ) echo $foo I found this behaviour unexpected und suspect it's a bug. I had encountered this as a real world problem in a project on GitHub [1]. With best regards, Richard Ulmer [1] https://github.com/mawww/kakoune/pull/2943
