Re: acme-client(1) and http_proxy
> I haven't seen anyone mention acme.sh yet--a shell script for > letsencrypt with no external dependencies. > > https://github.com/Neilpang/acme.sh No external dependencies, and no security foundations. No privsep, no clear seperation. Using pretty much every unsafe pattern tied to security holes in the past. Using the openssl command *GO READ THAT CODE SOMETIME*, don't go read the libressl one, go read upstream openssl command source. No attempt at security. Just doing the job, and assuming every mistake later can be It's like constructing jetliners from foundational components, and by that I mean sticks and stones. I'm sorry, but I don't get it. It is crazy to recommend something that hasn't been STUDIED to ensure it dutifully tries to only perform the task and creates no new risk.
Re: acme-client(1) and http_proxy
> acme.sh does not require root/sudoer access. For sure I run it as an > unprivileged user and hope you do as well! The concept of privsep isn't about running as an unprivileged user. It is so much more. The problem is that unprivileged users still have the full system call interface available to them. Ignoring that reality -- in these trying times -- is like living in a cave. Don't care where you run such software. But suggesting it to others as a quality choice is irresponsible.
Re: torrent downloads
> Christoph R. Murauer wrote: > > True but let me be a littlebit paranoid. Would it not be possible to create > > a new .fs / .iso with new keys in /etc/signify/* and new SHA256 / .sig > > files to place bad content and distribute it using a torrent ? I came > > across this idea as I readed long time ago some ideas how goverments could > > distribute the here in Europe called trojan of the state (Staatstrojaner). > > Don't verify with the key inside the thing you're veriyfing. There is some > difficulty bootstrapping from nothing, but that's life. Correct. And Christoph, you may have noticed I stopped making official CDs which did solve that particular problem. It was too much of a pain for the gain. This feels like a request to handle all this pain for torrent people. I stopped the build process for CDs because it was a lot of work for almost no financial gain, and a distraction against other things I'd rather do. Now I'm supposed to continue doing the same, for no gain at all? Allow me to express my disinterest. As Ted said. Bootstrapping problem is bootstrapping problem.
Re: pledge from command line
That is not possible. pledge only works on behalf of a process itself. In the simplest case, a call to pledge is done between the first part of a program "initialization" and the second part of a program "main loop". It serves no purpose if done earlier, and as you noted execve resets pledge, to serve the large variety or programs which are "shells" or have selective behaviours where they "shell-out". > I would like to have pledge on the command line so I can restrict an ad-hoc > process during execution. For example: > > $ pledge "stdio" sed -e "s/foo/bar/g" output.txt > > I can't modify sed, for example, because I don't always want it pledged > that tightly. Since execve removes pledges, I can't see a way to write > this pledge utility myself. Is it possible? Is there a better way to > impose these kinds of ad-hoc restrictions on a utility? > > Thanks.
Re: pledge from command line
> Michael Hendricks wrote: > > I would like to have pledge on the command line so I can restrict an ad-hoc > > process during execution. For example: > > > > $ pledge "stdio" sed -e "s/foo/bar/g" output.txt > > > > I can't modify sed, for example, because I don't always want it pledged > > that tightly. Since execve removes pledges, I can't see a way to write > > this pledge utility myself. Is it possible? Is there a better way to > > impose these kinds of ad-hoc restrictions on a utility? > > sed can (should?) reduce the set of permissions after it determines that input > and output are streams. in fact, it can do so after opening any required > files. Right. Ted is pointing out sed does this itself. Read my previous mail on "initialization" vs "mainloop", then go look at the code in main.c That is the groundbreaking idea behind pledge -- that a program itself knows when to instantiate policy for future instructions.
Re: pledge for sockets
> I can imagine pledge(2) becoming very complex if individual ports are > blocked. It is not just the syscall, it's also the code in the > kernel. From what I can gather, pledge is really to restrict processes > to a subset of functions available, rather than restricting each > individual argument, unless there are exceptional reasons for doing so. > > However, out of curiosity I've been tinkering with PF rules. > > Ruleset: > > block drop all > pass in proto tcp from any to any port 65535 user test2 > > Then running as user "test" (NOT test2): > > $ nc -l 65535 > > Note nc stays there, probably opened the socket successfully. > > Even with "block reset all" in PF rules, nc does this. > > It would be nice if the "reset" keyword tells the kernel to return > EACCES when bind(2) is called on a port blocked by PF rules for a > particular user. You really haven't got a clue.
Re: 6.1 syspatch installed SP kernel on MP system
> Seems like syspatch should install new /bsd.sp and /bsd.mp and then link > /bsd to the correct one based on whether sp or mp kernel is running. This > would be consistent with the installer. You are pretty sure of yourself, but that isn't what the installer does. It does not "link". You can go read the source.
Re: syspatch on diskless fails (stat -qf %Sd / issue)
> After a bit of investigation, I found that it was becasuse the unpriv > shell function generated an error upon invoking su: > > su: approval failure: Undefined error: 0 > > Is there no way to run syspatch in a chroot either? No. And that's just plain crazy.
Re: openssl/libressl ocsp error in 6.1 stable
> I noticed in my logs things like this. > May 1 03:00:02 isildur openssl: vfprintf %s NULL in "%s %2d > %02d:%02d:%02d%.*s %d%s" > > It comes down to this command to fetch ocsp response: > openssl ocsp -respout ocsp.der -no_nonce -issuer chain.pem -cert > cert.pem -url http://ocsp.int-x3.letsencrypt.org -header "HOST" > "ocsp.int-x3.letsencrypt.org" -verify_other chain.pem -rother chain.pem Fixed a month ago. revision 1.28 date: 2017/04/03 15:52:59; author: beck; state: Exp; lines: +2 -2; commitid: SfEldwG3FeZUMrhN; Fix silly code that printfs NULL when there are no fractional seconds on a GENREALIZEDTIME (which there should really never be for anything remotely standards compliant) ok jsing@
Re: OpenBSD/octeon and "OpenBSD/patches/6.0/common/002_perl.patch.sig"
>In patch "OpenBSD/patches/6.0/common/002_perl.patch.sig" I've found >references to two paths that appear to not exist in OpenBSD/octeon: > >* /usr/libdata/perl5/octeon-openbsd/5.20.3/IO >* /usr/libdata/perl5/octeon-openbsd/5.20.3/IO/Socket > >Instead, there are: > >* /usr/libdata/perl5/mips64-openbsd/5.20.3/IO >* /usr/libdata/perl5/mips64-openbsd/5.20.3/IO/Socket > >The following change seems to resolve this issue, at least on octeon and >i386: > >-/usr/libdata/perl5/`machine`-openbsd/5.20.3/IO >+/usr/libdata/perl5/`arch -s`-openbsd/5.20.3/IO > >-/usr/libdata/perl5/`machine`-openbsd/5.20.3/IO/Socket >+/usr/libdata/perl5/`arch -s`-openbsd/5.20.3/IO/Socket Strange noone else noticed this for so many months. Anyways, it is not that important. I won't reroll a 6.0 errata for something so minor. We'll keep an eye out for next time.
Re: syspatch ideas
>2) Notion of transactions > >Often, more patches are installed at once, with the single `syspatch` >command. One might want to be able to revert all those patches at once >as well. A notion of transactions could be made by adding a notion >of transactions, but that would add more unnecessary complexity. > >It can be solved simpler way, by adding the line with the list of >patches applied, e.g. > > # syspatch > Installing patch 005_pf_src_tracking > Get/Verify syspatch61-006_libssl.tgz 100% |*| 2276 KB00:04 > Installing patch 006_libssl > Get/Verify syspatch61-007_freetyp... 100% |*| 732 KB00:01 > Installing patch 007_freetype > Missing set, skipping patch 007_freetype > Patches applied: 5,6 > >and by adding support for -r optional argument, which could be comma separated >patch number list. That is incorrect. The usage situations are no patches, or all of the patches, or a subset and you are about to install to get more /all of them. You don't get to choose which you want, unless all newer ones are ripped out also. We don't manage dependencies. This tooling is designed to make errata handling EASY FOR US. Otherwise, we would not bother building this service.
Re: syspatch ideas
>On 2017-05-15 Mon 01:31, Theo de Raadt wrote: >> >2) Notion of transactions >> > >> >Often, more patches are installed at once, with the single `syspatch` >> >command. One might want to be able to revert all those patches at once >> >as well. A notion of transactions could be made by adding a notion >> >of transactions, but that would add more unnecessary complexity. >> > >> >It can be solved simpler way, by adding the line with the list of >> >patches applied, e.g. >> > >> > # syspatch >> > Installing patch 005_pf_src_tracking >> > Get/Verify syspatch61-006_libssl.tgz 100% |*| 2276 KB >> > 00:04 >> > Installing patch 006_libssl >> > Get/Verify syspatch61-007_freetyp... 100% |*| 732 KB >> > 00:01 >> > Installing patch 007_freetype >> > Missing set, skipping patch 007_freetype >> > Patches applied: 5,6 >> > >> >and by adding support for -r optional argument, which could be comma >> >separated >> >patch number list. >> >> That is incorrect. >> >> The usage situations are no patches, or all of the patches, or a >> subset and you are about to install to get more /all of them. You >> don't get to choose which you want, unless all newer ones are ripped out >> also. >> >> We don't manage dependencies. >> >> This tooling is designed to make errata handling EASY FOR US. Otherwise, >> we would not bother building this service. >> > >Here i agree. > >If not providing easy ability to revert arbitrary list of patches, what about >handle "transactions" or "syspatch sessions" or "patchsets" internally: > >After successful application of patch(es), create >/var/syspatch/patchset.$TIMESTAMP >with list of applied patches (line by line). > >Reverting the last patchset would be reverting the patches from the last >patchset file, and removing that file. You haven't justified need. They are either installed, or not, and existence of files and directories already indicates the patchlevel.
Re: syspatch ideas
>On Mon, May 15, 2017 at 08:36:21AM +, Michal Bozon wrote: >> I think the justification is: >> >> Why do i even need to revert a patch? Only because something got broken >> by the last syspatch command, that may have applied multiple patches. >> I might not now which patch caused the problem. >> >> If the problematic patch was not the last one from the set, >> reverting with -r does not help, because it reverts single last patch only. >> >> Well, applying `syspatch -r` repeatedly is a sort of solution as well. > >scratching head. > >well, we're talking patches on top of *stable*. >The release is originally rather well tested. >patches on top of that are applied conservatively, only to fix actual >issues. > >I would really start worrying about our process if you actually need >to 'revert patches until you find out which one causes the problem'. Exactly. If a syspatch sequence doesn't apply to your virgin system, then your system isn't virgin and all bets are off, sorry you screwed it up. This system is intentionally simple, to create robustness via simplicity. I think you are being critical because you think it is amusing.
Re: thinkpad x270
> I was planning on buying one but was waiting to see what the feedback was. > > Any other issues other than the resume? If I had one I would probably work on the resume the iron I carry around is getting a little dinged.
Re: mips64el packages deprecated?
> On Fri, May 05, 2017 at 09:34:57PM +, Christian Weisgerber wrote: > > On 2017-05-05, Roland Kammerer wrote: > > > > > Today I upgraded to OpenBSD 6.1 and saw that none of the mirrors seem to > > > contain packages for mips64el anymore. > > > > > > Are they still building? > > > > Yes. > > Are we there yet? Are we there yet? ;-). I think for the last 5 or so > releases I updated pretty soon after the official release, so this looks > new... The release process worked different when CDs were being manufactured. The tree was locked way before release day, approximately 5-6 weeks. Base builds were completed, then CDR were created and sent to the plant. Manufacturing tended to take around 3 weeks. During that time, the slower architectures would get caught up on building packages, and be ready in time for release day. Since there is no manufacturing holdup anymore, I have decided we'll release OpenBSD as soon as "most important stuff is done". That is all bases, plus packages for 2-4 important architectures. That means packages for slower architectures will arrive whenever they are finished. This will be evaluated each release. This new model is better for developers, myself included of course. > I once donated a ppc g4 mac mini to some openbsd dev. If it helps, I > could donate my loongson box. Just let me know. The mips64el packages are built on a cluster of 4 loongson machines. The machines are small, it could use a larger cluster maybe, but 1 machine won't make much difference. Hopefully a faster system with the same architecture shows up in the future.
Markus Uhlin
I am being harrassed by a guy called Markus Uhlin. https://github.com/uhlin?tab=following By sending this mail, I'm hoping he comes to understand I am fed up.
Re: No 008 patch on ftp.eu.openbsd.org yet
That mirror is updating way too slow. > I had to switch to ftp.openbsd.org to get the 008 patch for -stable > since my preferred mirror, ftp.eu.openbsd.org, doesn't seem to be > updating. The timestamp file says last update was run on 1495188001 > (Fri May 19 12:00:01 CEST 2017). > > There is no contact address in > https://ftp.eu.openbsd.org/pub/OpenBSD/README so I'm hoping that someone > who know someone who knows how the mirroring is performed will spot this > and get them to fix it. > > I would also be interested in knowing how often this mirror is > *supposed* to update (usually it's something like every two hours, > right?). > > > > Regards, > Kusalananda >
Re: isakmpd dies quietly with over 100 tunnels
Great thing is you all have source code, and can run the same debuggers live in your key-happy situations, and then generate traces to expose the problem so that someone can help you. But, yet, that doesn't happen. Strange isn't it?
Re: macbook only sees 3GB of ram
1. it works, be happy. 2. the memory map from the bios is being honoured; the kernel makes conservative decisions to honours it, as a result it works. see 1. 3. if you want to drill down further and get access to more memory, you have the source code AND the hardware. 4. if you don't want to drill down, but just want to bitch, sorry noone cares enough to do anything about this without the hardware, so go get a padded box for it and maybe we can find a developer who will take the machine off your hands. > On May 31 08:48:09, h...@stare.cz wrote: > > This is current/amd64 on an old MacBook A1181 (dmesg below). > > Until yesterday it had 2+1 GB of RAM, now it has 2+2 GB. > > However, dmesg still reports around 3GB. > > > > No, it's not the old dmesg; yes, I have checked. In fact, > > spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM > > spdmem1 at iic0 addr 0x52: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM > > > > It's not a hardwware issue - the MacOS that dualboots this machine > > sees and uses the 4GB. Am I missing something obvious? > > > > OpenBSD 6.1-current (GENERIC.MP) #0: Sat May 20 12:31:37 CEST 2017 > > h...@macbook.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 3171909632 (3024MB) > > avail mem = 3070050304 (2927MB) > > Here is a fresh upgrade to the latest snapshot > - the issue is the same. > > > OpenBSD 6.1-current (GENERIC.MP) #87: Tue May 30 21:05:25 MDT 2017 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 3171909632 (3024MB) > avail mem = 3070050304 (2927MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (37 entries) > bios0: vendor Apple Inc. version "MB21.88Z.00A5.B07.0706270922" date 06/27/07 > bios0: Apple Inc. MacBook2,1 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT > acpi0: wakeup devices ADP1(S3) LID0(S3) PXS1(S4) PXS2(S4) USB1(S3) USB2(S3) > USB3(S3) USB4(S3) USB7(S3) EC__(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz, 2161.59 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR > cpu0: 4MB 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 166MHz > cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz, 2161.26 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR > cpu1: 4MB 64b/line 16-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 addr 0xf000, bus 0-255 > acpiec0 at acpi0 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 1 (RP01) > acpiprt2 at acpi0: bus 2 (RP02) > acpiprt3 at acpi0: bus 3 (PCIB) > acpicpu0 at acpi0: !C3(100@55 mwait@0x31), !C2(500@1 mwait@0x10), C1(1000@1 > mwait), PSS > acpicpu1 at acpi0: !C3(100@55 mwait@0x31), !C2(500@1 mwait@0x10), C1(1000@1 > mwait), PSS > acpisbs0 at acpi0: SBS0 model "ASMB016" serial 19351 type LION oem "DP" > acpiac0 at acpi0: AC unit online > acpibtn0 at acpi0: LID0 > "APP0002" at acpi0 not configured > acpibtn1 at acpi0: PWRB > acpibtn2 at acpi0: SLPB > "APP0001" at acpi0 not configured > "APP0003" at acpi0 not configured > "ACPI0001" at acpi0 not configured > acpivideo0 at acpi0: GFX0 > cpu0: Enhanced SpeedStep 2161 MHz: speeds: 2167, 2000, 1833, 1667, 1500, > 1333, 1000 MHz > memory map conflict 0xbef0/0x10 > memory map conflict 0xbf00/0x100 > memory map conflict 0xf00f8000/0x1000 > memory map conflict 0xfed1c000/0x4000 > memory map conflict 0xfffb/0x3 > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03 > inteldrm0 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03 > drm0 at inteldrm0 > intagp0 at inteldrm0 > agp0 at intagp0: aperture at 0xc000, size 0x1000 > inteldrm0: apic 1 int 16 > inteldrm0: 1280x800, 32bpp > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) > wsdisplay0: screen 1-5 added (std, vt100 emulation) > "Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured > vendor "Intel", unknown product 0x27a3 (class DASP subclass Time and > Frequency, rev 0x03) at pci0 dev 7 function 0 not configured > azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
Re: nc in inetd - under which account?
> For a few years I have been running nc from inetd together with pf > redirect rules to reach LAN servers via their public IP adresses from > LAN: > > # cat /etc/inetd.conf > 127.0.0.1:20080 stream tcp nowait proxy /usr/bin/nc nc -w 20 PR.IV.AT.E 80 > 127.0.0.1:20443 stream tcp nowait proxy /usr/bin/nc nc -w 20 PR.IV.AT.E 443 > > Now that proxy user is gone in 6.1, what would be appropriate account to > run nc under? Is nobody OK? Something else? > > Or is there a better way to accomplish this? A user of your own you create. Never reuse a user intended for another purpose. Take a glance at the ptrace manual page.
Re: blank screen
> is somebody messing with the graphics stack by any chance? It is probably rude to call steps-being-taken-toward-progress "messing"
Re: blank screen
> On Sun, 11 Jun 2017 09:42:15 -0600 > "Theo de Raadt" wrote: > > > > is somebody messing with the graphics stack by any chance? > > > > It is probably rude to call steps-being-taken-toward-progress "messing" > > > > > > I am sorry - this wasn't meant to be as insult to anyone. As far as I > know 'messing' is used in english as well for a more colloquial speech > of saying 'somebody is changing things' - But what do I know - it is > not my primary language. > > So please let me rephrase it. > > Is somebody currently doing changes to the graphics stack? I would like > to report a problem because those possible changes might have a > negative impact on my system. For about a week, snapshots have contained a prototype of the new inteldrm codebase. Thereby allowing people to report issues. But saying "messing" really isn't helping. A detailed bug report helps. 1 line of whining doesn't. Noone said snapshots would always work for everyone all the time.
Re: dokuwiki - /dev/urandom issue
> Asbel Kiprop wrote on Sun, Jun 11, 2017 at 09:24:23PM +0300: > > > cat: /var/www/dev/urandom: Device not configured > > By default, /var is mounted nodev. See mount(8), fstab(5). Providing a workaround that reduces security is a poor answer. Perhaps the drive to make-it-work inevitably overrides the desire to do right. Also, you could "cp /etc/passwd urandom" and it will work fine also! Safety, good lord who cares. The port should be fixed, so that it internally use arc4random. The "nodev" option is used for some good reasons.
Re: inquiring about setting wxallowed on /home mountpoint
> So my question is, will there be any security implications that I > should be concerned about with setting wxallowed in /etc/fstab to the > home mountpoint? Yes there is a security implication. From mount(8), wxallowed Processes that ask for memory to be made writeable plus executable using the mmap(2) and mprotect(2) system calls are killed by default. This option allows those processes to continue operation. It is typically used on the /usr/local filesystem. That will allow this program to do create such memory. It will also allow any other program in your /home to do so. We don't know what other programs you might have in /home. That's why this feature was designed to operate in this restrictive way. In a perfect world, software would stop asking for W|X memory. We aren't there yet. This mechanism softly applies pressure towards that end. Turn it off and accept the consequences, and potential risks if you like. W|X memory isn't the only risk out there...
Re: inquiring about setting wxallowed on /home mountpoint
> However, the convenience of just installing packages is then lost. > After a discussion on IRC, a couple of ways to deal with this came up: > > 1. add a non-USE_WXNEEDED flavour of the python port > > 2. have the python port(s) ship two binaries (one with, one without >OPENBSD_WXNEEDED) > > 3. allow running binaries that have the OPENBSD_WXNEEDED header from >non-wxallowed filesystems, but simply kill them once they try W|X 4. Roll up sleeves and fix the issue.
Re: Doubling in Size of base61.tgz
> Please forgive me if this has been noted on misc@, as I've overlooked > it, but, just out of curiosity, can anyone account for the recent > doubling in size of base61.tgz in recent amd64 snapshots of -current? > > As recently as 7 June, it was ~58 MB in size, but over the last couple > of days at least, it has ballooned to nearly 120 MB in size. None of the > other tarballs seem to have changed much at all. KARL creates a new /usr/share/compile.tgz file, which is expanded to /usr/share/compile/GENERIC.MP directory at first boot that is the new space, a link kit The .o's are compiled with -ggdb, and that may shrink in the future if someone provides glue to shrink-down the .o files
Re: Kernel relinking not working after upgrade to latest snaphot
This is intentional. But the script /etc/rc may not be working exactly as intended yet. rpe, tb and I are still iterating this, and also attempting to satisfy the unhibernate case which requires booting the original kernel. The intent of the hash is so that a developer can build their own kernel from elsewhere. Upon the next boot, it will notice that that the hash is different. This means the developer is testing their own kernel, and does not want auto relinking to occur. However if the hash matches then /bsd is under system management, and can be relinked. Finally, if there is no hash file, this was an install or an upgrade, and it can go into this managed-mode where it auto relinks at boot. You can also make it relink on future boots by deleting the hash file. As you can tell we're trying to find a happy middle ground between automatic safety, and developers being in control of their own machines. There is also a bootblock change coming, to assist unhibernate. > After upgrading to the latest snapshot I noticed that the kernel is no > longer relinked on boot. The cause seems to be that the SHA256 checksum > doesn't match the kernel. > > # cat /usr/share/compile/GENERIC.MP/SHA256 > SHA256 (/bsd) = > bfcce01e68e62cc5d9666096206492be3f5c310e9711f2a14ac9c75e279585a1 > > # sha256 /bsd > SHA256 (/bsd) = > 10da3cee5c0bf44ce9182b2603be46b2adfc200222ca74d169691f79750bd05b > > # sysctl kern.version > kern.version=OpenBSD 6.1-current (GENERIC.MP) #13: Thu Jun 15 19:34:58 > MDT 2017 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > Is this on purpose or an error on my side? > > Kind regards, > > > Martijn Rijkeboer > > >
Re: Fwd: Boot issue 6.1
> I get the error Message that "installboot: /mnt/usr/mdec/biosboot extends > Beyond sector 268435455. OpenBSD might not boot." I'm dual booting with > Windows using Windows' boot loader first. You've created an OpenBSD MBR partition too far up your disk. It won't work in legacy mode. The BIOS won't be able to read it. You can try EFI mode instead.
Re: bug tracking system for OpenBSD
> Kai Wetlesen wrote: > > What would a potential curator of a bug tracker need > > to do besides spin up a server, install, and maintain > > the chosen (or written) software? > > not underestimate the effort involved. > > so this has come up before, and the answer remains the same. anyone can setup > a bug tracker, and feed bugs into it. close the ones that get fixed, > categorize the rest, etc.. do that for a few months and see how it goes. > > i'm not really interested in looking at an empty bug database. nor one that's > filled with crap. so yeah, there's a bootstrapping problem. > > you don't have to announce your bug database the first day you set it up. in > fact, it's better not to. but in a few months time, when somebody inevitably > asks misc how do i contribute, where's the todo list, you'll have this handy > list of unresolved bugs to point them at. > > like a lot of projects that seem really easy, you'd think somebody would just > do it if it were that simple. but the idea that nobody wants to chance > investing time in a deadend project suggests they kind of know the time > investment isn't just a saturday afternoon. > Indeed, this thread is full of volunteers, isn't it? Why haven't one of you already started doing it? (not including Ted, Ingo, or Antoine, or myself)
Re: Get an MAC address of a LAN PC - OpenBSD
> Hi Raul, > > I am very glad your effort to support me since I DO NEED to get an MAC of > an OLD PC. > > This PC was removed from the network last week. > > unfortunately "arp -a" does NOT give the MAC of that PC. > > I am running darkstat as well. It also does NOT give it either. I think > This pf box has been rebooted after removing that PC. > > no idea what to do? Plug it back in. Power it up. Make sure it has a reachable IP. Ping it. If you don't understand how computers and networking work, I'm sure you can find another job. Not everyone is suited to every role. For example, I'm not very good at explaining simple concepts to people who don't get it.
Re: Get an MAC address of a LAN PC - OpenBSD
> > > no idea what to do? > > > > Plug it back in. Power it up. Make sure it has a reachable IP. Ping > > it. > > > > very sorry. It is prohibited to plug it back in and power it up. > > To do it, We might need a special request. > > Theo, Anyway, thanks for you support. Another solution is to smash that device with a hammer. Repeatedly. Don't stop before you are sure it is destroyed. Then it has no MAC address. Later, if you search the world, you won't find it's MAC address. Eventually through exhaustive search you might be able to make a good guess as to what the MAC address was. Did that help?
Re: Get an MAC address of a LAN PC - OpenBSD
> Another solution is to smash that device with a hammer. Repeatedly. > Don't stop before you are sure it is destroyed. > > Then it has no MAC address. > > Later, if you search the world, you won't find it's MAC address. > > Eventually through exhaustive search you might be able to make a good > guess as to what the MAC address was. > > Did that help? Some of you will think this is a total joke. This has previously used to assure global unique MAC. I suspect Indunil has the same problem. Or, he's begging for help to do something kind of extra-judicial...
Re: upgrading release -> snapshot [was: Re: Characters of various Asian languages not rendering correctly in Firefox and Chromium]
> On 06/22/17 23:11, Stuart Henderson wrote: > > These warnings mean something like: "don't move straight from a release > > or an older snapshot directly to building new code from source (whether > > that's -current or a newer release)". > > > > If there is much of a gap between the version you're running and the > > version you want to move to, boot the install kernel from a recent > > snapshot and 'u'pgrade to that, then boot and upgrade all packages > > (pkg_add -u). > > Thanks, that answers my question nicely. Perhaps in faq/current.html after: > > "You should always use a snapshot as the starting point for running > -current. Upgrading by compiling your own source code is not supported." > > should be added: > > "You can upgrade from the most recent release to a snapshot using the > snapshot's installer." Not so sure. I think your proposal would make the page vague. The title of the page you are taking that from is: Following -current and using snapshots If you are doing that, the advice is clear and exact. Anyone participating in -current or following snapshots knows this information is for them. For others folk, this information isn't for them. It is for people subscribing to following the development process earnestly. People who don't already understand that model and the upsides/downsides from reading rest of the FAQ should probably not be encouraged since their self-help methodology will be weak and overwhelm the mailing lists. Overdocumenting isn't a strength.
Re: Get an MAC address of a LAN PC - OpenBSD
> If the user of that PC spoofed the MAC address, What does arp -a show in > OpenBSD ? It shows in:du:ni:l0:00:01 Every time.
Re: ipmi driver broken
> Anyway, thanks for the thoughts; but I do still want a working ipmi :). > No biggie to add one line and recompile the kernel, but it would be nice > to get fixed. It's still disabled by default out of the box, you have to > explicitly reconfigure your kernel to enable it. If you want it working, you will need to get it fixed. On all machines, so that we can renable it. Or the process you just described will go terribly wrong soon. Let me explain how we work. When we disable something -- as ipmi was handled -- it means we have give up on trying to fix it. This code was locking up some machines and noone cared enough to find the problem and fix it permanently. However, if code is disabled it also means people suddenly aren't using it, being exposed to the bug, and caring about it. Obviously a majority of users don't use this code. Also that means a majority of developers aren't using it. I'd say that number is ZERO. So in more than 5 years, noone has arrived to take care for it. But someone needs to care for every piece of code in our tree. Indications are noone will take care of ipmi.c So before long, the tedu will arrive with his scythe and take the code to the other world. I predict it won't be long before the code we don't use, don't maintain, and which noone else maintains is gone. Actually, this may summon the tedu...
Re: ext2 or usb problem
> This is not helpful. You insist that you know what is going on when I > was in front of the computer and you were not. File copying to an ext2 > filesystem on a usb drive is 10x slower than to an ffs filesystem on > an internal sata drive mounted async (ext2 is async; apples to > apples). I know because I've measured it, including the time to sync. > The file in question was 1.5 GB. That copy should have taken 150 > seconds or so at the rates I measured. The system sat there for two > hours, as I said in my message. And when I came back, it was making no > progress, as I also said in my message. I'm done discussing this. I've > reported what I found and offered to help debug it. My workaround is > simple: I will do these backup disk updates and anything else > involving ext2/usb disks with Linux. Then why all the angst? If you really wanted it fixed you have the src code. Yelling at people isn't helpful either, is it?
Re: ext2 or usb problem
> On 2 July 2017 at 13:54, Theo de Raadt wrote: > >> This is not helpful. You insist that you know what is going on when I > >> was in front of the computer and you were not. File copying to an ext2 > >> filesystem on a usb drive is 10x slower than to an ffs filesystem on > >> an internal sata drive mounted async (ext2 is async; apples to > >> apples). I know because I've measured it, including the time to sync. > >> The file in question was 1.5 GB. That copy should have taken 150 > >> seconds or so at the rates I measured. The system sat there for two > >> hours, as I said in my message. And when I came back, it was making no > >> progress, as I also said in my message. I'm done discussing this. I've > >> reported what I found and offered to help debug it. My workaround is > >> simple: I will do these backup disk updates and anything else > >> involving ext2/usb disks with Linux. > > > > Then why all the angst? > > > > If you really wanted it fixed you have the src code. Yelling at people > > isn't helpful either, is it? > > If you consider this 'yelling', then you really need to consult a > dictionary. And you are a fine one to be lecturing anyone about > yelling. Look, you don't get to lecture developers who are trying to help. Please leave here.
Re: vesa vs. wsfb?
> I went with wsfb because it doesn't need allowaperture. Any other > differences? > > > PS: The FAQ is silent on this topic. I had to dig through old > mailing list posts for a reminder to enable allowaperture. > I knew there was a wscons-based driver, too, but if you don't > know the exact name, wsfb(4) is hard to find. I think the FAQ is silent because this is an intermediate step, and we thought we'd be over this hump sooner...
Re: Security report with mail permissions
>Hi Mik, > >not quoting anything because your posting is too ill-formatted. > >Yours is a frequently answered question. The directory /var/mail/ >is intended for individual user mailboxes. If you need a directory >for a different purpose - like mailbox subhierarchies for virtual >domains - create a different directory. > >If you want to do daily checks on that different directory checking >for a different format, implement your own checks in daily.local(8). That is the correct answer. The files in /var/mail already have some pretty tricky locking requirements, so there is no way we're going to encourage placement of other objects in there.
Re: Best place for VM images
> I've been putting mine in a dedicated partition. /var/vmm should probably > be its own partition if used. > > nodev, nosuid are probably good choices there too. That won't work. People without an additional partition will get these mount options. And anyways those system flags don't make any sense for such controlled files. Anyways, this stuff should not be in /var at all! /var/ Multi-purpose log, temporary, transient, and spool files. Note the word transient. These vmm images people are creating are for their own use, and I don't think they should be anywhere near a system directory, let alone the system directory /var. I'd suggest /home/vmm as a good place to store them.
Re: Verified auth tty ioctl()s implementation details
> On 2017-07-18, multiplex'd wrote: > > Thank you for explaining; I suspected the reasoning was such. Speaking > > specifically > > about ports, is there a way to start a port build as root and then drop > > priviledges > > (in a similar manner to the base system's build infrastructure)? A quick > > glance > > through bsd.port.mk(5) suggests that this isn't (yet) possible. (A possible > > workaround > > is to run "make fetch" as a normal user, "make prepare" as root and "make > > build" as > > normal user etc, however if there are dependencies which need to be built > > at the "make > > prepare" stage then they are built as root.) > > dpb(8) handles this automatically, but it's a pain when you're starting > work on a new port from scratch especially if you don't have a > particularly clean ports tree. This ran into the same problem as base system builds: it isn't terribly difficult to build a de-escalation mechanism into a large infrastructure from the top-down, but it is much harder to build it for the internal elements. cd /usr/src/bin/ls; make. No de-escalation occurs. But in some ways that matches the development process, so that is OK.
Re: Best place for VM images
> Sure. I don't have a really strong opinion one way or the other. When I > mentioned I put mine in a dedicated partition, I use /data/vmm or various > places in /home if I've already fully partitioned the machine in question. I don't think a seperate partition is neccessary. However I think this should stop saying /var/anything right away, because that is leading people in the wrong direction.
Re: Verified auth tty ioctl()s implementation details
> > Now, I am running on the assumption that these ioctl()s were > > implemented as a kernel-side component of doas's "password timeout" > > functionality as observed when using the "persist" configuration > > keyword. From that, my question is whether there is any particular > > reason for recording the parent process ID in particular as part of > > the cookie stored by the persistent authentication ioctl() as opposed > > to the process group ID of the calling process's session leader, as > > with sudo. > > Yes, the difference is intentional. For pretty much exactly the reason you > noticed, although perhaps with the opposite result. A successful > authentication is not meant to be inherited by any random program or script > you run. A) because vague security concerns, but also B) because I think it's > weird that a script maybe works if it runs fast enough, but fails if it takes > five minutes to get to doas. Like "make; doas make install" works on a fast > machine but fails unexectedly on a slower machine. i'd like to point out that doas+kernel semantics are intended to be stronger than what sudo does. And if some finds a way for the kernel to become more strict (further tie-in to process groups maybe?) then we could do that easily and gain the security, as long as there is no further loss in functional use.
Re: OT: protonmail mail body
> On Wed, 12 Jul 2017, Mihai Popescu wrote: > > > Hello, > > > > I preffer to keep it calm, but some people on the list are using > > protonmail and their mails are impossible to read directly on the > > list. I think they are destroying the list, maybe they should turn > > that feature off. Here is what I see reading on marc.info: > > > > TmV2ZXIgaGVhcmQgb2YgVk5DPwpTZW50IGZyb20gUHJvdG9uTWFpbCBNb2Jp > > bGUKCk9uIFR1ZSwgSnVsIDExLCAyMDE3IGF0IDg6MzkgUE0sIE5pZWxzIEtv > > YnNjaMOkdHpraSA8bmllbHNAa29ic2NoYWV0emtpLm5ldD4gd3JvdGU6Cgo+ > > IEhpLCBJIGFtIHBvbmRlcmluZyB0byBpbnN0YWxsIE9wZW5CU0Qgb24gbXkg > > bWFpbiBtYWNoaW5lLiBCdXQgSSBqdXN0IGZvdW5kIGEgcG9zc2libGUgc2hv > > d3N0b3BwZXI6IGZhbWlseSByZW1vdGUgc3VwcG9ydCBSaWdodCBub3cgSSBh > > bSB1c2luZyBUZWFtdmlld2VyIHRvIGNvbm5lY3QgZnJvbSBteSBMaW51eC1t > > YWNoaW5lIHRvIHRoZSBmYW1pbHktTWFjLiBOb3cgSSBhbSBzZWFyY2hpbmcg > > YSBzaW1pbGFyIGVhc3kgd2F5IHRvIGRvIHRoYXQgZnJvbSBhIHBvc3NpYmxl > > IE9wZW5CU0QtbWFjaGluZS4gSXMgdGhlcmUgYW55IHNvZnR3YXJlIHRoYXQg > > Y291bGQgZG8gdGhhdD8gQXNraW5nIHRoZW0gZm9yIHRoZWlyIElQIG9yIGlD > > bG91ZC1ob3N0bmFtZSB3b3VsZCBhbHJlYWR5IGJlIHRvbyBjb21wbGljYXRl > > ZC4gV2hhdCBhcmUgeW91IHVzaW5nIGluIHN1Y2ggY2FzZXM/IElzIGEgUUVN > > VS1WTSBwZXJmb3JtYW50IGVub3VnaCBmb3Igc3VjaCBhIHRoaW5nIChJIGhh > > dmUgYSBUaGlua3BhZCBUNDYwIHdpdGggYSBTa3lsYWtlLWk1KSBOaWVscw== > > My primary e-mail address is on protonmail. For testing purposes, I have > sent e-mail from my protonmail account to a number of other accounts and > have never had any problem reading the messages. For example, on this > account I use pine (alpine) to handle my e-mail and have never had a > problem. If I see a mail which isn't plain text, I delete it. If that means something doesn't get handled, bummer.
Re: OT: protonmail mail body
> As things stand, ProtonMail is not a suitable client for writing to this > mailing list. > > Your messages are nearly unreadable. Maybe it should be blocked. Then the users there can tell them to fix it. Would have no downside for me.
Re: ntpd clock unsynced in vm
> If your clock drift is worse than that, your clock is broken. Which > alas is the case for vm. I agree with this statement. About 20 years ago, I defined the minimum system we attempt to run well on as IPL32 or I32LP64, with a MMU. Soon this was redefined as with an FPU as well, after which I observed valiant painful efforts to do softfpu on arm, causing much grief and pain and showing that FPU is needed. A while back we realized that a proper RTC is mandated. Some people still want to accept cheap hardware sold without an RTC. Those people will learn their lesson. At present, vmm is also weak in this area, not regarding the RTC, but regarding syncronous clock deliver. Mike will fix that eventually.
Re: syspatch glitch
> It seems syspatch looks at the current machine capabilities instead of > which kernel is running when it decides on if /bsd is /bsd.sp or /bsd.mp. > > I tried to install OpenBSD 6.1 to a USB connected CF card that later will > run in an alix2d13 that has got one core, but I did the installation from > a laptop with two cores. Both i386. > > Then I moved /bsd to /bsd.mp and /bsd.sp to /bsd since the installer had > detected that the install machine should run /bsd.mp. > > After that I ran syspatch, still on the laptop, and it failed on patch 002 > with as I remember tar complaining on not being able to find /bsd.sp. > > Restoring /bsd to /bsd.sp and /bsd.mp to /bsd allowed me to syspatch the > installation, and after that it seems both /bsd (.mp) and /bsd.sp are > patched, so I can hopefully change the kernels just before putting the CF > card in the Alix instead, so no harm done. > > But is it by design that syspatch looks at the running machine instead of > the running kernel? I would have expected it the other way around... Yes, it is by design. You are not following the normal pattern. When you do something strange, you own the consequences. Software often doesn't handle all the cases, and I think it is wrong to accuse it for not satisfying your specific needs in a strange usage pattern.
Re: Read sysctl from file
> Is there a way to make sysctl re-read its conf file, or even another file, > like sysctl -p does on linux systems ? > Supporting this option would be nice, as it is used by the sysctl module of= > ansible. But sysctl doesn't have a configuration file. there is a file called sysctl.conf, but it isn't a configuration file for the command. It is a list of sysctl changes, which will be made by the rc scripts at startup. someone in linux land went off the map here. and then another piece of software started un-portably assuming that's the way to do things?
Re: Read sysctl from file
> On 07:39 Thu 20 Jul, Theo de Raadt wrote: > > someone in linux land went off the map here. and then another piece of > > software started un-portably assuming that's the way to do things? > > Because it's a nice way to apply configuration changes made to > /etc/sysctl.conf without restarting the whole server? only thinking of yourself, and missing the point. the point is that the 25-year old sysctl design had no such feature, and now other things are changing that. No, what you want does not exist.
Re: Read sysctl from file
> > > On 07:39 Thu 20 Jul, Theo de Raadt wrote: > > > > someone in linux land went off the map here. and then another piece of > > > > software started un-portably assuming that's the way to do things? > > > > > > Because it's a nice way to apply configuration changes made to > > > /etc/sysctl.conf without restarting the whole server? > > > > only thinking of yourself, and missing the point. > > > > the point is that the 25-year old sysctl design had no such feature, > > and now other things are changing that. > > > > No, what you want does not exist. > > He just asks if OpenBSD supports such a feature. Why so butthurt? I said no the first time, and provided a detailed explaination. Why did you feel the need jump in? Ichy butt?
Re: Read sysctl from file
> > On Jul 21, 2017, at 3:47 AM, Stuart Henderson = > wrote: > >=20 > > On 2017-07-20, BARDOU Pierre wrote: > >> Is there a way to make sysctl re-read its conf file, or even another = > file, like sysctl -p does on linux systems ? > >> Supporting this option would be nice, as it is used by the sysctl = > module of ansible. > >=20 > > Sounds risky. It won't reset default values thag are unspecified in > > sysctl.conf, so you could be sitting on a configuration that appears = > ok, > > but will fail after a reboot. > > Stuart makes a good point. So does Theo, adding -p to the sysctl binary = > when > it doesn't currently do any file handling at all seems extreme. So I = > wrote a > wrapper script that emulates Linux sysctl -p. I put very simple = > directions > at the top of the file. Find it here: > > https://gist.github.com/PeterFaiman/5b67c530b0ffa009ebef904ed0678e26 > > Ideally these tools wouldn't use Linux-specific features. But emulating > simple features like sysctl -p in a non-invasive way isn't too hard. One more point to add: Some setting can only be changed before securelevel. They fail afterwards. I'd say the entire approach is wrong, because it cannot tell them apart. It will fail halfway. It was obviously written by people who don't care.
Re: Read sysctl from file
> > On Jul 21, 2017, at 3:42 PM, li...@wrant.com wrote: > >=20 > > Fri, 21 Jul 2017 12:33:31 -0700 Peter Faiman > >> # ./sysctl -p example.conf > >> Peter > >=20 > > Hi Peter, ansibles, > >=20 > > No guarantee systems controls stay affixed, wrapper tools comply got = > it? > > The point of sysctl -p is reloading from a file. So that you put controls in > the file and load that file, exactly as happens in system startup. The whole > point is to ensure consistency with system startup. True, securelevel throws > a bit of a wrench in that, but this works for all other settings. We don't have -p. It is an addition made by a foreign system which barely uses sysctl, and has been acting for years like they will be removing support. THERE IS NO SUPPORT FOR -p. It is unlikely to happen. Let's just stop this. You just aren't capable of listening to what is being said. Also, you are ridiculously rude.
Re: Read sysctl from file
Peter, please leave. People around here don't need to read your insults.
Re: octeon port, ubiquity edgerouter
> > This is a solid machine, if you can get it, do so. OpenBSD 6.1 works > > very well on this hardware, I have used mine variously as a gateway > > router with PF, DHCP server, DNS server with unbound, and local name > > server with nsd. Currently it's acting as local name server while > > standing as backup router/nameserver/dhcp if needed. You will have to > > have valid time servers as the ERL doesn't have an internal clock. > > Have fun! I'd really like if someone could find a USB RTC clock, which is a viable affordable product which we can then create good support for. I've searched and found a few prototypes and 'licence key' products, but nothing readily available which we could support & encourage as a solution for the RTC problem.
Re: Minium System Requirements
> That said, while "minimum requirement" is neither useful nor > understandable, it might be interesting to document nominal > requirements - for example, size of base system on disk and memory > occupied on bootup. The landisk builds are done on a SH4 cpu running at 267 MHz, with 64MB of ram. Network is a 100mbit, the disk drive is a Hitachi CF 8GB disk drive -- yes it fits into a CF socket internally, and it has real spinning parts. That's not the bare minimum to get work done. I am certain a much slower machine would be able to get the work done. The landisk is obviously too much machine for the job, because it spits out a new snapshot every few days. It meets expectations; dare I say it exceeds them. So I encourage everyone to get a machine no faster than this, or perhaps even slower. Perhaps later we can decide who is proving which point. > But - given the undefined free variables - that sort of thing probably > belongs in blog posts rather than on openbsd.org. It's misc, everyone wants a helping hand no matter how silly. I'd like my lawn mowed.
Re: Lumina enable Shut Down
> On Sun, Jul 23, 2017 at 09:10:07PM +0200, Martijn Rijkeboer wrote: > > On 22-07-17 02:02, Sha'ul wrote: > > > In Lumina desktop how do I enable shutdown from GUI menu for point and > > > click poweroff and reboot? > > > > Try adding yourself to the 'operator' group. > > The operator group has read access to raw disk device nodes, > bypassing file system permissions: ls -l /dev/r[ws]d[0-9]* > > Allowing shutdown/reboot via doas(1) is a safer option. Oh come on Stefan, don't be so demoralizing, isn't it obvious some people want their browsers reading their raw filesystems?
Re: Lumina enable Shut Down
> I'm our maintainer of the Lumina port. Let me chat with my friends > upstream and see if we can't come up with a better solution for this. > As a quick thought, allowing users in a particular group (perhaps > :wheel?) to run shutdown(8) without a password prompt using doas seems > like a starting point. Thoughts on that if I push that direction? Whatever anyone wants to do to de-secure their own machine, but this type of thing should NEVER be default configuration applied by a package. I think the entire approach is dumb. It's like adding a "shutdown" built-in to ksh. Obviously when I'm in ksh, I want to be able to Shutdown my machine. Why has this feature been withheld from me for so long??
Re: fsck_ffs: cannot alloc 131427074 bytes for lncntp
> No. Filesystem is FFS. The os is 4.9 or later but not above 5.4 afaik. Sorry, that's too old for you to get any 'free support' or assistance.
Re: octeon port, ubiquity edgerouter
> I wonder how fast the NIC's will be - using this CPU and still no hardware > acceleration. > > Yeah, I'm wondering that too. It's pretty cool this platform is > becoming more popular to run openBSD on. > > People are willing to take an unknown (right now) performance penalty > to run openBSD on it and with pf. Wow. So there is a series of self-education problems hiding behind this conversation. There is a completely proprietary HW-assist platform that the vendor has as a blob. You want us to use that? You want a blob? You think it will be reverse engineered? Keep dreaming. Or let's go back to using the blob. What else does it do? Thought about that? Nope, I think that went WHOOSH overhead. And even if the HW was figured out. Does it work with the way PF manages every packet from arrival to delivery? Or is it a switch-style cut-through approach, without good inspection/management inflection points. Probably something designed for PERFORMANCE, and acting to the detriment of any attempt to smart filter/route packets. But still, the statement stands that this is a 'performance penalty'? How do you figure that?? None of the other architectures have the benefit of such a blob. They do it all in software. When we run on amd64, we don't have such a blob. So we operate with a 'performance penalty' defacto? Where do you guys keep coming from?? I mean I keep seeing people who just don't spend an OUNCE OF EFFORT at actually learning how things are put together, and then cheerily pat each other on the back on mailing lists with hope and glee, and cheering on about changing a fan? You really do deserve each other, and to large degree I think perhaps on that platform perhaps you should stick with the blob-enhanced vendor-locked Linux.
Re: stub-addr in unbound.conf & unbound man page wording
> then a 'dig' or 'nslookup' fails even though I can get to port 8053 on > 127.0.0.1. This is due to the socket pledge code, with SOCK_DNS. This area was damaged during the transition to pledge, and hasn't been repaired. Maybe one day. But for the moment, it is not getting fixed because it isn't easy. It is the only major damage from pledge which hasn't been fixed yet, and if you go study the source code of dig and nslookup carefully you'll see why.
Re: USB 3.0 and i/o error 5 @ CRYPTO block
There are some known problems on xhci usb3.0. the driver isn't perfect yet.
Re: OpenBSD Traning Docs / How Tos
> both regarding content and markup (including pf.conf(5) and > ifconfig(8)), and that is not a coincidence: The subject matter is > unusually difficult, the number of features to explain is unusually > large, the number of people qualified to judge the accuracy of the > manual pages and proposed changes is unusually small, and many of > them are unusually busy. Let me try to provide some perspective why. Simple uses are easy to document (ie. "do this, here is an example, copy it. you don't need to understand). Complex usage cases eventually hit questions regarding order-of-evaluation. We made mostly correct decisions years ago, but people trying to use the code don't immediately come to the same conclusions since they are learning the field at the same time. These details should be documented, or someone must figure it out themsleves. But where? Describing both simple behaviours and complicated behaviours together is very difficult. In all fields. I'm also very wary of documentation changes in complicated areas, because most of the proposals are focusing on "me" cases, rather than trying to capture all the angles.
Re: What about some automated testing for X programs? Re: Libreoffice calc crash
> As of today, what package testing is automated by anyone? None. So you can be first to do it...
Re: re: code duplication
> > P.S. > > There is no good reason to insult Todd > > I don't know him, I might've heard of him once. Needless to say, the > insult obviously wasn't personal. > > > for running spamd(8), which > > is a standard tool and less annoying than some others. > > How do you find 'Hello, spam sender. Pleased to be wasting your time.' > anything but a grave insult to someone who takes the trouble to manually > send e-mail? > > > Managing > > completely open mailing lists is a very difficult, a tiresome, and > > a thankless job, in particular for popular lists like the OpenBSD > > ones, and i'm quite glad the service has been running so smoothly > > all these years. > > I do appreciate that, and I don't complain much if messages get delayed > because of it. > > But when I take the time and effort to not bother people with mangled > subject lines, and I'm just called a spammer and effectively dismissed, > then I call the responsible admin a jerkass for it. > > 'cause that's the feeling it evokes in me, even if it's through the > machine. Then please demonstrate your sensitivity by stopping use of the OpenBSD project's mailing lists. Obviously what I'm saying isn't a personal insult. I just came to the conclusion you are a loudmouthed jackass. So go away.
Re: fd0 at fdc0 drive 0: density unknown
> > The old behavior was that the kernel would wait after the "fdc0 ..." line > > until fd0 attaches. Now it does the waiting in the background and continues > > booting. I agree that it's a bit ugly, but it makes booting about 5 seconds > > faster. > > It's not just a bit ugly... It's horrible. It has to go. I'm surprised > noone has reverted this crazy change yet. usb devices attach late all the time also. Tony, your opinion counts for very little around here -- quite a few rungs below my cats...
Re: Packages security updates in -stable
> Since the main goal of OpenBSD is security, I keep wondering about one > thing. > There are packages like irssi or Thunderbird that should be updated to > the newest upstream version. These two sentences don't make sense together. You equate "update update" with security. That doesn't make sense. Replacing the pigs with newer versions isn't security work. It is simply grunt work. This project's focus is on building new security features into a complete operating system, and still allow the junk to run. For a few of us that mission is important, for other people it is less important. > For example irssi's upstream encourages all users to upgrade to the > newest one, see: > https://irssi.org/2017/07/07/irssi-1.0.4-released/ > > Similar situation with Chromium etc. All of those packages exists in > newer versions in -current, but it's not an option in my case. > > I understand that -stable is not place for the latest packages available > and it's expected to be rock solid, but also secure. Well the options are: Get involved and do the work, or watch. There are lots of keyboards, but too many monkeys work on drafts of shakespeare and too few are working on making software better. Of course, I should add a caveat that it is my impression that the "update! update!" treadmill is ridiculous, and for every bug fixed in upstream software, new features+complexities result addition of new bugs, for that reason in particular I don't work in that area but instead focus on building a cleaner kernel+library infrastructure so that high-level errors hopefully don't compound as dangerously. BTW, the real estate board of your country would like to remind you that you probably live in an old house, and should upgrade... > So I wonder what is the policy in situation when updating to the newer > upstream version is more than recommended due the security reasons. There is no policy. The ports area of the tree consists of genuine people who end up having to do all the work -- since the space and workload is so huge, it should not be surprising when they are selective about which things they consider most crucial and do first. Perhaps that is the nugget you seek.
Re: Packages security updates in -stable
> >> I understand that -stable is not place for the latest packages available > >> and it's expected to be rock solid, but also secure. > The thing is that mentioned packages are already updated in MAIN. Twice the work == twice the work. > I'm curious how looks the process of merging package updates that > contains security fixes. Doing the work twice, unfortunately, means putting something else aside and not doing it. You mention two pieces of software. Whoever handles them -stable is taking time away from work on other software in -current. > > Well the options are: Get involved and do the work, or watch. > How can I help in case when updated package is already in -current? Unfortunately, you cannot really help. We don't know how to scale groups of people to do the same work twice. Also as any group gets larger, other frictions and inefficiencies show up. Instead, the various cadence mismatches are handled best-effort by doing releases twice a year, and ensuring that the tree always builds and produces -current. That is our way. I think it is a good decision. In the meantime you have the source code, don't you? So you can handle it for yourself.
Re: 6.1 -release syspatched or -stable
> For 6.1 amd64/i386 is there a difference between a syspatched -release > and a compiled -stable (in base syspatched -release eq compiled > -stable)? > And what about the userland in -release in contrary to a fresh compiled > userland for -stable? For amd64/i386 I just want to understand the > difference if there is any to decide which way will be more suitable for > my new installations. Yes they are possibly different. syspatch is the errata process. -stable could be more than that -- it depends. Pick one method.
Re: What decides which port becomes a package?
>On 2017-09-11, Marc Espie wrote: >> I'm just discovering the issue and the thread with it. >> >> I don't quite understand why we don't talk it over with Colin Percival. >> >> > >PERMIT_*_FTP would seem alright to me, as long as people are careful >not to add patches .. Yeah, and the same policy could apply to all the other ports like that! Until someone breaks that rule, violating the author's wishes. Which is why this isn't done. I think it should not change.
Re: Kernel relinking fails after using config(8)
> Hello misc, I used config -ef on my current kernel, and after rebooting, > kernel relinking fails. The log only contains "(SHA256) /bsd: FAILED" Yes, this is known. If you take control of the kernel using various means, relinking deactivates.
Re: Increase swap size on a running instance
> Looking for help. I am trying to run an application that requires 2 GB > of swap. My VPS instance has 256 by default. For some reason the > application will not accept a swap file. It is possible to resize > partitions live to get a bigger swap space? On fooVPS you type # fooswap -a /foo I am glad you enjoy the highly detailed response I'm able to give you, in response to your exquisitely detailed question.
Re: FF vs. Chrome/Chromium
> Firefox has W^X compliance and so runs with the secure defaults. it uses page aliasing, which is a shitty way of being compliant > The latest Firefox (Not ESR as mtier provides) has recently had > sandboxing for Windows and Linux added and legacy extensions will be > phased out. > > It is therefore likely possible to add pledge patches without depending > on upstream and so Firefox could become the clear winner. you really shouldn't be promising that to anyone. it might not happen, their design might not allow it. pledge in giant programs is very rare. chrome got LUCKY, and there is no evidence that firefox will also. n> > Otherwise you have to decide for yourself. I'm not sure any browsers > code quality is Good or which is better, which would be an important > factor. > > Neither are particularly good at privacy but Firefox does allow > clearing data on exit and has better extensions. > 1
Re: relayd: high CPU usage by one or two proc. of many
> >> ktrace gives me following:
> >> 4013 relayd CALL getdtablecount()
> >> 4013 relayd RET getdtablecount 101/0x65
> >> 4013 relayd CALL getrlimit(RLIMIT_NOFILE,0x7f7bb630)
> >> 4013 relayd STRU struct rlimit { cur=3D65536, max=3D65536 }
> >> 4013 relayd RET getrlimit 0
> >> 4013 relayd CALL recvmsg(550,0x7f7bb6a0,0)
> >> 4013 relayd RET recvmsg -1 errno 35 Resource temporarily unavailable
> >> 4013 relayd CALL getdtablecount()
> >> 4013 relayd RET getdtablecount 101/0x65
> >> 4013 relayd CALL getrlimit(RLIMIT_NOFILE,0x7f7bb630)
> >> 4013 relayd STRU struct rlimit { cur=3D65536, max=3D65536 }
> >> 4013 relayd RET getrlimit 0
> >> 4013 relayd CALL recvmsg(550,0x7f7bb6a0,0)
> >> 4013 relayd RET recvmsg -1 errno 35 Resource temporarily unavailable
> >> 4013 relayd CALL getdtablecount()
> >> 4013 relayd RET getdtablecount 101/0x65
> >> 4013 relayd CALL getrlimit(RLIMIT_NOFILE,0x7f7bb630)
> >> 4013 relayd STRU struct rlimit { cur=3D65536, max=3D65536 }
> >> 4013 relayd RET getrlimit 0
> >> 4013 relayd CALL recvmsg(550,0x7f7bb6a0,0)
> >> 4013 relayd RET recvmsg -1 errno 35 Resource temporarily unavailable
This probably means the process has run out of file descriptors.
fstat might expose what is going on. If that's the case, roll your
sleeves up and study the code. As usual, the circumstances that
create this event are not being completely documented - I MEAN, what
I'm seeing here isn't a bug report including a configuration file
that reliably reproduces it.
Re: stickers
> Now that there are no CDs, are stickers also gone? I guess many people didn't think through what happened when CD production stopped. Stickers, posters, etc. were subsidized by the sales of CDs. With CDs gone, of course there isn't an efficient way to sell stickers, and make even a few pennies in return for producing art. Some shops now print our older stickers or newer (minimal) release art, and there's nothing we can do about it. We can complain but it solves nothing. The project and I don't get a single penny. Sure those of you who want the stickers benefit, but that's selfish isn't it. The OpenBSD Foundation never participated in making artwork. It was always done by me, out of CD income. It was a tremendous amount of effort twice a year, coming up with the ideas and completing them. When CDs stopped returning at least some income, that process had to stop for everything.
Re: boot> does not "time out" after failed PXE boot
Only one boot attempt occurs, whether network or disk. It is expected behaviour. > After a failed/aborted PXE boot (e.g., hitting a key or no network) > a laptop is "hanging" at the (OpenBSD 6.2 snapshot) > >boot > prompt which normally (AFAICT) times out and just boots after a few > seconds (from disk); it boots fine after hitting "Return". > > Can someone please clarify if this is known/expected behaviour or > a problem with the software or the hardware? > > dmesg from the laptop (running a recent snapshot) > > OpenBSD 6.2 (GENERIC.MP) #123: Sat Sep 30 22:51:56 MDT 2017 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8495951872 (8102MB) > avail mem = 8231452672 (7850MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf2440 (67 entries) > bios0: vendor Dell Inc. version "A12" date 05/09/2012 > bios0: Dell Inc. Latitude E6510 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC TCPA MCFG HPET BOOT SLIC SSDT > acpi0: wakeup devices AGP_(S4) P0P1(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) > RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) > RP07(S4) PXSX(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) i7 CPU M 620 @ 2.67GHz, 2660.43 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: TSC frequency 2660428950 Hz > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 132MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 4 (application processor) > cpu1: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz, 2659.99 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 2, package 0 > cpu2 at mainbus0: apid 1 (application processor) > cpu2: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz, 2659.99 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 1, core 0, package 0 > cpu3 at mainbus0: apid 5 (application processor) > cpu3: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz, 2659.99 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 1, core 2, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 addr 0xf800, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (AGP_) > acpiprt2 at acpi0: bus 10 (P0P1) > acpiprt3 at acpi0: bus 1 (RP01) > acpiprt4 at acpi0: bus -1 (RP02) > acpiprt5 at acpi0: bus 2 (RP03) > acpiprt6 at acpi0: bus 4 (RP04) > acpiprt7 at acpi0: bus -1 (RP05) > acpiprt8 at acpi0: bus -1 (RP07) > acpiprt9 at acpi0: bus -1 (RP08) > acpiprt10 at acpi0: bus -1 (PEG3) > acpiprt11 at acpi0: bus -1 (PEG5) > acpiec0 at acpi0 > acpicpu0 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), > C1(1000@3 mwait.1), PSS > acpicpu1 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), > C1(1000@3 mwait.1), PSS > acpicpu2 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), > C1(1000@3 mwait.1), PSS > acpicpu3 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), > C1(1000@3 mwait.1), PSS > "PNP0401" at acpi0 not configured > "DLL040B" at acpi0 not configured > "SMO8800" at acpi0 not configured > acpibtn0 at acpi0: LID_ > acpibtn1 at acpi0: PBTN > acpibtn2 at acpi0: SBTN > acpiac0 at acpi0: AC unit offline > acpibat0 at acpi0: BAT0 model "DELL RG04908" serial 7861 type LION oem "Sanyo" > acpibat1 at acpi0: BAT1 not present > "*pnp0c14" at acpi0 not configured > acpivideo0 at acpi0: VID_ > acpivideo1 at acpi0: VID_ > acpivideo2 at acpi0: VID_ > acpivout0 at acpivideo2: LCD_ > cpu0: Enhanced SpeedStep 2660 MHz: speeds: 2667, 2666, 2533, 2399, 2266, > 2133, 1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev
Re: How to allow __set_tcb in pledge
> I'm trying to use pledge to protect a go program. > > The exec aborts with abort trap: core dump > > Ktrace and /var/log/messages say that the __set_tcb > syscall is denied. > > Can I configure pledge to allow such syscall ? In post-6.2, this is now allowed. It wasn't allowed earlier due to an oversight. > (Same question for mlock and mlockall) Uhm, those are not going to be allowed. They are precisely the type of operations you should do before pledge.
Re: pointing installurl to current snapshot packages path does not work
Completely intentional. Snapshots convert into released mode, but not all the parts are released yet. Release happens when enough parts are built. When you encountered this problem, did you read the manual pages to look for a solution? Why not? > I installed today via usb the latest snapshot > 2017-Oct-04 03:45 from > leaseweb. > When setting up I chose disk as install medium, so have no installurl > set up at the beginning. > > Now i am trying to set up installurl so i can get latest packages. > > I have tried following in installurl > > > 1 https://ftp.eu.openbsd.org/pub/OpenBSD/ > 2 https://ftp.eu.openbsd.org/pub/OpenBSD/snaphots > 3 https://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/packages/amd64 > > and also with other mirrors, i always get same responces in the form that > > https://ftp.eu.openbsd.org/pub/OpenBSD/6.2/amd64/ is not found > > So even when i use the installurl to point into right path, the path > is being changed into 6.2 and the rest. > > Can anyone explain to me what i am doing wrong and how i am supposed > to get with pkg_add packages on my new install, > > thanks for understanding maybe this simple question for some person > with more experience in openbsd management. > > eelco >
Re: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode
This is kind of intentional, since noone has put effort into making softraid understand the disk-binding logic found in the BIOS-RAID sectors. Maybe we should reconsider, dunno. > I've just tried to install the amd64 OpenBSD 6.2 and it doesn't see > hard disks when controller in RAID mode (BIOS configuration). If I > change it to AHCI mode (in BIOS) it can see them. > > Although I don't use RAID capabilities I can't switch to the AHCI mode > because I have Windows 7 installed when the storage controller was in > RAID mode (default in my BIOS). > > Is it a know bug/limitation? Various Linuxes and FreeBSD 11.1 work > properly with my disk controller and see all the disks, even in RAID > mode. > > My hardware: > HP Z230 desktop with Intel C226 chipset, Intel Core i7 4790 CPU and 16 > GB of RAM. > Hard disks: > [1] 238GB SanDisk SD8SBAT256G1122 (SSD) > [2] 931GB Western Digital WDC WD10EZEX-60M2NA0 (SATA) > > Installation media: > install62.fs flashed on a USB drive. >
Re: 6.2 starts nsd before slaacd binds ipv6 address
> > I don't feel this warrants a bug report, but nevertheless feel that this > > behavior is inconsistent with the way dhclient works. I have a vultr > > server running nsd/OpenBSD 6.2, and I suspect that the move to slaacd > > from kernel code in 6.1 is what has broken my nsd config (it fails to > > start on boot now). > > There definitely are races in the demon startup sequence. It's > less clear what to do about them. This is an irrelevant race. The transit paths are equivalent. IPV6 was sold on the premise that we change the software to support a second transit, which performs exactly the same function so that either can be used, equivalently. If the applications support both methods, then why would we wait until we can qualify that both are working? Either works -- and that is Good Enough. The DNS lookup picks a method that works because returning an answer ASAP is the mission of the DNS lookup code. There are no valid inet6 routes, so inet6 is bot operating at that point and it returns the answer. Since these are UDP applications, they could contain logic to speak the other protocol if they discover later that it works. Such logic could be complicated and fragile. But I don't use "family inet6 inet4" in resolv.conf or any other such logic, so I don't want my machines booting slower to satisfy the problem... and I doubt anyone else does either. That is likely the only circumstance where this problem happens -- Because I understand people have made DNS servers return different results if the request comes in over IPV6. That is obviously an agenda-driven campaign which breaks the original promise that the data over transport would produce identical results. It breaks things in subtle ways, no surprise. > At home, I have my own stratum 1 NTP server, so my standard ntpd.conf > is "server ntp". This seemingly innocuous configuration has revealed > _two_ races. > > (1) slaacd, ntpd > I also have "family inet6 inet4" in resolv.conf, and ntp(.mips.inka.de) > has both an A and an record. ntpd should thus talk to the > server at the v6 address. However, on faster machines it ends up > talking to the server's v4 address, because slaacd hasn't successfully > configured the local v6 address yet when ntpd starts. > > (2) nsd, unbound, ntpd > On my home gateway I run unbound as caching name server. My private > mips.inka.de namespace is configured as a stub-zone supplied by nsd > running on the same machine on port 5353. I was quite surprised > to find that ntpd on the gateway wasn't talking to ntp.mips.inka.de > but instead to ntp.inka.de--a very different machine. Apparently, > at the time ntpd starts and queries unbound, nsd isn't ready yet > and unbound can't resolve ntp.mips.inka.de, leading to another > attempt to resolve "ntp" as ntp.inka.de. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
Re: How to allow __set_tcb in pledge
> What does that mean ?... It means you cannot pledge big pieces of software that perform arbitratry magic. Learn the magic, change the magic.
Re: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode
> On Thu, Oct 12, 2017 at 12:18:52AM +0300, Rostislav Krasny wrote: > > You just lose users and popularity. > > In this community, your statement has the opposite effect of what it is > trying to achieve. It puts developers off and discourages them from > worrying about your problem. > > At any given moment, there are enough problems developers have to worry > about already. Hardware they want to use which does not work yet, new > problems people report in code they've recently changed, chasing new > developments in code they've ported from other projects, new features > they want to implement, etc. etc.; all stacked against limited time. > Worrying about popularity on top of it all would just be distracting. > > The mindset here is that if you really want something fixed in OpenBSD, > try to fix it yourself, and then try to share your fix with the rest of us. > That's how, collectively, we produce value, and popularity has nothing to > do with it. damn straight
Re: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode
> On Thu, Oct 12, 2017 at 2:43 AM, Mike Larkin wrote: > > On Thu, Oct 12, 2017 at 02:36:11AM +0300, Rostislav Krasny wrote: > >> On Thu, Oct 12, 2017 at 1:10 AM, Stefan Sperling wrote: > >> > On Thu, Oct 12, 2017 at 12:18:52AM +0300, Rostislav Krasny wrote: > >> >> You just lose users and popularity. > >> > > >> > In this community, your statement has the opposite effect of what it is > >> > trying to achieve. It puts developers off and discourages them from > >> > worrying about your problem. > >> > > >> > At any given moment, there are enough problems developers have to worry > >> > about already. Hardware they want to use which does not work yet, new > >> > problems people report in code they've recently changed, chasing new > >> > developments in code they've ported from other projects, new features > >> > they want to implement, etc. etc.; all stacked against limited time. > >> > Worrying about popularity on top of it all would just be distracting. > >> > > >> > The mindset here is that if you really want something fixed in OpenBSD, > >> > try to fix it yourself, and then try to share your fix with the rest of > >> > us. > >> > That's how, collectively, we produce value, and popularity has nothing to > >> > do with it. > >> > >> I'm not familiar with the OpenBSD code and I even don't have a working > >> OpenBSD system to try fixing it by myself. > >> > >> I think you can easily identify hard disks that are not part of any > >> software RAID array and support only them when the RAID mode is > >> enabled in BIOS. You can do it by looking for the 0xa92b4efc "Magic > >> Number" of the RAID superblock at the end of the disk and at 4K from > >> the beginning of the disk. If it's NOT present then this disk is not > >> part of any RAID array and you may use it directly as in AHCI mode. It > >> seems you don't have to understand the whole RAID metadata but only be > >> able to identify its presence. > >> > >> I found it there: > >> https://raid.wiki.kernel.org/index.php/RAID_superblock_formats > >> https://github.com/neilbrown/mdadm/blob/master/md_p.h > >> > >> Also Intel officially recomends the mdadm tool and participated in its > >> development, so the above information should be good: > >> https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/rst-linux-paper.pdf > >> === > >> The recommended software RAID implementation in Linux* is the open > >> source MD RAID package. Intel has enhanced MD RAID to support RST > >> metadata and OROM and it is validated and supported by Intel for > >> server platforms. > >> === > >> > > > > Sounds like you've already done most of the research. > > > > Your diff to implement this will be most welcome on tech@. > > As I already told I'm not familiar with the OpenBSD code and I even > don't have a working OpenBSD system to try fixing it by myself. I just > googled for the technical information. > Oh, so you are just some boasty guy on the net I get it
Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied
You own all the pieces. > RO /usr also breaks the shiny new kernel relinking. > > So the best I have come up with is crontab lines > > @reboot sleep 60 mount -urf /usr > > The 60 may be too short on very old systems. > > Perhaps it's time to drop the ro but I'm quite attached to my security > blanket, lol ;) >
Re: size of size_t
> I just discovered, to my dismay, that size_t is only 32 bits, even on > 64-bit processors. Is there a particular pressing reason for this? A > quick investigation reveals that even dd(1) is affected -- this is IMO > not good. You are wrong. limits.h:#defineSIZE_T_MAX ULONG_MAX /* max value for a size_t (historic) */ > I'd suggest, given modern file sizes, that we bump it to 64 bits on all > platforms. Comments? No way.
Re: FU: size of size_t
> I wrote: > > I'd suggest, given modern file sizes, that we bump it to 64 bits on all > > platforms. > > Oh, and off_t *is* 64 bits, at least on i386; pity most routines don't > use it: they use size_t. off_t is used where it should be used. size_t is used where it should be used. You are showing inexperience.
Re: RE: size of size_t
> >> I just discovered, to my dismay, that size_t is only 32 bits, even on > >> 64-bit processors. Is there a particular pressing reason for this? A > >> quick investigation reveals that even dd(1) is affected -- this is IMO > >> not good. > > > > You are wrong. > > > > limits.h:#define SIZE_T_MAX ULONG_MAX /* max value for a size_t (historic) > > */ > > Okay, I don't have a 64-bit machine running OpenBSD to check -- but is 'long' > 64-bits on those? In that case I am indeed wrong. > > >> I'd suggest, given modern file sizes, that we bump it to 64 bits on all > >> platforms. Comments? > > > > No way. > > Can I trouble you for an explanation? No, not really. If you won't use the publically available source tree and vast amounts of documentation about POSIX but instead jump straight towards assertive dialogue on a mailing list, then I don't see how we can help. Basically you are saying we should just change everything, consequences and correctness be damned.
Re: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode
> On Wed, Oct 11, 2017 at 11:01 AM, Stuart Henderson > wrote: > > What is not good is when you do have a RAID array, the controller is > > in RAID mode, but OpenBSD doesn't understand the metadata, so it corrupts > > data on the disk. > > > > This is a difficult area. We don't want to corrupt data, but then some > > BIOS don't allow this option to be changed at all, and on others BIOS > > only offer a choice between IDE and (unsupported) RAID, even though > > it's an AHCI controller. > > Would a config flag for ahci(4) that when enabled, forces it to attach > to the Intel RAID PCI IDs, work here, or would that have to be handled > at a lower level? > > If so, users who have a broken BIOS or are willing to accept the risk > of destroying their RAID metadata could enable the flag with UKC, but > the defaults would remain safe. An option which noone will use because they aren't aware they need to use it? That isn't helpful. 1. It would be better if the metadata are identified, and at minimum the proto disklabel is down-adjusted to protect them. 2. When that safely does the read operations, next step is to parse them in more detail as feed-stock for softraid. 3. Then the final detail is to have softraid initialization capable of creating such metadata. Unfortunately we are still stuck here: 0. No code being developered, email and wiki discussion, gnashing of teeth
Re: RE: FU: size of size_t
> theo wrote: > > > > off_t is used where it should be used. size_t is used where it should > > be used. > > In that case I change the proposal to the introduction of an uoff_t, or > is there already something appropriate? If so, why doesn't dd(1) use it? > > > You are showing inexperience. > > Yes, you got that exactly. Time to begin buffing the 'd' key.
Re: Automatically restarting services/daemons after crash
> Perhaps I'm mistaken, but it doesn't seem like there's a facility for > automatically restarting daemons after a crash or similar. Is the idea > just that daemons should be designed to not crash? Yes. Fail closed. It is the only secure thing to do. > I'm familiar with 3rd party tools like daemontools and such that > provide these facilities, but I can't find anything on this for native > OBSD services. You can build anything yourself, but we're not going to provide such a mechanism. If software has a bug, you want to fix it. You don't want to keep running it. Yes, I get it many people are addicted to the service industry model of running crap and getting the job done. Lots of stories in the news about that all the time...
Re: Automatically restarting services/daemons after crash
> That's sensible, but if money or lives were on the line, I think It'd > be better to have a running but potentially vulnerable service. For my > use case, this is completely acceptable, I'm just curious about the > implications for others. Then you can do that on your own, if it suits your use case. It does not suit the default use case. Go right ahead repeatedly restarting a service that some attacker is trying to attack a known hole in, which is being defeated by the entropy we added to the runtime. Except each time he's learning a little more about your runtime, and eventually he wins. Any remote service which crashes is potentially exploitable; we have to assume so, until we see the specific way it fails.
Re: Automatically restarting services/daemons after crash
> OpenBSD also has plenty of redundancy service failover (CARP, relayd > etc.) as do service providers. So one/more can take over whilst the > failed are audited. Uhm, in your dreams. This is a conversation about simply restarting such failing services.
Re: A stupid question, re: xargs(1)
> Can someone explain to me why xargs(1) does not support using newline > as a separators, when that is one of the most common unix separators? Because then you don't need xargs, normal tooling seperates each line into a seperate argv entry regardless of other spacing. You are proposing an incompatible extension to a POSIX defined utility. Meaning if someone uses this in a script, it won't work on other systems. Not everything in unix is perfect. > I'm pasting one potential approach to the end of this message. There's > a few issues that might be stalling points: > > (*) which command line option to be used (this gets into potential > conflicts with other versions). > > (*) how to handle (or not handle) escape characters (my feeling is > that escaping newline characters would be a bad thing when using > newline as a separator). > > (*) code neatness and style issues. > > But, anyways, given the problems that arise from xargs space handling > being "too smart", and given how often spaces get included in file and > directory names, it seems like newline separated records should have > been a no-brainer back like 20 years ago, if not earlier. So > presumably someone has at some point squashed efforts to fix this. > > So, I guess I might be looking for the reasons. Does anyone know? > > Thanks, > > -- > Raul > > --- xargs.c.orig2017-10-13 14:13:16.0 -0400 > +++ xargs.c2017-10-13 14:13:17.0 -0400 > @@ -65,7 +65,7 @@ > static char **av, **bxp, **ep, **endxp, **xp; > static char *argp, *bbp, *ebp, *inpline, *p, *replstr; > static const char *eofstr; > -static int count, insingle, indouble, oflag, pflag, tflag, Rflag, rval, > zflag; > +static int count, insingle, indouble, oflag, pflag, tflag, Rflag, > rval, zflag, lflag; > static int cnt, Iflag, jfound, Lflag, wasquoted, xflag, runeof = 1; > static int curprocs, maxprocs; > static size_t inpsize; > @@ -174,6 +174,9 @@ > case '0': > zflag = 1; > break; > +case '/': > +lflag = 1; > +break; > case '?': > default: > usage(); > @@ -262,7 +265,7 @@ > if (insingle || indouble) > goto addch; > hasblank = 1; > -if (zflag) > +if (zflag || (lflag && '\n'==ch)) > goto addch; > goto arg2; > } > @@ -282,6 +285,8 @@ > goto arg2; > goto addch; > case '\n': > +if (lflag) > +goto arg2; > hasblank = 1; > if (hadblank == 0) > count++; > @@ -360,19 +365,19 @@ > wasquoted = 0; > break; > case '\'': > -if (indouble || zflag) > +if (indouble || zflag || lflag) > goto addch; > insingle = !insingle; > wasquoted = 1; > break; > case '"': > -if (insingle || zflag) > +if (insingle || zflag || lflag) > goto addch; > indouble = !indouble; > wasquoted = 1; > break; > case '\\': > -if (zflag) > +if (zflag || lflag) > goto addch; > /* Backslash escapes anything, is escaped by quotes. */ > if (!insingle && !indouble && (ch = getchar()) == EOF) >
Re: A stupid question, re: xargs(1)
> (2) Given that POSIX is an incomplete specification, why is POSIX the > issue here? What does 'incomplete specification' mean. You mean incompatible extensions should be added, quite similar to the damage bash creates in the ecosystem with it's incompatible extensions?
Re: A stupid question, re: xargs(1)
> The problem here is that you currently can't get xargs to use newline > as a separator without also getting spaces as a separator. This > creates a variety of problems. But it creates lots of other problems when you propose an extension to only one operating system's version of a utility. I think you've written a diff and now you are handwaving...
Re: A stupid question, re: xargs(1)
> Ok, I am curious - what new problems would this create? I explained in the first mail.
Re: A stupid question, re: xargs(1)
> It does seem to me that the implementation should be portable. Wow, you don't get it. You want to add a feature. The someone will use the feature. In a script intended to be portable. But other systems won't have this feature Therefore the script won't work. That sucks. If you want to add things to standardized utilities you need to convince a large volume of people in the greater community Not me. An alternative solution for your problem already exists on all the operating systems, which is to use programmatic tools _such as perl or awk_. Every utility doesn't need to grow handling for every case, differently on every operating system.
Re: Automatically restarting services/daemons after crash
> I read "hacking blind." Can you restart a daemon with another forked > process that's only job is to monitor a pipe or a waitpid()-like operation > and if the parent dies, it exec's to restart it, or even execs "rcctl > restart ntpd" > > If the mitigations are successful at limiting execution to let's say, > overwriting a canary that gets completely rerandomized with a fork-exec, > instead of just a fork, it would stop a meaningful search for the correct > canary to just blind luck instead of byte by byte discovery. your position is very roughly: that paper lays out the absolute limit of what someone could learn from broken software, so as long as we run a new copy of the broken software we'll be safe obviously, no downside. you say "completely rerandomized" -- uhm no, only a tiny fraction of the program execution environment and runtime are randomized, in particular same registers used everywhere, same instruction sequences, same frame layouts, same register and stack leave-behinds, same relative offsets inside each DSO nothing learned from re-running buggy software? sorry, that is BS.
Re: Automatically restarting services/daemons after crash
> Maybe more things should be randomized like the stack canaries. Is that a > new idea? Time to orer a new keyboar.
Re: Postfix tlsmgr(8) entropy source on OpenBSD
> In light of the message regarding /dev/arandom and /dev/urandom would it now > be correct to use *ONLY* /dev/urandom on current versions of OpenBSD ? In OpenBSD it doesn't matter which one you use. /dev/urandom, /dev/arandom and /dev/random all work the same They are identical - gaurantee excellent strong random data - never block As I said, it doesn't matter which one you use.
Re: awk in OpenBSD
i'm watching a bunch of losers who argue before running diff > You didn't really make a great case for the newer awk, either. Is there a > good reason to use the 2012 release from upstream? If so, you could submit > a diff and explain the benefits. > > On Oct 19, 2017 12:15 AM, "Niels Kobschaetzki" > wrote: > > > > On 19. Oct 2017, at 06:23, flipchan wrote: > > > > Yeah blindly follow the flow of the others , DONT THINK SO > > That doesn=E2=80=99t explain the reasoning WHY the newer awk is not used. > > >> On October 19, 2017 4:25:09 AM GMT+02:00, Andras Farkas < > deepbluemist...@gmail.com> wrote: > >> On the 6.2 release page, and confirmed in the source code, one can see > >> The system includes the following major components from outside > >> suppliers: > >> Awk Aug 10, 2011 version > >> This turns out to be one release behind upstream, where the latest > >> release is from December 20 2012: a quick check shows that > >> DragonFlyBSD, FreeBSD, and NetBSD all use this version. > >> > >> Just out of curiosity, is there a reason why OpenBSD uses the 2011 > >> release? > > Niels
