Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
2015-12-13 7:17 GMT+01:00 Delan Azabani : > On Sun, Dec 13, 2015 at 6:28 AM, Kevin Chadwick wrote: >> On a low traffic site it already annoys me that I have to change it >> once per year with startSSL. > > This is what the tooling provided by Let's Encrypt is designed to > solve. It shouldn't be hard to issue new certificates, and for many > applications, the fact that issuing them is a manual process results > in more downtime when a certificate is compromised. > I'll give my 2 cents, First, the author of the Let's Encrypt tool say himself people are perfectly right to not trust a random script downloaded from the internet. Their tools should be seen as an example, not the only true way of doing things. Secondly, this whole thread should have ended long ago. It have been mentioned a couple of times. The main outcome of https is to make caching impossible. It introduce a non trivial computational cost for serving every file. Remember, OpenBSD is no facebook. It serve static file from cache, not the output of a script. There is a lot of whining about refusing https despite it being a mitigation technique. Would you accept a mitigation technique making your favorite OS half as slow and consuming twice as much power ? I don't think so. Signify exist for integrity. You can get an initial key with the CD. The CD looks cool on a shelf, comes with nice artwork, helps pay theo bills and is way harder to tamper than a letter. Who talked about fiendlish difficulty ? VPN is a better tool for anonymity. https doesn't hide your DNS query or the domain you are connecting to. All the bad guy have to search on the site which page have the same length as the one you downloaded. If done right, VPN will hide who is downloading the file and put the burden away from the OpenBSD project. -- Cordialement, Coues Ludovic +336 148 743 42
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
On Sun, Dec 13, 2015 at 6:28 AM, Kevin Chadwick wrote: > On a low traffic site it already annoys me that I have to change it > once per year with startSSL. This is what the tooling provided by Let's Encrypt is designed to solve. It shouldn't be hard to issue new certificates, and for many applications, the fact that issuing them is a manual process results in more downtime when a certificate is compromised.
Re: syscall 5 "cpath" continues with octeon
Worst case, delete all partitions (EXCEPT the first one, the FAT one) and use only one, install, test and then redo as you see fit. You can mount your FAT partition and access it right? You do have the bsd.rd file on that FAT partition right? May be your fat partition conflict with one of the default install. I don't really know as i can see it. But really it works. I also fell like ssh to one of your box you have terminal to this one, where you have nothing to show you and then install it for you, then when you see it working you redo it for both the ssh box and this one as you shouldn't trust me anyway! I know I wouldn't trust anyone to do an install for me, but I have so many boxes around to lay with and that I am testing with, setting one just for this and have a terminal to an other is easy and then I would have no problem to wipe it out after that if you have the same I could help you as a LAST resort, but really you can do it! This is something I would never do or really have someone do to me except if I am totally stuck, but your setup is not difficult and it does work, so if you provide more details may be I can help you, however it really does work. I fell, you have to do something wrong someplace or skip a set or something, unless your USB flash drive IS REALLY BAD may be, but I really don't think it is what's going on! Daniel On 12/12/15 10:42 PM, jungle Boogie wrote: > Hello All, > > Despite the very helpful reply from Daniel on this thread: > http://marc.info/?l=openbsd-misc&m=14493626054&w=2 > > I'm faced with the same message upon accepting the default partition > and disk layout: > disklabel(19593): syscall 5 "cpath" > Abort trap > > When attempting to use the Octeon snapshot from November: > http://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/ > > Is there something more I can do to get this working or is this some > pledge issue? To rule out a USB disk problem or edge router lite > problem, I can load the previous bsd.rd file but I would need someone > to share that with me because I don't have it anymore. > > Thanks!
Re: syscall 5 "cpath" continues with octeon
I am really not sure what problem you are facing for sure. I did a few times form scratch and every time it goes without any problems what so ever and I really don't see where your cpath can come from at all. And I see no pledge issue what so ever either. Are you sure that you are actually using the proper bsd.rd, NOT a previous version somehow. You need to make sure to put it on your fat partition BEFORE trying to do the install and then create your own partition, no need to use the default one, plus it's not like you will do development on this box. What partition is your bsd.rd installed on? If you do. mount_msdos /dev/sd0i /mnt where the ^ is your fat partition. The ^ point to the i of sd0i, your may well be at a different place. After you mount it, what ls -al show. Is it really the proper one. If, not then just: cd /mnt and then download it ftp http://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/bsd.rd and then make sure you load that one to do the install. I would want to help you more, but it's hard to know what you do or do not do. Daniel On 12/12/15 10:42 PM, jungle Boogie wrote: > Hello All, > > Despite the very helpful reply from Daniel on this thread: > http://marc.info/?l=openbsd-misc&m=14493626054&w=2 > > I'm faced with the same message upon accepting the default partition > and disk layout: > disklabel(19593): syscall 5 "cpath" > Abort trap > > When attempting to use the Octeon snapshot from November: > http://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/ > > Is there something more I can do to get this working or is this some > pledge issue? To rule out a USB disk problem or edge router lite > problem, I can load the previous bsd.rd file but I would need someone > to share that with me because I don't have it anymore. > > Thanks!
syscall 5 "cpath" continues with octeon
Hello All, Despite the very helpful reply from Daniel on this thread: http://marc.info/?l=openbsd-misc&m=14493626054&w=2 I'm faced with the same message upon accepting the default partition and disk layout: disklabel(19593): syscall 5 "cpath" Abort trap When attempting to use the Octeon snapshot from November: http://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/ Is there something more I can do to get this working or is this some pledge issue? To rule out a USB disk problem or edge router lite problem, I can load the previous bsd.rd file but I would need someone to share that with me because I don't have it anymore. Thanks! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si irc: jungle-boogie
Re: Wireless connection mystery two OpenBSD machines suddenly cannot connect
Carl Trachte wrote: from the command line ifconfig down I think this resets the device IIRC Mystery solved. The $3 transformer for the DSL modem is dying. If I unplug it and let it cool off everything works again :) Off to buy a new $3 transformer :) Thanks Carl and Unixreader for replying! -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan
Re: Wireless connection mystery two OpenBSD machines suddenly cannot connect
from the command line ifconfig down I think this resets the device IIRC ifconfig up nwid wpakey At this point you should within a few seconds get an associated conneciton - if not there's another problem. On my thinkpad the little antenna light blinks then stays on constant when it's right. dhclient ping www.google.com to check to make sure everything works. Sorry if I've reviewed stuff you already tried or know. Good luck. On Sat, Dec 12, 2015 at 6:02 PM, Jack J. Woehr wrote: > I have two very different laptops running OpenBSD 5.8 with all patches. > > Both were connected to my home wireless via very simple hostname files: > > nwid foo > wpakey bar > dhcp > > Both stopped connecting today .. no link (sleeping). > Both see the station via ifconfig scan with reasonable dB levels > (>55dBm) > My mobile phone still connects to the station with the same credentials, as > does my Kindle. > > Of course this is ridiculous. I don't know enough to be dangerous on this > one. Any tips? > > -- > Jack J. Woehr # Science is more than a body of knowledge. It's a way of > www.well.com/~jax # thinking, a way of skeptically interrogating the > universe > www.softwoehr.com # with a fine understanding of human fallibility. - Carl > Sagan
Wireless connection mystery two OpenBSD machines suddenly cannot connect
I have two very different laptops running OpenBSD 5.8 with all patches. Both were connected to my home wireless via very simple hostname files: nwid foo wpakey bar dhcp Both stopped connecting today .. no link (sleeping). Both see the station via ifconfig scan with reasonable dB levels (>55dBm) My mobile phone still connects to the station with the same credentials, as does my Kindle. Of course this is ridiculous. I don't know enough to be dangerous on this one. Any tips? -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 05:35:47PM -0400, Kenneth R Westerback wrote: > On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote: > > On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote: > > > On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote: > > >> Well, git just has a different set of bugs than cvs. > > > ... > > >> I would deem cvs MORE painful than git on average, it's just that > > >> we're more accustomed to the pain... > > > > > > Yes, this is right. And also there would be a price to pay in lost > > > productivity in switching to a new system. To those very familiar with > > > CVS and not very familiar with Git (or hg, et al), the benefits of > > > switching are nebulous and uncertain, while the cost is very real. > > > > I will add a somewhat controversial viewpoint to the mix. Because cvs > > makes working with branches and large diffs so painful, it forces > > developers to split their work into smaller pieces. In OpenBSD, > > that's a good thing. Keeping your changes in a private fork is > > difficult, which is good. It means fewer private forks. If every > > developer could maintain a branch with some private tweaks, and not > > bother integrating their changes or fixing regressions, progress would > > grind to a halt. [I have mentioned this to people before and their > > eyes just about popped out of their head. I don't expect > > everyone to agree.] > > ++1 here. My only experience with a project that moved from cvs to > git was that a) the number of brances exploded and b) the number > of repositories containing branches exploded and were erratically > interconnected. > > This resulted in many rotting branches, many private playgrounds > and far less incentive to move forward together. I particularly > enjoyed messages containing lists of random hex numbers that one > should revert, merge with or sacrifice chickens over if one could > only find the appropriate repository. > I can share that we had the same experience when we started to use git at work: exploded and rotting branches, playgrounds, and all these troubles with git-isms and endless ways to do the same thing. But, quite frankly, it is a sign that a) the release maintenance sucks. b) the willingness and experience to master git is missing. After more than two years, we got used to git, established stricter rules, and I think we got rid of these problems plus having some of the benefits and reliefs over CVS (see espie's mail for a few examples). Most importantly, unused branches have to be deleted from the server, people have to work and develop in "master", and arbitrary experiments do not belong on the shared remote, unless they are important or intereting for others. If people do not test their changes in master, they will keep on breaking the tree and you'll have to deal with them personally (I think that is the "social" part of the model). After all, git is not github. The latter is the same old bazaar-like model where everyone does something somewhere and it eventually turns into releases, excluding quality. You do not have to use git like that, but it is a learning curve for people who only knew github. You can use git in a more traditional, centralized and self-hosted way. > OK, one experience but it left an indelible impression. :-) > > I think git gives you a lot of rope. It does. I'm fine with using CVS in OpenBSD. Reyk
Re: ld.so behavior with $ORIGIN
Just as an update: I just spent some time reading NetBSD source code to understand how they are doing it. They seem to do exactly what Philip suggested: pack the execname from kern_exec in the elf auxiliary vector, and dirname() that on ld.so. On Sat, Dec 12, 2015 at 4:08 PM, Aurélien Vallée wrote: >> I asked a question, and you didn't answer it. > > I did my best to try to find this out, but all I was able to dig are these > release notes of ELF gABI. > I will try to find how that was supposed to be solved at the time, but > I fear these details are lost in time, and not available on much online > documents I could get a hand on. > >> We could come up with a hack. > > If you don't mind detailing the hack you're thinking of, I could try to make > a patch implementing it. > > On Sat, Dec 12, 2015 at 3:23 PM, Theo de Raadt wrote: >>> Allow me to rephrase it with a clearer wording then: >>> We need the path that was provided to execve(), and thus contained - >>> at that time - the >>> ELF that was loaded". >> >> And once again, I am saying Unix doesn't have a standardized way of >> doing this. >> >> We could come up with a hack. > > > > -- > Aurélien Vallée > Phone +33 9 77 19 85 61 -- Aurélien Vallée Phone +33 9 77 19 85 61
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
> > and have to keep changing the cert every year. > > Your certificate cycling process should be automated, and it should > happen more frequently than once a year. Complete nonsense firstly and not a major point but you may have greater security than automating key changes and secondly the only reason you may want to is if you believe your key is not strong enough, in which case use a stronger key. It has *little* to do with time really but more to do with the amount of traffic the key has been used for and whether PFS has solely been used. On a low traffic site it already annoys me that I have to change it once per year with startSSL. -- KISSIS - Keep It Simple So It's Securable
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
> > I would consider signify keys printed on CDs and copied across several > > web sites safer than trusting the hundreds of CA certs shipped with a > > standard web browser. > > Didn't we just established that with HPKP you can disregard the CA > completely? At least if you trust your fist access to the site. But I > think this thread followed its course, lets move on. Xombrero does that by caching certs ;) I'd hardly call it disregarding the CA myself, makes it sound much more progressive than it is! -- KISSIS - Keep It Simple So It's Securable
Re: 8-Port Serial Port Card
On Sat, Dec 12, 2015 at 09:54:39AM +, Craig Skinner wrote: >On 2015-12-07 Mon 21:30 PM |, Jordon wrote: >> I recently picked up a few PCI serial port cards from the junk pile at >> work. My intent is to put one in my soon-to-be-retired Soekris net5501 >> and install OpenBSD on it to turn it into an 8 port terminal switch. >> >> I tried the cards in a different PC just to see if they would work. >> Unfortunately, none of them were supported. >> > >If you want to get going quickly Jordan, Moxa PCI cards work: > >$ fgrep puc0 /var/run/dmesg.boot >puc0 at pci0 dev 18 function 0 "Moxa C168H" rev 0x01: ports: 8 com >com4 at puc0 port 0 irq 9: ns16550a, 16 byte fifo >com5 at puc0 port 1 irq 9: ns16550a, 16 byte fifo >com6 at puc0 port 2 irq 9: ns16550a, 16 byte fifo >com7 at puc0 port 3 irq 9: ns16550a, 16 byte fifo >com8 at puc0 port 4 irq 9: ns16550a, 16 byte fifo >com9 at puc0 port 5 irq 9: ns16550a, 16 byte fifo >com10 at puc0 port 6 irq 9: ns16550a, 16 byte fifo >com11 at puc0 port 7 irq 9: ns16550a, 16 byte fifo > >I found 3 on ebay.co.uk & grabbed them - all with octopus cable. Beware, Soekris boards have a 3.3 V PCI slot while the Moxa C168H is a 5 V PCI card. -- Maurice
/bsd: athn0: device timeout
I own a Compex WLE200NX Atheros AR9280 Minipci-express Wlan Card and use it
in hostap-mode.
Every 10 minutes i get the following error:
/bsd: athn0: device timeout
The Wlan connections and all radio/video streaming stopps.
Then i do manually a "sh /etc/netstart athn0" and the radio/video streaming
continue.
Thats very annoying. Isn't there
a) a reasonable minipci-express wlan card for hostap-mode which is stable or
b) a patch for the device timeout-error?
I thought OpenBSD is ideally for routers?
My setup:
*/etc/hostname.re0*
up
*/etc/hostname.vlan100*
vlan 100 vlandev re0
up
*/etc/hostname.vlan178*
inet 192.168.178.184 255.255.255.0 NONE vlan 178 vlandev re0
up
*/etc/hostname.athn0*
mediaopt hostap mode 11g nwid openbsd wpakey up
*/etc/hostname.vether0*
inet 192.168.100.184 255.255.255.0
up
*/etc/hostname.bridge0*
add athn0
add vlan100
add vether0
up
*/etc/pf.conf*
if_lo="lo0"
ext_if="vlan178"
int_if="vether0"
wlan_if="athn0"
set skip on $if_lo
set skip on $int_if
set skip on $wlan_if
match on $ext_if scrub (reassemble tcp random-id max-mss 1440)
match out on $ext_if from any to !($ext_if) nat-to ($ext_if)
block all
pass out on $ext_if proto tcp all keep state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state
*dmesg:*
OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8256442368 (7873MB)
avail mem = 8002322432 (7631MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec3d0 (78 entries)
bios0: vendor American Megatrends Inc. version "B252P008" date 05/22/2015
bios0: ZOTAC XX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT
SSDT SSDT DMAR
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4)
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
PXSX(S4) RP05(S4) [...]
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) M-5Y10c CPU @ 0.80GHz, 1995.70 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT
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.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) M-5Y10c CPU @ 0.80GHz, 1995.39 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT
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) M-5Y10c CPU @ 0.80GHz, 1995.39 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT
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) M-5Y10c CPU @ 0.80GHz, 1995.39 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimadt0: bogus nmi for apid 0
acpimadt0: bogus nmi for apid 2
acpimadt0: bogus nmi for apid 1
acpimadt0: bogus nmi for apid 3
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 1 (RP01)
acpiprt5 at acpi0: bus -1 (RP02)
acpiprt6 at acpi0: bus 2 (RP03)
acpiprt7 at acpi0: bus 3 (RP04)
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
Thus said Tati Chevron on Fri, 11 Dec 2015 13:16:23 +: > On the other hand, if somebody actually received a fake OpenBSD CD in > the mail, and it was discovered, it would be a huge news story within > the IT industry. A bad download, much less so. My OpenBSD 5.7 CD arrived with a green label affixed to the shipping packaging that claimed it had been inspected by some U.S.A. customs department. It had actually been opened and resealed and the green label placed on it to inform me of said tampering. Did anything change? Is this a fake CD? Who knows. I do know that there was an extra CD in the shipment by The OpenBSD Store, apparently because there were problems with first stamping of the CD. Hopefully signify will protect in this case. Andy -- TAI64 timestamp: 4000566c62a4
Re: ld.so behavior with $ORIGIN
> I asked a question, and you didn't answer it. I did my best to try to find this out, but all I was able to dig are these release notes of ELF gABI. I will try to find how that was supposed to be solved at the time, but I fear these details are lost in time, and not available on much online documents I could get a hand on. > We could come up with a hack. If you don't mind detailing the hack you're thinking of, I could try to make a patch implementing it. On Sat, Dec 12, 2015 at 3:23 PM, Theo de Raadt wrote: >> Allow me to rephrase it with a clearer wording then: >> We need the path that was provided to execve(), and thus contained - >> at that time - the >> ELF that was loaded". > > And once again, I am saying Unix doesn't have a standardized way of > doing this. > > We could come up with a hack. -- Aurélien Vallée Phone +33 9 77 19 85 61
Re: ld.so behavior with $ORIGIN
>> It seems like most other unixes out there do have a way to retrieve the full >> path of a running program, mainly through /proc (be it /proc/pid/exe on >> Linux, or /proc/pid/path/a.out on Solaris (TBV). > An issue, though, is that this path does not have to refer to a file > which has anything to do with what the process is doing. You are right, apologizes for being very unclear on my wordings here. I totally understand that there is no way to literally retrieve "the path of the executable currently running". That doesn't make sense, as you stated and demonstrated. The file could have been removed, replaced, the partition unmounted, or whatever other million of reasons. Maintaining a relationship between a path and a running process on unix doesn't make sense. Allow me to rephrase it with a clearer wording then: We need the path that was provided to execve(), and thus contained - at that time - the ELF that was loaded". We don't need to - and can't - make any sort of guarantee on this path, it is just informational, and can be used by ld.so to perform $ORIGIN substitution. On Sat, Dec 12, 2015 at 2:19 PM, Raul Miller wrote: > On Sat, Dec 12, 2015 at 6:34 AM, Aurélien Vallée > wrote: >> It seems like most other unixes out there do have a way to retrieve the full >> path of a running program, mainly through /proc (be it /proc/pid/exe on >> Linux, or /proc/pid/path/a.out on Solaris (TBV). > > An issue, though, is that this path does not have to refer to a file > which has anything to do with what the process is doing. > > Here's an illustration: > > #!/bin/sh > set -e > mkdir -p $HOME/bin > rm -f $HOME/bin/example[12] > cp /bin/sleep $HOME/bin/example1 > ln $HOME/bin/example1 $HOME/bin/example2 > $HOME/bin/example2 100 & > rm -f $HOME/bin/example2 > cp /usr/bin/false $HOME/bin/example2 > echo "what is the full path for process $!?" > > Seriously, though: understanding the unix process/file model is > critically important if you are going to make any useful contributions > to the implementation. But I am not sure where to refer you to get the > basic idea. (I got mine from reading source code comments for a very > early version of unix.) > > All the docs I find through searching go into a lot of detail about > steps and procedures, but what I think you really need is something > cruder. I don't know where to point you for that, though - perhaps > such things have been lost to the mists of history? > > Good luck, > > -- > Raul -- Aurélien Vallée Phone +33 9 77 19 85 61
Re: ld.so behavior with $ORIGIN
On Sat, Dec 12, 2015 at 6:34 AM, Aurélien Vallée wrote: > It seems like most other unixes out there do have a way to retrieve the full > path of a running program, mainly through /proc (be it /proc/pid/exe on > Linux, or /proc/pid/path/a.out on Solaris (TBV). An issue, though, is that this path does not have to refer to a file which has anything to do with what the process is doing. Here's an illustration: #!/bin/sh set -e mkdir -p $HOME/bin rm -f $HOME/bin/example[12] cp /bin/sleep $HOME/bin/example1 ln $HOME/bin/example1 $HOME/bin/example2 $HOME/bin/example2 100 & rm -f $HOME/bin/example2 cp /usr/bin/false $HOME/bin/example2 echo "what is the full path for process $!?" Seriously, though: understanding the unix process/file model is critically important if you are going to make any useful contributions to the implementation. But I am not sure where to refer you to get the basic idea. (I got mine from reading source code comments for a very early version of unix.) All the docs I find through searching go into a lot of detail about steps and procedures, but what I think you really need is something cruder. I don't know where to point you for that, though - perhaps such things have been lost to the mists of history? Good luck, -- Raul
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
On Sat, Dec 12, 2015 at 7:11 PM, Constantine A. Murenin wrote: > once you give in to https once, you're hooked You're only hooked if you use HSTS. > and have to keep paying someone every year, There are at least three CAs that provide free certificates, and one of those is Let's Encrypt. > and have to keep changing the cert every year. Your certificate cycling process should be automated, and it should happen more frequently than once a year.
Re: ld.so behavior with $ORIGIN
> How did people get by without needing this in the last three decades? Just trying to be positive on a feature that would have interest for me. Nevermind. It seems like most other unixes out there do have a way to retrieve the full path of a running program, mainly through /proc (be it /proc/pid/exe on Linux, or /proc/pid/path/a.out on Solaris (TBV). >From what I have understood there is no /proc anymore of OpenBSD, and these info are now accessible through sysctl, so I thought that would fit nicely for this feature too. > Since Unix operating systems don't have a way to do this in general, > how did this become part of the ld.so spec? It is part of the System V ELF gABI. Current description: http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#substitution Revision history available at: http://www.sco.com/developers/gabi/latest/revision.html It was added in 2nd draft from 1999 may 3: > New dynamic section tags DT_RUNPATH and DT_FLAGS added. Dynamic section tag DT_RPATH moved to level 2. > New semantics for shared object path searching, including new ``Substitution Sequences''. On Fri, Dec 11, 2015 at 11:32 PM, Theo de Raadt wrote: >> > It would be that or >> > have the kernel store the whole path for the life of the process for >> > obtaining with sysctl() >> >> That would be great. ps and top would be able to display the path too, >> pretty handy. > > How did people get by without needing this in the last three decades? -- Aurélien Vallée Phone +33 9 77 19 85 61
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
On 11 December 2015 at 03:58, Kamil Cholewiński wrote: >> The official CD set contains the signify keys for that release and the >> next one. Once you have a known good copy of one set, you can always obtain >> future ones securely. >> >> You don't even need to use the CD set to install, just as a way of obtaining >> the signify keys with a high degree of confidence. > > This is the real thing bothering me. I don't even have a CD drive > available, and I was about to ask if it would be possible to get the > signify keys via paper mail in exchange for a donation. But both paper > and CDs can be intercepted and tampered with (with some effort). > >> I currently just assume they are correct because it'd be enormously >> complex to spoof the entire OpenBSD distribution, but I souldn't have >> to rely on "security through effort involved". > > Exactly, and this is a problem with the CDs too. There's currently no > way to securely bootstrap the chain of trust. HTTPS is a way to do that. LOL. Maybe you should read this: http://marc.info/?l=openbsd-bugs&m=138445221329747&w=2 Or take a look at the full list of CAs in your browser. > > Yes, we would have to rely on third parties (CAs). It can be optional > (so that a text browser from an ancient unsupported release can still Thing is, in https land, a "downgrade" is considered a serious attack, not a backwards-compatibility feature. If the browser fails to load https://example.org/, it will not even suggest you go to the http://example.org/ version. And what happens when someone gets their web-site onto https? People start linking to the https version, so, legacy devices/releases may no longer be capable of just following the web of links. (So much for World Wide Web!) > access plain HTTP version fine). It can be just a single page like > keys.openbsd.org so that there are few extra computing resources used. > It doesn't have to be Let's Encrypt - heck, I'm willing to go to > RapidSSL or whoever and pay for it myself if someone can give me a CSR > and assist with domain validation. Yes, and once you give in to https once, you're hooked and have to keep paying someone every year, and have to keep changing the cert every year. C. > > K.
Re: 8-Port Serial Port Card
On 2015-12-07 Mon 21:30 PM |, Jordon wrote: > I recently picked up a few PCI serial port cards from the junk pile at > work. My intent is to put one in my soon-to-be-retired Soekris net5501 > and install OpenBSD on it to turn it into an 8 port terminal switch. > > I tried the cards in a different PC just to see if they would work. > Unfortunately, none of them were supported. > If you want to get going quickly Jordan, Moxa PCI cards work: $ fgrep puc0 /var/run/dmesg.boot puc0 at pci0 dev 18 function 0 "Moxa C168H" rev 0x01: ports: 8 com com4 at puc0 port 0 irq 9: ns16550a, 16 byte fifo com5 at puc0 port 1 irq 9: ns16550a, 16 byte fifo com6 at puc0 port 2 irq 9: ns16550a, 16 byte fifo com7 at puc0 port 3 irq 9: ns16550a, 16 byte fifo com8 at puc0 port 4 irq 9: ns16550a, 16 byte fifo com9 at puc0 port 5 irq 9: ns16550a, 16 byte fifo com10 at puc0 port 6 irq 9: ns16550a, 16 byte fifo com11 at puc0 port 7 irq 9: ns16550a, 16 byte fifo I found 3 on ebay.co.uk & grabbed them - all with octopus cable. -- I once met a lassie named Ruth, In a long distance telephone booth. Now I know the perfection, Of an ideal connection, Even if somewhat uncouth.
Re: Pictures are "blurred" in certain cases after snapshot upgrade (radeonrdrm related?)
Problem solved [1]. Thanks jsd@ [1]: https://www.marc.info/?l=openbsd-tech&m=144984739021388&w=2 On 12/11/15 16:19, Alexis de BRUYN wrote: Hi Everybody, After upgraded from snapshots/amd64 12/09/2015 (previous was 12/04/2015), Puffy is blurred on xdm login screen (like [1]). Puffy (/etc/X11/xdm/pixmaps/OpenBSD_15bpp.xpm) displayed in feh is fine [2], while in eog is blurred [1]. Pictures/thumbnails displayed and all icon buttons in/of Thunderbird, Firefox [3], Libreoffice, Evince (some texts too if zoomed)... In Chromium [4], Gajim and Minitube, all is displayed fine. After this upgraded I also have another issue [5]: radeon_ring_test_lockup / radeon_sa_bo_manager_fini *ERROR* Today's snapshot sets and packages upgrade doesn't correct the problem. (fresh dmesg and Xorg.0.log below) -- Alexis de BRUYN
