Re: libre/openssl patches available
On Thu, 19 Mar 2015, John Merriam wrote: On Thu, 19 Mar 2015, Ted Unangst wrote: Ted Unangst wrote: Patches are now available to fix a variety of issues in libcrypto and libssl. 5.5 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/024_openssl.patch.sig And I boned the instructions again. cd /usr/src/lib/libcrypto/crypto should be cd /usr/src/lib/libssl/crypto instead. Hmmm: # cd /usr/src/lib/libssl/crypto ksh: cd: /usr/src/lib/libssl/crypto - No such file or directory On 5.6-release amd64. I'll look back to see if I can find it but is there a different process to build all of libssl to be sure it's all patched? Nevermind. I see my failure. That change is for the 5.5 patch only I'm thinking. Sorry for the noise again. -- John Merriam
Re: libxfont errata
On 2015-03-18 04:06, Ted Unangst wrote: Patches are now available to fix buffer overflows in libXfont. This issue affects 5.5, 5.6, and the forthcoming 5.7 release. For more details, refer to the X.org advisory: http://www.x.org/wiki/Development/Security/Advisory-2015-03-17/ 5.5 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/023_libxfont.patch.sig 5.6 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/019_libxfont.patch.sig I'm sure most people could figure this out, but: --- 019_libxfont.patch.sig Wed Mar 18 01:25:07 2015 +++ 019_libxfont.patch.sig.fixedWed Mar 18 10:14:11 2015 @@ -17,7 +17,7 @@ Then build and install a new libXfont: -cd /usr/xenocara/lib/libXont +cd /usr/xenocara/lib/libXfont make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build Looks like the 5.5 patch has the same typo. Also wanted to pass along a BIG THANK YOU to all the OpenBSD developers for all the great work you do! -- John Merriam
Re: libxfont errata
On 2015-03-18 04:05, Ted Unangst wrote: Patches are now available to fix buffer overflows in libXfont. This issue affects 5.5, 5.6, and the forthcoming 5.7 release. For more details, refer to the X.org advisory: http://www.x.org/wiki/Development/Security/Advisory-2015-03-17/ 5.5 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/023_libxfont.patch.sig 5.6 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/019_libxfont.patch.sig I sent this earlier but I think it didn't go through for some reason so I am resending it. If it did go through the first time, sorry for the noise. Original message below... I'm sure most people could figure this out, but: --- 019_libxfont.patch.sig Wed Mar 18 01:25:07 2015 +++ 019_libxfont.patch.sig.fixedWed Mar 18 10:14:11 2015 @@ -17,7 +17,7 @@ Then build and install a new libXfont: -cd /usr/xenocara/lib/libXont +cd /usr/xenocara/lib/libXfont make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build Looks like the 5.5 patch has the same typo. Also wanted to pass along a BIG THANK YOU to all the OpenBSD developers for all the great work you do! -- John Merriam
Re: ksh version lies
On Tue, 17 Feb 2015, Adam Thompson wrote: On 2015-02-17 08:06 PM, John Merriam wrote: I definitely agree that the silliness of checking a version string to possibly use some exotic or non-standard feature of a particular flavor of a particular family of shells is not a good idea when writing a shell script. If you can't do what you want without relying on that particular feature then maybe what you're writing shouldn't be a shell script. If it's a bug in a particular flavor of a shell, then instead of checking for and working around it, report the bug to the author/maintainer. Jumping in late in the conversation... This is not an academic point; as an ISV, I've had to do this sort of thing in the past, and will have to do so again in the future. There is no standard or universal way to detect what version of what shell happened to get invoked on what operating system, so an ISV must rely on tricks and silliness like checking the version string to make what amounts to an educated guess. For example, I have a customer that must run a specific (non-current) version of HP-UX due to hard dependencies in a mission-critical line-of-business app. Yes, that means there's a foundational problem, but it would cost ~$100M to fix now. Not going to happen. Report the bug to the author/maintainer is all very well, but HP isn't going to issue a patch for an old version of HP-UX just because one customer complains about /bin/ksh behaving badly. (Actually, they very well might, given sufficient financial incentive, but that's another story altogether...) Meanwhile, portable shell scripts must continue to run - portably - across multiple OSes. Array handling is the big bugbear I run into; if I can handle arrays inside the shell, I don't have to resort to using tmpfiles and fork/exec'ing multiple external utilities to simulate the functionality. Which means, firstly, determining if I'm inside something ksh-like or bash-like, or if I'm running in a simple POSIX shell. There are virtually no safe assumptions that can be made in portable shell scripting - how was the script invoked? Sourced? Hash-bang? Explicit /bin/sh script invocation? It's a mess, despite POSIX' attempt to unify things; the choice is to either code for lowest-common-denominator, which typically results in payloads up to 10x larger and that run up to 10x slower, or to probe for advanced features and exit cleanly and safely if they're absent. I definitely hear what you're saying. I also have seen issues dealing with arrays in shell scripts. What I do when I want an array in a shell script is to either switch to Perl5 or some other language, or insist that the shell be Bash. Say what you want about Bash but I have found it to be relatively consistent and available on many platforms. I would guess that option 5 in my original post in this thread (a version string with no version numbers with or without PD KSH in it) would probably keep the majority of shell script writers happy (especially if it does have PD KSH in it) and would involve no maintenance down the line. But maybe that's not the case. Are there large numbers of scripts keying off the version numbers out there? -- John Merriam
Re: ksh version lies
On 2/17/2015 7:40 PM, Ted Unangst wrote: Jérémie Courrèges-Anglas wrote: Ted Unangst t...@tedunangst.com writes: [...] So let's return to the top. What does PD KSH in KSH_VERSION mean? What does one do differently if that string is present or missing? sigh pdksh is not the same thing as ksh88 or ksh93. And not the same thing as mksh, which has grew features since it was based on pdksh from the OpenBSD tree. And you may want to avoid known problems in some of those, or use known nice features in others, whether it is in scripts or your dotfiles. But for this obviously you have to know which shell you're using. Your proposal to remove the variable or to change significantly its content breaks other people's way to use ksh. I'm asking specifically what those features are. Well, good luck with that. As things stand, we need to make a list of features *not* to implement, lest people's version tests become incorrect. Are you genuinely afraid that people won't be able to use the features you plan to implement in ksh? Do you actually think that third-party shell developers out there have stopped implementing features just because ill-oriented users may make bad uses of $WHATEVERSH_VERSION? In short, I think KSH_VERSION encompasses all the badness of web pages that check USER_AGENT. We should not perpetuatate such silliness. Feel free to send this straight to the circular file, but I have been watching this discussion with some interest and figured I would add a couple cents to it. From what I can see the options are: 1) Leave OpenBSD ksh version string as it is which references only PD KSH. 2) Remove it completely as proposed by tedu. 3) Change it to something else not referencing PD KSH like OpenBSD ksh 5.7. 4) Change it to something else referencing PD KSH like OpenBSD ksh 5.7; based on PD KSH v5.2.14 as proposed by djm. 5) Change it to something that does not include version numbers like OpenBSD ksh or OpenBSD ksh based on PD KSH. I think option one is the least preferable if it isn't really PD KSH anymore. Options 2 and 5 are set and forget. Options 3 and 4 need to be bumped for each ksh/OpenBSD release. Personally I don't care what $???_VERSION is (or if it exists at all) in a shell I'm writing for. If I'm using #!/bin/sh, I'll stick to standard Bourne shell. If it's #!/bin/bash, it'll be Bash. If it's #!/bin/ksh, I'll try to stick with features common to all Korn shell variants. I definitely agree that the silliness of checking a version string to possibly use some exotic or non-standard feature of a particular flavor of a particular family of shells is not a good idea when writing a shell script. If you can't do what you want without relying on that particular feature then maybe what you're writing shouldn't be a shell script. If it's a bug in a particular flavor of a shell, then instead of checking for and working around it, report the bug to the author/maintainer. -- John Merriam
Re: additional drm fixes from linux-stable 3.10.y
ATI EHCI root hub rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 ATI SBx00 SMBus rev 0x13: SMI iic0 at piixpm0 spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 spdmem1 at iic0 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-5300CL5 pciide0 at pci0 dev 20 function 1 ATI SB600 IDE rev 0x00: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility azalia0 at pci0 dev 20 function 2 ATI SBx00 HD Audio rev 0x00: apic 8 int 16 azalia0: codecs: Analog Devices AD1983 audio0 at azalia0 pcib0 at pci0 dev 20 function 3 ATI SB600 ISA rev 0x00 ppb1 at pci0 dev 20 function 4 ATI SB600 PCI rev 0x00 pci2 at ppb1 bus 2 rl0 at pci2 dev 2 function 0 Realtek 8139 rev 0x10: apic 8 int 22, address 00:40:f4:6c:99:b2 rlphy0 at rl0 phy 0: RTL internal PHY bce0 at pci2 dev 9 function 0 Broadcom BCM4401B1 rev 0x02: apic 8 int 21, address 00:1d:09:16:ca:2e bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 ATI OHCI root hub rev 1.00/1.00 addr 1 usb2 at ohci1: USB revision 1.0 uhub2 at usb2 ATI OHCI root hub rev 1.00/1.00 addr 1 usb3 at ohci2: USB revision 1.0 uhub3 at usb3 ATI OHCI root hub rev 1.00/1.00 addr 1 usb4 at ohci3: USB revision 1.0 uhub4 at usb4 ATI OHCI root hub rev 1.00/1.00 addr 1 usb5 at ohci4: USB revision 1.0 uhub5 at usb5 ATI OHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 uhidev0 at uhub1 port 1 configuration 1 interface 0 Logitech Optical USB Mouse rev 2.00/3.40 addr 2 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse0 at ums0 mux 0 uhub6 at uhub1 port 2 Dell Dell USB Keyboard Hub rev 1.10/48.01 addr 3 uhidev1 at uhub6 port 1 configuration 1 interface 0 Dell Dell USB Keyboard Hub rev 1.10/48.00 addr 4 uhidev1: iclass 3/1 ukbd0 at uhidev1: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 uhidev2 at uhub6 port 1 configuration 1 interface 1 Dell Dell USB Keyboard Hub rev 1.10/48.00 addr 4 uhidev2: iclass 3/0, 3 report ids uhid0 at uhidev2 reportid 1: input=1, output=0, feature=0 uhid1 at uhidev2 reportid 2: input=1, output=0, feature=0 uhid2 at uhidev2 reportid 3: input=3, output=0, feature=0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (387205e18729d3cc.a) swap on sd0b dump on sd0b drm: initializing kernel modesetting (RS400 0x1002:0x5A61 0x1028:0x01E5). radeondrm0: VRAM: 32M 0xCE00 - 0xCFFF (32M used) radeondrm0: GTT: 512M 0xA000 - 0xBFFF drm: PCIE GART of 512M enabled (table at 0xCCD6D000). error: [drm:pid0:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) error: [drm:pid0:r100_cp_init] *ERROR* radeon: cp isn't working (-22). error: [drm:pid0:rs400_startup] *ERROR* failed initializing CP (-22). error: [drm:pid0:rs400_init] *ERROR* Disabling GPU acceleration error: [drm:pid0:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. error: [drm:pid0:r100_cp_disable] *ERROR* Failed to wait GUI idle while programming pipes. Bad things might happen. drm: radeon: cp finalized radeondrm0: 1280x1024 wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 wskbd1: connecting to wsdisplay0 wsdisplay0: screen 1-5 added (std, vt100 emulation) -- John Merriam
