Re: SSL issue on 6.8 arm64 when upgrading to 6.9

2021-06-18 Thread Theo de Raadt
Your clock is wrong.

> Unable to connect using https. Use http instead? [no]

Say yes.  (And thus, understand and accept that openbsd file
distribution is signed using a very reliable static key -- more
than good enough).



Re: TTY Count

2021-06-18 Thread Theo de Raadt
Brian Empson  wrote:

> What is the proper way to increase the number of TTYs available on the
> system? I have alot of users logged in on a machine and we run out of 
> TTYs every once in awhile.

I guess you mean ptys.

By default the system ships with 1 group of ptys (a group is 62), and
can support up to 15 sets (for a total of 992)

This is partially documented in the pty(4) manual page.

You can add additional sets by running MAKEDEV, this adds 3 more sets:

# cd /dev
# sh MAKEDEV pty1 pty2 pty3



Re: EACCES of UDP packet

2021-06-15 Thread Theo de Raadt
use ktrace

Siegfried Levin  wrote:

> Hi,
> 
> I have a application run by a normal user communicating with the server with 
> UDP. It crashes very occasionally, like once per week, due to EACCES when 
> sending a UDP packet. According to the manpage 
> (https://man.openbsd.org/OpenBSD-6.9/sendmsg.2#EACCES), the reason might be 
> either being blocked by PF or sending to a broadcast address. I can confirm 
> the packet was not sent to a broadcast address. However, I cannot figure out 
> what rule could block the connection occasionally either. The application can 
> be brought back online without changing any configuration. Does anyone know 
> what might fix this? I can also rewrite the code to make it ignore the error 
> and keep trying but that might not be a proper solution. Running it as root 
> might not be a good idea, too.
> 
> It happens since OpenBSD 6.8. Now I’m running it on 6.9. The application is 
> written in Rust.
> 
> Siegfried
> siegfried.le...@gmail.com
> 
> 
> 
> 



Re: OpenSSH and Key Pair Generation

2021-06-11 Thread Theo de Raadt
Sounds like you have an operating system with a broken random number
generator.

Someone is going to say "but it is so hard in VMs".  Yes it is hard
if the vendors do a poor job of handling it.  If they do a good job,
it is easy.

Anyways, Linux discussions are off-topic for OpenBSD mailing lists.


Christopher Johns  wrote:

> Good Evening,
> 
> Recently it has been brought to my attention that we may have several Linux
> hosts that may have the same problem ssh-rsa key pairs.
> 
> Is it possible if I use a server template to create Linux servers, for
> OpenSSH to create the same host keys in /etc/ssh for the servers created by
> my template?
> 
> Also, how does OpenSSH create the key pairs, by some random process called
> when OpenSSH is installed or when the new server is booted for the first
> time?
> 
> Thank you for your time and I look forward to hearing from you soon.
> 
> Regards,
> 
> Chris Johns
> UNIX-Linux Systems Administrator



Re: unhibernate failed: original kernel changed

2021-06-11 Thread Theo de Raadt
Allan Streib  wrote:

> Mike Larkin  writes:
> 
> > This is happening because you changed the kernel on your machine after
> > you booted, then did a hibernate. The new kernel no longer matches the
> > kernel loaded in memory. The kernels have to be identical. We do a few
> > checks to ensure this is the case, and that's the check you're seeing.
> 
> So then is it correct to say that if I run syspatch(8), and get the
> advisory message to reboot, I should be sure to do that before
> hibernating?

You should reboot immediately after syspatch.



Re: reposync:host key verification failed

2021-06-06 Thread Theo de Raadt
Yes a diff we need tested. Snapshots often contain future diffs, being
tested, and once in a while those diffs contain errors.

Newer snapshots contain a fix to this diff, another approach is to try a
newer snapshot.


Stuart Henderson  wrote:

> There are some diffs in ssh in snapshots, please try building ssh from
> source rather than snapshot and see if it fixes things,
> 
> $ cd /usr/src/usr.bin/ssh
> $ cvs up
> $ make obj
> $ make
> $ doas make install
> 
> 
> On 2021-06-06, Avon Robertson  wrote:
> > Hello misc@,
> > I have used a shell script containing the following statements since the
> > 20th January 2021. It has executed without error until recently. The
> > last error free execution was on the 30th May.
> >
> > #!/bin/ksh
> > logfile="$HOME/var/log/updcvs"
> > printf "\n$(date)\n" >> $logfile
> > printf "Call reposync to update local /cvs repository\nOutput is logged to 
> > $logfile\n"
> > doas -u cvs /usr/local/bin/reposync rsync://anoncvs.au.openbsd.org/cvs /cvs 
> > 2>&1 | /usr/bin/tee -a $logfile
> > exit $?
> >
> > Using a previous snapshot, reposync began to report failures as shown in
> > my log, on:
> > Mon May 31 20:07:02 NZST 2021
> > reposync: host key verification failed - see
> > /var/db/reposync/known_hosts
> >
> > The same error was then recorded in my log on the 3rd, 4th, 5th, and
> > 6th of June. The above known_hosts file does not exist on this machine.
> > The FILES section of reposync(1) I have interpreted as meaning that the
> > above known_hosts file, is not needed when the official keys exist in
> > file /usr/local/share/reposync/ssh_known_hosts which they do on this
> > machine.
> >
> > Hints as to where the problem is would be very appreciated. I have
> > included a dmesg output on the off chance it will contain useful
> > information.
> >
> > Regards Avon.
> >
> > OpenBSD 6.9-current (GENERIC.MP) #54: Sat Jun  5 09:41:12 MDT 2021
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 68647477248 (65467MB)
> > avail mem = 66551521280 (63468MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe8980 (59 entries)
> > bios0: vendor American Megatrends Inc. version "F2" date 03/14/2018
> > bios0: Gigabyte Technology Co., Ltd. X470 AORUS ULTRA GAMING
> > acpi0 at bios0: ACPI 6.0
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG HPET 
> > SSDT UEFI BGRT IVRS SSDT SSDT WSMT
> > acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) 
> > GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) 
> > GPPF(S4) GP17(S4) [...]
> > acpitimer0 at acpi0: 3579545 Hz, 32 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: AMD Ryzen 7 2700X Eight-Core Processor, 3700.63 MHz, 17-08-02
> > cpu0: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> > 64b/line 8-way L2 cache
> > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 100MHz
> > cpu0: mwait min=64, max=64, IBE
> > cpu1 at mainbus0: apid 1 (application processor)
> > cpu1: AMD Ryzen 7 2700X Eight-Core Processor, 3700.01 MHz, 17-08-02
> > cpu1: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> > 64b/line 8-way L2 cache
> > cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
> > associative
> > cpu1: smt 0, core 1, package 0
> > cpu2 at mainbus0: apid 2 (application processor)
> > cpu2: AMD Ryzen 7 2700X Eight-Core Processor, 3700.02 MHz, 17-08-02
> > cpu2: 
> > 

Re: Resuming from suspend takes 12-14 seconds

2021-05-27 Thread Theo de Raadt
amdgpu startup is slow.

not our fault.


Subhaditya Nath  wrote:

> Hi there!
> 
> I have installed OpenBSD 6.9 on my ThinkPad E495, and I have run
> syspatch and fw_update to install all the necessary patches and
> firmwares.  I have been running it for a few weeks now, and I absolutely
> love it!
> 
> Except, there is one very annoying issue.
> Resuming from suspend _always_ takes 12-14 seconds at least.
> 
> Say, I press the sleep button. Within two seconds, the PC goes into
> sleep. Then, I press any button on the keyboard to wake up the PC. As
> soon as I press the button, the POWER LED lights up, indicating that the
> hardware is up and running. But, the screen stays OFF for the next 11-13
> seconds. Then, the display turns on and shows ttyC0, and after a second,
> automatically switches to Xenocara.
> 
> 
> Any idea what's causing the 11-13 second delay in the screen turning on?
> How do I go about diagnosing the problem?
> 
> 
> Also, in case it is relevant, I have noticed that these lines appear in
> dmesg when I suspend and resume -
> 
>   uhub0 detached
>   video0 detached
>   uvideo0 detached
>   uhub1 detached
>   iwm0: acquiring device failed
>   uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev
> 3.00/1.00 addr 1
>   uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev
> 3.00/1.00 addr 1
>   uvideo0 at uhub1 port 2 configuration 1 interface 0 "SunplusIT Inc
> Integrated Camera" rev 2.01/54.22 addr 2
>   video0 at uvideo0
> 
> I presume that the first four lines are from suspending? And that the
> remaining lines are from resuming?
> 
> I wondered if it could be that the delay is being caused by the failure to
> acquire iwm0? (iwm0 is my Intel WiFi card)
> So, I disabled my WiFi in BIOS. I also disabled USB, Camera, Microphone,
> Ethernet, and the Memory Card slot. But the problem is still there!
> 
> Now, these lines appear on dmesg on suspend-resume (I don't know what
> uhub0 and uhub1 are) -
> 
>   uhub0 detached
>   uhub1 detached
>   uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" 
> rev
> 3.00/1.00 addr 1
>   uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" 
> rev
> 3.00/1.00 addr 1
> 
> 
> I have no idea what is causing the delay. Any help to identify the
> problem is appreciated.
> 
> Please pardon me if this is a simple mistake in my part... I am new to
> OpenBSD :)
> 
> 
> 
> The full dmesg (with everything except Bluetooth enabled) follows -
> -
> OpenBSD 6.9 (GENERIC.MP) #1: Sat May 22 13:19:59 MDT 2021
> 
> r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 32103845888 (30616MB)
> avail mem = 31115493376 (29674MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xbc627000 (58 entries)
> bios0: vendor LENOVO version "R11ET40W (1.20 )" date 11/17/2020
> bios0: LENOVO 20NES02J00
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT SSDT SSDT TPM2 SSDT MSDM BATB HPET APIC
> MCFG SBST WSMT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI
> acpi0: wakeup devices GPP0(S3) GPP1(S4) GPP2(S3) GPP3(S3) GPP4(S3)
> GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3)
> SLPB(S3)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx, 2096.33 MHz, 17-18-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 8-way L2 cache
> cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx, 2096.08 MHz, 17-18-01
> cpu1: 
> 

Re: libexpat.so.14.0 missing in latest -current

2021-05-27 Thread Theo de Raadt
Anthony Campbell  wrote:

> After upgrading to -current today I found that xenodm would not run
> because of a missing /usr/lib/libexpat.so.14.0_ Various other things
> didn['t work either, including vim.
> 
> As a temporary work-round I made a link for it to libexpat.so.13.0,
> which seems to have made everything function again.

Occasionally a bad snapshot will ship out, because we are actively
developing.  It is rare.  Shrug.



Re: Error making 002_libx11.patch.sig

2021-05-18 Thread Theo de Raadt
You are not building using the correct procedure.

Sorry, we don't have time to teach that.

Please use the syspatches, or the snapshots, or learn to do full builds.

The latter is fully documented in manual pages, and reaching for the
mailing list is inappropriate.

Jonathan Drews  wrote:

> OpenBSD 6.9 GENERIC.MP#473 amd64
> 
> Hi Folks:
> 
> I am trying to patch Xenocara with 002_libx11.patch.sig. I first
> applied  make -f Makefile.bsd-wrapper obj. Afterwards
> I get the following error message when I do make -f
> Makefile.bsd-wrapper build:
> 
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating include/Makefile
> rm: include/Makefile: Permission denied
> config.status: error: could not create include/Makefile
> *** Error 1 in . (/usr/X11R6/share/mk/bsd.xorg.mk:158
> 'config.status')
> *** Error 2 in /usr/xenocara/lib/libX11
> (/usr/X11R6/share/mk/bsd.xorg.mk:196 'build')
> 
> my /usr/include has the following permissions
> jack# ls -lhd /usr/include/
> 
> drwxr-xr-x  32 root  bin   3.0K May  1 20:24 /usr/include/
> 
> My xenocara directory has the following permissions
> jack# ls -lhd /usr/xenocara/
> 
> drwxr-xr-x  16 root  wheel   512B Apr 17 16:16 /usr/xenocara/
> 
> 
> Any ideas as to what I am doing wrong?
> 
> 
> Kind regards,
> 
> Jonathan
> 



Re: Curious about errata patches

2021-05-13 Thread Theo de Raadt
Manually and carefully.

Irshad Sulaiman  wrote:

> Hi everybody 
> 
> Just to know about errata patches : how openbsd developers Generates 
> errata patches 
> Like , I know (diff -upf ) generates diff 
> How you ppl generate patches like below , is there any tool or scripts to do 
> that 
> 
> OpenBSD 6.9 errata 001, May 4, 2021:
> 
> vmd guests can trigger excessive log messages on the host by sending
> certain network packets.
> 
> Apply by doing:
> signify -Vep /etc/signify/openbsd-69-base.pub -x 001_vmd.patch.sig \
> -m - | (cd /usr/src && patch -p0)
> 



Re: VMM 6.9amd64 host video acceleration

2021-05-12 Thread Theo de Raadt
I am terribly sorry you aren't satisfied with what is possible in OpenBSD,
and will have to return to a Linux or Windows environment.

Martin  wrote:

> Hi Theo,
> 
> Sure, for online videos I'm using OpenBSD host with appropriate browser 
> installed. Just wonder about VMM to move all 'potentially dangerous' things 
> to a linux VM and remove any browsers from the host.
> 
> Martin
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, May 12, 2021 6:07 PM, Theo de Raadt  wrote:
> 
> > Have you considered using a real computer?
> >
> > Martin martin...@protonmail.com wrote:
> >
> > > Hi Dave,
> > > Can you recommend any way to see online videos without shuttering? Modern 
> > > CPUs can't smoothly play it in software emulation, unfortunately.
> > > Martin
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Wednesday, May 12, 2021 1:43 PM, Dave Voutila d...@sisu.io wrote:
> > >
> > > > Martin writes:
> > > >
> > > > > Hi list,
> > > > > Just wonder how to enable video acceleration on VMM guest's side 
> > > > > (Debian) if it was possible. Maybe PCIe passthru should be present 
> > > > > for that purpose?
> > > >
> > > > There is nothing to accelerate: vmd(8) doesn't emulate a display or
> > > > video device. vmm(4) doesn't support pass-through to host hardware
> > > > either.
> > > > -dv
> 
> 



Re: VMM 6.9amd64 host video acceleration

2021-05-12 Thread Theo de Raadt
Have you considered using a real computer?


Martin  wrote:

> Hi Theo,
> 
> Sure, for online videos I'm using OpenBSD host with appropriate browser 
> installed. Just wonder about VMM to move all 'potentially dangerous' things 
> to a linux VM and remove any browsers from the host.
> 
> Martin
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, May 12, 2021 6:07 PM, Theo de Raadt  wrote:
> 
> > Have you considered using a real computer?
> >
> > Martin martin...@protonmail.com wrote:
> >
> > > Hi Dave,
> > > Can you recommend any way to see online videos without shuttering? Modern 
> > > CPUs can't smoothly play it in software emulation, unfortunately.
> > > Martin
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Wednesday, May 12, 2021 1:43 PM, Dave Voutila d...@sisu.io wrote:
> > >
> > > > Martin writes:
> > > >
> > > > > Hi list,
> > > > > Just wonder how to enable video acceleration on VMM guest's side 
> > > > > (Debian) if it was possible. Maybe PCIe passthru should be present 
> > > > > for that purpose?
> > > >
> > > > There is nothing to accelerate: vmd(8) doesn't emulate a display or
> > > > video device. vmm(4) doesn't support pass-through to host hardware
> > > > either.
> > > > -dv
> 
> 



Re: VMM 6.9amd64 host video acceleration

2021-05-12 Thread Theo de Raadt
Have you considered using a real computer?

Martin  wrote:

> Hi Dave,
> 
> Can you recommend any way to see online videos without shuttering? Modern 
> CPUs can't smoothly play it in software emulation, unfortunately.
> 
> Martin
> 
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, May 12, 2021 1:43 PM, Dave Voutila  wrote:
> 
> > Martin writes:
> >
> > > Hi list,
> > > Just wonder how to enable video acceleration on VMM guest's side (Debian) 
> > > if it was possible. Maybe PCIe passthru should be present for that 
> > > purpose?
> >
> > There is nothing to accelerate: vmd(8) doesn't emulate a display or
> > video device. vmm(4) doesn't support pass-through to host hardware
> > either.
> >
> > -dv
> 
> 



Re: kernel size over time

2021-05-12 Thread Theo de Raadt
kernel-side code for X

Kent Watsen  wrote:

> I used to be able to install OpenBSD on a 1G disk (sets: -x* -g* -c*) and 
> 256M ram, but no more….now a 1280M disk + 384M ram is needed.
> 
> After a little sleuthing, the primary reason seems to be that the size of 
> /usr/share/relink/kernel/GENERIC/ has been growing:
> 
>   Rel  Size
>    
>   6.4  217M
>   6.5  223M
>   6.6  339M
>   6.7  
>   6.8  465M
>   6.9  469M
> 
> Not that it really matters, but does anyone know why the kernel has grown 
> this much over the releases?
> 
> K.
> 



Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-05-01 Thread Theo de Raadt
The FAQ speaks to this matter.

Noone else has anything more to say.

Please stop begging for personal handholding, everyone is getting
embarrassed.



Luke Small  wrote:

> I tried that by the way. I even mv’ed my pf.conf to nullify it and tried
> and it couldn’t download from the gigenet mirror which absolutely has the
> 6.9 files. It didn’t work at all. Sysupgrade really needs to be able to be
> working on versions as well as -r and -s! The program isn’t intelligent
> enough.
> 
> On Sat, May 1, 2021 at 5:26 PM jpeg bild  wrote:
> 
> > If you want to move back to stable, you would have to boot bsd.rd and
> > select "Upgrade" in the prompt, then install from http with the correct
> > path for 6.9-stable
> >
> > On Fri Apr 30, 2021 at 9:49 PM CST, Luke Small wrote:
> > > We’re there major irreversible changes made to the following snapshot:
> > >
> > > kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr 26 02:26:53
> > > MDT
> > > 2021
> > >
> > > which would render in incapable of a downgrade?
> > > --
> > > -Luke
> >
> > --
> -Luke



Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-05-01 Thread Theo de Raadt
Carson Chittom  wrote:

> On Sat, May 1, 2021, at 1:14 PM, Luke Small wrote:
> > I google searched: “site:openbsd.org (snapshot OR current) (stable OR
> > release) faq”
> > 
> > and found no results which speaks of minor downgrades.
> > 
> > Also, “sysupgrade -r” defaults to 7.0 when trying to upgrade from previous
> > 6.9 snapshots to release. Is it intended to require folks to use bsd.rd (or
> > use an iso) to make that change?
> 
> See the very first sentence on this page: 
> https://www.openbsd.org/faq/upgrade69.html

No kidding.



Re: AUTOCONF4 flag

2021-05-01 Thread Theo de Raadt
Peter Wens  wrote:

> Hi,
> 
> In OpenSBD 6.9 the AUTOCONF4 flag is not set
> with 'dhcp' set in hostname.if (from fresh install)

You have described this incorrectly.  In 6.8, choosing "dhcp" would run
dhclient(8) in that interfaces, and dhclient would set the AUTOCONF4 flag.
That was incorrect.  AUTOCONF4 is supposed to work like AUTOCONF6.

These are per-interface flags which indicate a request: "Someone please
go get us a dynamic address".  dhclient incorrectly believed the flag
meant "I have gotten a dynamic address"

> If 'autoconf' instead of 'dhcp' is used with dhcpleased
> the flag is set.
> 
> Is this intentional in 6.9?

Yes, it is intentional.

In 6.9:

1) 'autoconf' is to instruct dhcpleased(8), to do dhcp lease-learning, then
   dhcpleased(8) will communicate learned DNS configuration via
   route-socket to resolvd(8), which will make changes to /etc/resolv.conf

2) 'dhcp' runs a per-interface dhclient(8) which will manage /etc/resolv.conf

The two dhcp modes of operation are incompatible.

By 7.0 we hope to switch to the model described in (1), because this
allows resolvd(8) to blend DNS configuration from multiple sources into
/etc/resolv.conf, rather than havine one per-interface daemon smashing
the file.

   



Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-04-30 Thread Theo de Raadt
Luke Small  wrote:

> We’re there major irreversible changes made to the following snapshot:
> 
> kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr 26 02:26:53 MDT
> 2021
> 
> which would render in incapable of a downgrade?

The FAQ has a clear & simple answer to that question, and it is our
belief that noone deserves an independently decided answer on a
case-by-case basis.  Basically, stop wasting our time.



OpenBSD 6.9 released May 1

2021-04-30 Thread Theo de Raadt



- OpenBSD 6.9 RELEASED -

May 1, 2021.

We are pleased to announce the official release of OpenBSD 6.9.
This is our 50th release.  We remain proud of OpenBSD's record of more
than twenty years with only two remote holes in the default install.

As in our previous releases, 6.9 provides significant improvements,
including new features, in nearly all areas of the system:

 - New/extended platforms:
o Support for the powerpc64 platform was improved:
   - Added astfb(4), a driver for the framebuffer of the Aspeed
 BMC found on many POWER8 and POWER9 systems.
   - Added bsd.mp to powerpc64's installXX.{img,iso}.
   - Added RETGUARD implementation for powerpc and powerpc64.
   - Added a workaround for PCIO devices that cannot address the
 full 64-bit PCI address space to powerpc64. Needed for
 radeondrm(4) and amdgpu(4) since Radeon GPUs only implement
 36, 40, or 44 bits of address space.
   - Added limited emulation of unaligned access in the powerpc64
 kernel.
   - Added support for netbooting to the powerpc64 RAMDISK kernel.
   - Fixed booting on powerpc64 machines with memory banks higher
 in physical address space, needing a larger TCE table.
   - Introduced power-saving mode on POWER9 CPUs.
   - Enabled floating-point exceptions on powerpc64.
   - Added support for ipmi(4) on PowerNV systems.
o Preliminary support was added for devices using the Apple M1 SoC:
   - Recognized Apple Icestorm/Firestorm cores on arm64.
   - Added support for BCM4378 chips, as found on the Apple M1
 SoCs, to bwfm(4).
   - Added exuart(4) support for the UART found on the Apple M1
 SoC.
   - Added apldog(4), a driver for the watchdog on Apple M1 SoCs,
 allowing reboot of the machine.
   - Added aplintc(4), a driver for the interrupt controller found
 on Apple M1 SoCs.
   - Added aplpcie(4), a driver for the PCIe host bridge on Apple
 M1 SoCs.
   - Added apldart(4), a driver for the IOMMU on Apple M1 SoCs.
   - Added support for CPUs with 8-bit ASIDs such as those on
 Apple's M1 SoC.
o The arm64 platform support was improved with the following
  changes:
   - Optimized arm64 copyin(9), copyout(9) and kcopy(9) by doing
 16-byte copies if possible.
   - Added recognition of Cortex-A78AE, Cortex-X1 and Neoverse V1
 arm64 CPUs.
   - Added clock support for i.MX8MP SoCs.
   - Added support for the VF610 I2C controller to imxiic(4).
   - Added dwgpio(4), a driver for the Synopsys DesignWare GPIO
 controller.
   - Added amlpinctrl(4) support for the "Always On" GPIOs.
   - Made large read and write transactions work in amliic(4).
   - Added support for the PCIe controller found on Amlogic
 G12A/G12B/SM1 SoCs to dwpcie(4).
   - Implemented legacy interrupt support to mvkpcie(4).
   - Added cryptox(4), a driver for armv8 cryptographic
 extensions.
   - Added support for PCIe on the NanoPi R4S to rkpcie(4).
   - Added smmu(4), a driver for the ARM System MMU.
   - Introduced an IOVA early-allocation scheme in smmu(4),
 mitigating the performance penalty of typical IOVA allocation
 designs.
   - Introduced Guard Pages in smmu(4), to spot misuse and
 misconfiguration of I/O devices more easily.
   - Added support for RK809 to rkpmic(4), as seen on the Rock Pi
 N10 with the rk3399pro.
   - Added support for sdhc(4) on the Raspberry Pi in ACPI mode.
   - Enabled ixl(4) on arm64.
   - Updated device-tree bindings for cwfg(4) battery capacity
 driver to correct attaching and account for monitoring
 interval change, making cwfg(4) export values under
 hw.sensors as expected when using a Pinebook Pro.
   - Added ARMv8-5 instruction set related CPU features to arm64.

 - Various kernel improvements:
o Added the RAID1C (encrypted raid1) softraid(4) discipline,
  encrypting data like the CRYPTO discipline and accepting multiple
  chunks during creation and assembly like the RAID1 discipline.
o Corrected raidlevel verification specified by the -c option in
  bioctl(8).
o Introduced kern.video.record for video(4) devices, a privacy
  feature analog to the kern.audio.record sysctl(8) parameter for
  audio(4) devices. By default, kern.video.record will be set to
  zero and blank all data delivered by drivers attaching to
  video(4).
o Allowed a process to open a video(4) device multiple times. Fixes
  webcam usage with Firefox and BigBlueButton.
o Enabled multiple opens of a video(4) device as described in the
  V4L2 specification.
o Added basic support for kclock timeouts to timeout(9).
o Changed the pool(9) timeouts 

Re: Fwd: umm_map returns unaligned address?

2021-04-23 Thread Theo de Raadt
Alessandro Pistocchi  wrote:

> During the syscall I allocate some memory that I want to share between the
> kernel and the calling process.

When you get the mapping working, it will not work as well as you like.

Compiler re-ordering of writes & reads, caches, write buffers, and other
details such as non-TSO will creat problems, meaning you'll need very careful
data-structure, and great care with co-dependent fields, otherwise one side
can fool the other.

That is why the copyin/copyout approach is used as a high-level 
serializing-forcing
primitive in most operating systems.

But since you don't show your whole diff.. I suspect this is a waste of time.



Re: Cultural underground legende Seymour Cray and his legacy

2021-04-22 Thread Theo de Raadt
Balder,

Get your non-openbsd related crap off the openbsd lists.

In other words: go away.


Balder Oddson  wrote:

> On Thu, Apr 22, 2021 at 12:28:28AM +0200, Balder Oddson wrote:
> > Whereof everyone is interested,
> > 
> > 
> > 
> > A few things about his architecture is extraordinary special.
> > 
> > #1 ideal properties, can never be done better for some things.
> > #1.1 analogue, you need ground and good drain, to do work during weak force 
> > pull.
> > #1.2 physical, independent IC's, relying on physics for syncronization.
> > #1.2.1 allowing digital global sync between die slots, async, but local
> > sync with global clock.
> > #1.3 as a turing machine, everything is virtually represented with
> > arrays of addresesses in cintinous memory.
> > #1.3.1 You get scalar operations on your vectors with SIMD insutrctions.
> > #1.3.2 Remotely scatter data in remote memory, that is gathered into
> > another continous area of memory with addresses to data.
> > 
> > 
> > On the one hand, where this gives 8x the performance at a high price, it
> > likely caused as much awe, inspiration and anxiety in the finance sector
> > where Cray got the funding to research, build and sell these beasts.
> > 
> > The Cult of the Holy Cow, and The Cult of the Dead Cow are oxymorons if
> > the contexts abd historic circumstances are to be considered.
> > 
> > Using hex numbers, would ideally imply an understanding of the Cray
> > architecture, and why it perhaps now can be be software defined.
> > 
> 
> The puns where uninviting, and didn't inspire snide remarks and comments
> that weren't drivel without content and context.
> 
> Thereof interests in logic has invited investigations of tautologies as
> a concept in logic, whereof one cannt speak and merely add drivel.
> 
> Not sure if it's true entirely, but for the orginal Cray's, first an
> engineer came to try and get it to work, if not, Seymour gave it a try
> before shipping a replacement. Likely because he tortured the
> electromechanical properties around the central part so much that it was
> touchy feely.
> 
> Anyone intelligeble around this topic likely have passing interest for
> having a gray beard and being sick and tiered of "what did cray do",
> "what if he set a more reasonable goal than 10x the closest competitor".
> 
> 
> Ciao,
> Balder
> 



Re: Issue with Ubiquiti ERL upgrade from 6.7 to 6.8 via sysupgrade (octeon)

2021-03-31 Thread Theo de Raadt
your PROM is likely setup to boot a "bsd" kernel in the msdos partition,
rather than the "boot" file.  The "boot" file will load /bsd from the ffs
partition.

Amarendra Godbole  wrote:

> So I used sysupgrade to upgrade the ERL from 6.7 to 6.8. It went through
> everything fine, downloaded the sets, extracts, etc. and reboots. However,
> it boots back into the old 6.7 kernel. I can see /bsd.upgrade created, and
> /home/_sysupgrade is empty. but did not see any option to trigger the
> upgrade. I thought it should have been automatically handled by sysupgrade.
> 
> What did I miss?
> 
> Thanks.
> 
> -Amarendra
> 
> 
> erl# uname -a
> OpenBSD erl.lan 6.7 GENERIC.MP#134 octeon
> 
> erl# ls -l
> total 79128
> -rw-r--r--   1 root  wheel  578 May  7  2020 .cshrc
> -rw-r--r--   1 root  wheel  468 May  7  2020 .profile
> drwxr-xr-x   2 root  wheel  512 May  7  2020 altroot
> -rw-r--r--   1 root  wheel  160 Mar 31 00:08 auto_upgrade.conf
> drwxr-xr-x   2 root  wheel 1024 May  7  2020 bin
> -rwx--   1 root  wheel  7626800 Mar 31 00:10 bsd
> -rwx--   1 root  wheel  7623592 Mar 31 00:01 bsd.booted
> -rw---   1 root  wheel  8843608 May  7  2020 bsd.rd
> -rw---   1 root  wheel  7568260 May  7  2020 bsd.sp
> -rwx--   1 root  wheel  8823044 Mar 31 00:09 bsd.upgrade
> drwxr-xr-x   4 root  wheel18432 Mar 31 00:10 dev
> drwxr-xr-x  23 root  wheel 2048 Mar 31 00:11 etc
> drwxr-xr-x   4 root  wheel  512 Oct 15 21:09 home
> drwxr-xr-x   2 root  wheel  512 May  7  2020 mnt
> drwx--   3 root  wheel  512 Mar 31 01:30 root
> drwxr-xr-x   2 root  wheel 1536 May  7  2020 sbin
> lrwxrwx---   1 root  wheel   11 May  7  2020 sys -> usr/src/sys
> drwxrwxrwt   6 root  wheel  512 Mar 31 07:45 tmp
> drwxr-xr-x  16 root  wheel  512 Sep  7  2020 usr
> drwxr-xr-x  23 root  wheel  512 May  7  2020 var
> erl#
> 
> erl# dmesg
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2020 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> 
> OpenBSD 6.7 (GENERIC.MP) #134: Thu May  7 16:05:06 MDT 2020
> dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
> real mem = 536870912 (512MB)
> avail mem = 506740736 (483MB)
> mainbus0 at root: board 20002 rev 2.18
> cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
> cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
> cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
> cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
> clock0 at mainbus0: int 5
> octcrypto0 at mainbus0
> iobus0 at mainbus0
> simplebus0 at iobus0: "soc"
> octciu0 at simplebus0
> octsmi0 at simplebus0
> octpip0 at simplebus0
> octgmx0 at octpip0 interface 0
> cnmac0 at octgmx0: RGMII, address 78:8a:20:46:a8:c0
> atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2
> cnmac1 at octgmx0: RGMII, address 78:8a:20:46:a8:c1
> atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2
> cnmac2 at octgmx0: RGMII, address 78:8a:20:46:a8:c2
> atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2
> com0 at simplebus0: ns16550a, 64 byte fifo
> com0: console
> dwctwo0 at iobus0 base 0x118006800 irq 56
> usb0 at dwctwo0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev
> 2.00/1.00 addr 1
> octrng0 at iobus0 base 0x14000 irq 0
> /dev/ksyms: Symbol table not valid.
> umass0 at uhub0 port 1 configuration 1 interface 0 "Lexar USB Flash Drive"
> rev 2.10/11.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus0 at umass0: 2 targets, initiator 0
> sd0 at scsibus0 targ 1 lun 0:  removable
> serial.21c40cd1719080003000
> sd0: 30526MB, 512 bytes/sector, 62517248 sectors
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> boot device: sd0
> root on sd0a (2124441bc835a462.a) swap on sd0b dump on sd0b
> WARNING: No TOD clock, believing file system.
> WARNING: CHECK AND RESET THE DATE!



Re: Adding accessibility for blind and low vision individuals to OpenBSD?

2021-03-25 Thread Theo de Raadt
> If the tmux server uses the TMux protocol as described in RFC 1692, it

Uhm no, that is quite a big misunderstanding.



Re: /usr/bin/ld and /usr/bin/ld.lld

2021-03-23 Thread Theo de Raadt
KAWAMATA Yoshihiro  wrote:

> When I was looking at the snapshot package, I found that /usr/bin/ld
> and /usr/bin/ld.lld have the same contents and properties, but they
> are independent.
> 
> Upon further investigation, it seems that this is due to the fact that
> /usr/bin/ld is contained in base69.tgz and /usr/bin/ld.ld is contained
> in comp69.tgz.  It is likely that ld is included in base.tgz in order
> to run KARL.
> 
> Since ld and ld.lld are identical, I think it would be preferable to
> include both in base.tgz. This will reduce the total size by about
> 40MB.
> 
> If you build from the source tree, ld and ld.lld will be installed
> hard-linked.

Some other scripts need changes also.

Index: checkflist
===
RCS file: /cvs/src/distrib/sets/checkflist,v
retrieving revision 1.13
diff -u -p -u -r1.13 checkflist
--- checkflist  17 Apr 2017 19:44:59 -  1.13
+++ checkflist  23 Mar 2021 17:04:03 -
@@ -38,11 +38,11 @@ arch=`machine`
 
 for i in base comp etc game man; do
cat ./lists/$i/mi ./lists/$i/md.${arch}
-   if [ $i = comp ]; then
-   [ -f ./lists/comp/gcc.${arch} ] && \
-   cat ./lists/comp/gcc.${arch}
-   [ -f ./lists/comp/clang.${arch} ] && \
-   cat ./lists/comp/clang.${arch}
+   if [ $i = comp -o $i = base ]; then
+   [ -f ./lists/$i/gcc.${arch} ] && \
+   cat ./lists/$i/gcc.${arch}
+   [ -f ./lists/$i/clang.${arch} ] && \
+   cat ./lists/$i/clang.${arch}
fi
 done | sort >$TMP1
 
Index: makelocatedb
===
RCS file: /cvs/src/distrib/sets/makelocatedb,v
retrieving revision 1.2
diff -u -p -u -r1.2 makelocatedb
--- makelocatedb18 Apr 2017 07:13:39 -  1.2
+++ makelocatedb23 Mar 2021 17:10:18 -
@@ -39,7 +39,7 @@ cd ${lists}
 for i in base comp etc game man; do
{
case $i in
-   comp)
+   base|comp)
[ -f $i/gcc.${arch} ] && cat $i/gcc.${arch}
[ -f $i/clang.${arch} ] && cat $i/clang.${arch}
;;
Index: maketars
===
RCS file: /cvs/src/distrib/sets/maketars,v
retrieving revision 1.26
diff -u -p -u -r1.26 maketars
--- maketars17 Apr 2017 19:44:59 -  1.26
+++ maketars23 Mar 2021 17:09:47 -
@@ -56,7 +56,7 @@ cd $fsdir
 for i in base comp game man; do
echo -n "$i: "
cat ${lists}/$i/mi ${lists}/$i/md.${arch} > $TMP2
-   if [ $i = comp ]; then
+   if [ $i = comp -o $i = base ]; then
[ -f ${lists}/$i/gcc.${arch} ] && \
cat ${lists}/$i/gcc.${arch} >> $TMP2
[ -f ${lists}/$i/clang.${arch} ] && \
Index: lists/base/clang.amd64
===
RCS file: lists/base/clang.amd64
diff -N lists/base/clang.amd64
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.amd64  23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.arm64
===
RCS file: lists/base/clang.arm64
diff -N lists/base/clang.arm64
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.arm64  23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.armv7
===
RCS file: lists/base/clang.armv7
diff -N lists/base/clang.armv7
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.armv7  23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.i386
===
RCS file: lists/base/clang.i386
diff -N lists/base/clang.i386
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.i386   23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.loongson
===
RCS file: lists/base/clang.loongson
diff -N lists/base/clang.loongson
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.loongson   23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.macppc
===
RCS file: lists/base/clang.macppc
diff -N lists/base/clang.macppc
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.macppc 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.octeon
===
RCS file: lists/base/clang.octeon
diff -N lists/base/clang.octeon
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.octeon 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.powerpc64

Re: /usr/bin/ld and /usr/bin/ld.lld

2021-03-23 Thread Theo de Raadt
KAWAMATA Yoshihiro  wrote:

> When I was looking at the snapshot package, I found that /usr/bin/ld
> and /usr/bin/ld.lld have the same contents and properties, but they
> are independent.
> 
> Upon further investigation, it seems that this is due to the fact that
> /usr/bin/ld is contained in base69.tgz and /usr/bin/ld.ld is contained
> in comp69.tgz.  It is likely that ld is included in base.tgz in order
> to run KARL.
> 
> Since ld and ld.lld are identical, I think it would be preferable to
> include both in base.tgz. This will reduce the total size by about
> 40MB.
> 
> If you build from the source tree, ld and ld.lld will be installed
> hard-linked.

true.

A diff to do that probably looks like the following.  I will test it in
snapshots, and refine it if needed.

Index: checkflist
===
RCS file: /cvs/src/distrib/sets/checkflist,v
retrieving revision 1.13
diff -u -p -u -r1.13 checkflist
--- checkflist  17 Apr 2017 19:44:59 -  1.13
+++ checkflist  23 Mar 2021 17:04:03 -
@@ -38,11 +38,11 @@ arch=`machine`
 
 for i in base comp etc game man; do
cat ./lists/$i/mi ./lists/$i/md.${arch}
-   if [ $i = comp ]; then
-   [ -f ./lists/comp/gcc.${arch} ] && \
-   cat ./lists/comp/gcc.${arch}
-   [ -f ./lists/comp/clang.${arch} ] && \
-   cat ./lists/comp/clang.${arch}
+   if [ $i = comp -o $i = base ]; then
+   [ -f ./lists/$i/gcc.${arch} ] && \
+   cat ./lists/$i/gcc.${arch}
+   [ -f ./lists/$i/clang.${arch} ] && \
+   cat ./lists/$i/clang.${arch}
fi
 done | sort >$TMP1
 
Index: lists/base/clang.amd64
===
RCS file: lists/base/clang.amd64
diff -N lists/base/clang.amd64
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.amd64  23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.arm64
===
RCS file: lists/base/clang.arm64
diff -N lists/base/clang.arm64
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.arm64  23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.armv7
===
RCS file: lists/base/clang.armv7
diff -N lists/base/clang.armv7
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.armv7  23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.i386
===
RCS file: lists/base/clang.i386
diff -N lists/base/clang.i386
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.i386   23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.loongson
===
RCS file: lists/base/clang.loongson
diff -N lists/base/clang.loongson
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.loongson   23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.macppc
===
RCS file: lists/base/clang.macppc
diff -N lists/base/clang.macppc
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.macppc 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.octeon
===
RCS file: lists/base/clang.octeon
diff -N lists/base/clang.octeon
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.octeon 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.powerpc64
===
RCS file: lists/base/clang.powerpc64
diff -N lists/base/clang.powerpc64
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.powerpc64  23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.sgi
===
RCS file: lists/base/clang.sgi
diff -N lists/base/clang.sgi
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.sgi23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.sparc64
===
RCS file: lists/base/clang.sparc64
diff -N lists/base/clang.sparc64
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/clang.sparc6423 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/gcc.alpha
===
RCS file: lists/base/gcc.alpha
diff -N lists/base/gcc.alpha
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lists/base/gcc.alpha23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.bfd
Index: lists/base/gcc.amd64

Re: Documentation on OpenBSD's 3-process privsep model?

2021-03-22 Thread Theo de Raadt
misopolemiac  wrote:

> I'd appreciate some pointers to documentation or minimal examples of
> the 3-process privilege separation model for OpenBSD's daemons.
> Internet searches pointed to skeleton examples at
> github.com/krwesterback/newd and github.com/krwesterback/newdctl, but
> those repos are now dead and it's unclear how authoritative they were
> in the first place.

This is not difficult: Use the repository.

Go find a privsep daemon.  Go look at the earliest revisions, when the
problems were simple.  Follow the commits forward.

And learn.



Re: 6.8 Install Issue

2021-02-26 Thread Theo de Raadt
Kenneth Hendrickson  wrote:

> Thanks again Theo.
> 
> > WARNING: / was not properly unmounted
> 
> That is true for the disk in that system.

You don't understand the OpenBSD installed.  That / is the root filesystem
of the install-tool fileysystem inside the bsd.rd

It is corrupt.  Someone wrote to it.  Whatever happpened to the bsd.rd
you used is outside our control, because it has been modified.




Re: 6.8 Install Issue

2021-02-26 Thread Theo de Raadt
Kenneth Hendrickson  wrote:

> Thanks Theo.
> 
> Here is what happened beforehand:
> 
> Welcome to the OpenBSD/amd64 6.8 installation program.
> WARNING: / was not properly unmounted

  

I have no idea what is going on here, but this never happens with
an OpenBSD install image.  The mr.fs inside the bsd.rd is always
clean.

This is not normal, and hints that you have changed something.



Re: 6.8 Install Issue

2021-02-26 Thread Theo de Raadt
Kenneth Hendrickson  wrote:

...
> No label changes.
> newfs: /dev/rsd0a is mounted on /mnt

  ^^^

Well you had that partition mounted, probably with a different disklabel
and sizes, so it was not newfs'd. 

You did something manual earlier.  You didn't show that which created
the problem.



Re: tc= in remote(5) example

2021-02-18 Thread Theo de Raadt
Jan Stary  wrote:

> /etc/examples/remote contains the following stanzas:
> 
>   unixhost:\
>   :br#9600:
> 
>   cua00|For i386,macppc:\
>   :dv=/dev/cua00:tc=unixhost:
> 
>   cuaa|For sparc:\
>   :dv=/dev/cuaa:tc=unixhost:
> 
> 
> The remote(5) manpage describes br, dc, dv
> but not tc, which seems to be used here as an include.
> Is it described elsewhere or is that an omission?

The second sentence of the manual page is:

It is an ASCII file structured somewhat like the termcap(5) file.

That is slightly erroneous.  It is not "somewhat like", but "precisely like".

Around 4.4BSD this format was generalized for other purposes also, and
renamed "capability database", with cap_mkdb(1) and cgetent(3)
functions.

Thus, the cu(1) code uses the cgetent(3) family of library functions,
and thus gains the "tc" capability, which is similar to cpp "include".

Other "capability database" format details not documented in remote(5)
percolate up (for example, the behaviour of '\' is not entirely
intuitive), and these narrow details are not documented in remote(5)
either... how far should this go?

As to where "tc" is documented:

In termcap(5), "tc" is explained thus:

 tc   str  Entry of similar terminal; must be last.

I'll admit that is poor and vague.

It is explained carefully in the cgetent(3) manual page, in the
subsection "Capability database semantics", but that page isn't Xr'd,
and the subsection is so far down the page I am not sure a reader would
scan far enough down to learn anything.

I don't know what precisely should be done.



Re: OpenBSD 6.7-stable macppc hacked?

2021-02-16 Thread Theo de Raadt
ANSI sequences appeared on ttyC0.

init is running getty there, which exec'd login, which is running
login_passwd to perform a login.



Riccardo Giuntoli  wrote:

> Hi there I've got a strange process that spawn from init in the environment
> above. No network traffic. Look ahead:
> 
>  |-+= 51452 root login -p -- \^[[7~\^[[7~\^[[7~\^[[7~\^[[7~\^[[7~\^[[7~\^[[7
>  | \--- 73422 root passwd -v login=yes -s login --
> \^[[7~\^[[7~\^[[7~\^[[7~\^[[7~\^[[7~\^[[7~\^[[7 default (login_passwd)
> 
> They depend directly from init.
> 
> taglio@cyberanarkhia:/sbin$ ls -al init
> 
> 
> 
> -r-xr-xr-x  1 root  bin  345348 Nov 25 19:39 init*
> taglio@cyberanarkhia:/sbin$
> 
> taglio@cyberanarkhia:/sbin$ md5 init
> 
> 
> 
> MD5 (init) = 0fbb14ece72860443abe2c2ddb2ae96a
> taglio@cyberanarkhia:/sbin$
> 
> [ using 1142476 bytes of bsd ELF symbol table ]
> console out [NVDA,Display-B] console in [keyboard], using USB
> using parent NVDA,Parent:: memaddr 9800, size 800 : consaddr
> 98004000 : ioaddr 9100, size 100: width 1280 linebytes 1536 height
> 1024 depth 8
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2020 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> 
> OpenBSD 6.7-stable (GENERIC.MP) #1: Mon Dec 21 08:42:13 CET 2020
> tag...@cyberanarkhia.telecomlobby.net:/sys/arch/macppc/compile/
> GENERIC.MP
> 
> root@cyberanarkhia:/usr/libexec/auth# ls -al
> total 388
> drwxr-x---  2 root  auth   512 Nov 25 19:39 ./
> drwxr-xr-x  6 root  wheel 1024 Dec 22 18:54 ../
> -r-xr-sr-x  4 root  _token   21900 Nov 25 19:39 login_activ*
> -r-sr-xr-x  1 root  auth  9340 Nov 25 19:39 login_chpass*
> -r-xr-sr-x  4 root  _token   21900 Nov 25 19:39 login_crypto*
> -r-sr-xr-x  1 root  auth 17688 Nov 25 19:39 login_lchpass*
> -r-sr-xr-x  1 root  auth  9340 Nov 25 19:39 login_passwd*
> -r-xr-sr-x  1 root  _radius  17628 Nov 25 19:39 login_radius*
> -r-xr-xr-x  1 root  auth  9340 Nov 25 19:39 login_reject*
> -r-xr-sr-x  1 root  auth 13480 Nov 25 19:39 login_skey*
> -r-xr-sr-x  4 root  _token   21900 Nov 25 19:39 login_snk*
> -r-xr-sr-x  4 root  _token   21900 Nov 25 19:39 login_token*
> -r-xr-sr-x  1 root  auth 21628 Nov 25 19:39 login_yubikey*
> root@cyberanarkhia:/usr/libexec/auth#
> 
> root@cyberanarkhia:/usr/libexec/auth# md5 login_passwd
> 
> 
> 
> MD5 (login_passwd) = 17ed9f36a170b5614de566f71768e753
> root@cyberanarkhia:/usr/libexec/auth#
> 
> root login  39663 text /usr52236  -r-xr-xr-x r25824
> root login  39663   wd /   2  drwxr-xr-x r 1024
> root login  396630 / 741  crw---rwttyC0
> root login  396631 / 741  crw---rwttyC0
> root login  396632 / 741  crw---rwttyC0
> root login  396633* unix stream 0x325e9a08 <-> 0x325e90a8
> root login_passwd 50752 text /usr78065  -r-sr-xr-x r
> 9340
> root login_passwd 50752   wd /home 4595712  drwxr-xr-x r
> 1536
> root login_passwd 507520 / 564  crw--wrw
>  ttyp1
> root login_passwd 507521 / 564  crw--wrw
>  ttyp1
> root login_passwd 507522 / 564  crw--wrw
>  ttyp1
> root login_passwd 507523* unix stream 0x325e9468 <-> 0x325e9968
> root login_passwd 507524 /1090  crw-rw-rw-   rwp
>  tty
> 
> Any suggestions?
> 
> Nice regards,
> 
> RG
> -- 
> Name: Riccardo Giuntoli
> Email: tag...@gmail.com
> Location: sant Pere de Ribes, BCN, Spain
> PGP Key: 0x67123739
> PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739
> Key server: hkp://wwwkeys.eu.pgp.net



Re: sysupgrade failure logs

2021-02-15 Thread Theo de Raadt
Judah

> I did not and do not expect anyone else to solve my problem for me.

Your dishonesty is consistant.

We supply it all as software.  You can study it and find your problem.

Blaming me solves nothing.




Re: sysupgrade failure logs

2021-02-14 Thread Theo de Raadt
You are outside the box, by changing tons of stuff.

People who operate inside the box won't be able to help you.

And it is even less likely when you are dishonest in the original email.
You claimed your sysupgrade use was completely normal, but it isn't.

It is far from normal.

When we get reports like this where people "touch the insides", both
Florian and I regret that sysupgrade ever arrived in the system.

We want to delete sysupgrade.  Or, every month or so change the internals
so that it will delete some people's machines.

Does sysupgrade recommend what you do?  No.  But you do it.  Do you understand
the concept of "you own all the pieces"?



Re: sysupgrade failure logs

2021-02-14 Thread Theo de Raadt
You are using sysupgrade -n, and then modifying the payload?

Let's be serious about this:

I think everyone should stop helping you, you are on your own because
what you are showing now is completely different from your original
simple claim that "sysupgrade does not work".

Or you should pay someone for the trouble you are causing yourself.
I am not joking.


Judah Kocher  wrote:

> Thanks to each of you for your replies, Lesson 1: always get machines 
> with remote console access. It wil save the day some day and help in 
> diagnosing issues. Having remote console access would be sweet, but 
> unfortunately that goes far beyond the hobbyist price point I currently 
> have to work with. On the system that succeeded when you were watching 
> on the console, did automaic sysupgardes started to work after that? It 
> did not. This unit still fails the weekly upgrade. In general, my guess 
> would be a boot.conf contents that prevent the automatic upgrade to 
> work. Or maybe you have very old bootloaders on the failing mahcines. I 
> do not have an /etc/boot.conf file on any of these systems. Both the 
> units having issues are less than 12 months old so I wouldn't think the 
> bootloader age would be an issue. I have both older and newer units that 
> are working correctly. Are there major recent changes you are aware of 
> that might lead to something like this? BTW, kernel # cannot be used to 
> identify a kernel. Interesting. When I realized two of my machines were 
> still on old snapshots it seemed like a a simple metric to use for 
> tracking this. The actual number isn't really as relevant to me at this 
> point as the fact that it does or does not change. Could the update be 
> partially and/or completely succeeding and the kernel # staying the 
> same? In my limited experience following -current for the last 4+ years 
> every snapshot comes with a different #.  -Otto
> Care to show a script ? otherwise it looks like rather lengthy 
> mathematical problem with quite some variables.
>   The script is very basic. I didn't show it originally because I know 
> from reading various threads in the past that many of the folks on this list 
> find a "non-default" install abhorrent and I wasn't interested in dragging 
> that into this. However, here are the complete script contents:
> 
> #!/bin/sh
> 
> # Fetch current system version
> CURRENT=`uname -a | awk '{print $4}'`
> 
> # download latest snapshot but do not install
> doas sysupgrade -n -s
> 
> # Delete unwanted sets
> doas rm /home/_sysupgrade/x*
> doas rm /home/_sysupgrade/g*
> doas rm /home/_sysupgrade/c*
> 
> # Log System Time
> year=`date +%Y`
> month=`date +%m`
> day=`date +%d`
> hour=`date +%H`
> minute=`date +%M`
> second=`date +%S`
> 
> echo "System Snapshot upgrade started from $CURRENT at $hour:$minute:$second 
> on $month/$day/$year" >> /home/$USER/systemLog
> doas reboot
> 
> 
>   I have a separate script that runs on each boot which checks if an 
> upgrade attempt was the last logged item and fetches the current system 
> version to compare. If it is the same it logs a failure. If it is different 
> it logs the new version #. Either way it emails me the results. This script 
> is running on all 6 systems.
> .
> 
> 
> What are the permissions on the bsd.upgrade that's left behind? If they 
> are still +x then your issue is with the boot loader, maybe that 
> boot.conf otto suggested. If they are -x then the boot loader started 
> the install kernel but something went wrong. The permissions of the 
> left-behind bsd.upgrade are -rw--- 1 root
> 
> > On 14 February 2021 18:02:07 CET, Judah Kocher  wrote:
> >> Hello folks,
> >>
> >> I am having an issue with sysupgrade and I have had trouble finding the
> >>
> >> source of the problem so I hope someone here might be able and willing
> >> to point me in the right direction.
> >>
> >> I have 6 small systems running OpenBSD -current and I have a basic
> >> script which upgrades to the latest snapshot weekly. The systems are
> >> all
> >> relatively similar. Three are the exact same piece of hardware, two are
> >>
> >> slightly different, and one is a VM configured to match the first three
> >>
> >> as closely as possible with virtual hardware.
> >>
> >> The script checks the current kernel version, (e.g. "GENERIC.MP#302")
> >> logs it, runs sysupgrade, and after the reboot it checks the kernel
> >> version again. If it is different it logs it as a "success" and if it
> >> is
> >> still the same it logs it as a failure.
> >>
> >> All 6 systems were configured using the same autoinstall configuration
> >> and the upgrade script is identical on each unit. However, two of the
> >> three identical units always fail. When I remote into either system and
> >>
> >> manually run the upgrade script it also fails. I was able to get onsite
> >>
> >> with one of them where I connected a monitor and keyboard and manually
> >> ran the script to observe the results but oddly enough it succeeded so

Re: rdsetroot and gzip'd bsd.rd

2021-02-01 Thread Theo de Raadt
Should rdsetroot be able to edit gzip'd files?  I am not sure about
that.

BTW, at least one arch bsd.rd's has been gzip'd over the decades, so
this is simply an observation on a common architecture, it has been
with us forever.

Daniel Jakots  wrote:

> Hi,
> 
> Running -current amd64, I fetched a -current amd64 bsd.rd, then run
> $ rdsetroot -x bsd.rd ramdisk
> rdsetroot: bsd.rd: not an elf
> 
> I didn't expect that, so I run file on it which said
> bsd.rd: gzip compressed data, max compression, from Unix
> 
> I naively tried to gunzip it:
> $ mv bsd.rd bsd.rd.gz && gunzip bsd.rd.gz
> $ file bsd.rd
> bsd.rd: ELF 64-bit LSB executable, x86-64, version 1
> 
> so I ran rdsetroot again
> $ rdsetroot -x bsd.rd ramdisk
> rdsetroot: symbol table not found
> 
> 
> I guess it's because of
> https://github.com/openbsd/src/commit/aa6c3ec2488169493ed4877eea65efb00c967050
> 
> 
> Is it because now bsd.rd is stripped and rdsetroot needs to be updated
> to not expect a symbol table? Or am I missing something?
> 
> 
> Cheers,
> Daniel
> 



Re: Go language and pledge exec promises

2021-01-21 Thread Theo de Raadt
Kevin Chadwick  wrote:

> On 1/21/21 2:58 PM, Kevin Chadwick wrote:
> >>>840 beep CALL  pledge(0xcf4000,0xcae384)
> >>>840 beep STRU  promise="stdio rpath wpath cpath dpath tmppath inet 
> >>> mcast fattr chown flock unix d\
> >>>   ns getpw sendfd recvfd tape tty proc exec prot_exec settime ps vminfo 
> >>> id pf route wroute audio v\
> >>>   ideo bpf unveil error"
> >>>840 beep STRU  execpromise=""
> >>>840 beep RET   pledge 0
> >>>
> >> Whatever you are trying to do is ridiculous.
> > Absolutely. In fact the program itself is pointless to pledge, playing a 
> > beep to
> > the speaker. However, I had pledge disabled in my binaries due to the 
> > syscall 74
> > Go bug that was fixed. This is just testing with the most permissable 
> > settings.
> > Perhaps that in itself could cause an issue.
> 
> Is execpromise="" equivalent to passing null in c as a nil string in Go is
> initialised to "" (function sig = string)
> 
> Perhaps I should ktrace the whacky full promise passsed as execpromise too?

I wonder what happens if I point this thing at my foot.



Re: Go language and pledge exec promises

2021-01-21 Thread Theo de Raadt
Kevin Chadwick  wrote:

> On 1/21/21 2:54 PM, Theo de Raadt wrote:
> >>> Run your code under ktrace and see what is actually passed to pledge(),
> >>> that might give some clues.
> >>>
> >>>
> >>840 beep CALL  pledge(0xcf4000,0xcae384)
> >>840 beep STRU  promise="stdio rpath wpath cpath dpath tmppath inet 
> >> mcast fattr chown flock unix d\
> >>ns getpw sendfd recvfd tape tty proc exec prot_exec settime ps vminfo 
> >> id pf route wroute audio v\
> >>ideo bpf unveil error"
> >>840 beep STRU  execpromise=""
> >>840 beep RET   pledge 0
> >>
> > Whatever you are trying to do is ridiculous.
> 
> Absolutely. In fact the program itself is pointless to pledge, playing a beep 
> to
> the speaker. However, I had pledge disabled in my binaries due to the syscall 
> 74
> Go bug that was fixed.

> This is just testing with the most permissable settings.

That statement is wrong.  The most permissable setting is to not use
pledge, and use full POSIX.

pledge use should be based upon informed decisions after study of
everything a program needs to do, rather than slapping it in and then in
an uneducated fashion complaining about the result not meeting
expectations.

People using pledge in high-level language programs are making
uninformed decisions, since the high-level language environments perform
many complicated operations.

Your problem report is useless.  You don't supply source, you don't show
what is going on, yet you want hand-holding.  You don't trace what the
program or the heavy-environment is doing.

If you can't figure out pledge or how to ensure it is being used
correctly, then don't use pledge.



Re: Go language and pledge exec promises

2021-01-21 Thread Theo de Raadt
Kevin Chadwick  wrote:

> On 1/21/21 2:18 PM, Stuart Henderson wrote:
> > Run your code under ktrace and see what is actually passed to pledge(),
> > that might give some clues.
> > 
> > 
> 
>840 beep CALL  pledge(0xcf4000,0xcae384)
>840 beep STRU  promise="stdio rpath wpath cpath dpath tmppath inet 
> mcast fattr chown flock unix d\
>   ns getpw sendfd recvfd tape tty proc exec prot_exec settime ps vminfo 
> id pf route wroute audio v\
>   ideo bpf unveil error"
>840 beep STRU  execpromise=""
>840 beep RET   pledge 0
> 

Whatever you are trying to do is ridiculous.



Re: 4G mini PCI-e modem support?

2021-01-19 Thread Theo de Raadt
Peter Kay  wrote:

> On Fri, 8 Jan 2021 at 16:47, Stefan Sperling  wrote:
> >
> > On Fri, Jan 08, 2021 at 05:13:52PM +0100, Patrick Wildt wrote:
> 
> > > There's umb(4).  It supports USB's MBIM standard.  There are some MBIM
> > > compatible chips around, one for instance is this one:
> [..]
> > I have umb(4) working on an APU1 board. It's a Sierra Wireless EM7345, the 
> > one
> > shipped with x250 Thinkpads. Installation in an APU requires a compatible 
> > M.2
> > to miniPCIe adapter. Make sure to get an adapter with the correct M.2 
> > keying.
> > If the vendor advertises GSM/UMTS/LTE modem support the adapter should work.
> > If they don't, better ask before buying.
> >
> > This combo works fine in the middle miniPCIe slot of the APU. You'll need a
> > full size SIM card for the SIM card slot. Again, an adapter will help to fit
> > a micro or nano SIM.
> >
> > You will also want LTE antennas and compatible pigtails. Using wifi antennas
> > will result in about 50% packet loss.
> 
> Much obliged, I see some of those cards are quite cheap on ebay, and I
> don't need to have the absolute latest.
> 
> Now to find antennas and pigtails to link to the card

Be careful.

Cards listed with the right model could have older firmware which don't
suppor the MBIM protocol natively, but instead the older MSM protocol.
Or they have MBIM, but it is hidden from our driver.  Thus you end up with
umsm(4) support instead of umb(4).  With umsm(4) you need to do ppp yourself,
it is not a transparent network driver.



Re: -current amd64 packages not updated? Impatient or broken?

2021-01-07 Thread Theo de Raadt
Chris Cappuccio  wrote:

> Mihai Popescu [mih...@gmail.com] wrote:
> > I was in the same situation, impatient to have a 2021 snapshot.
> > 
> > Warning: I am not sure you will not finish with a Frankenstein system. I am
> > not so good with compiler-linker stuff.
> 
> For those trying to use the latest snap and the latest ports, try link
> libc++.so.4.0 to libc++.so.5.0 and libc++abi.so.2.1 to libc++abi.so.3.0
> for now. Frankenstein, indeed. You'll feel dirty just doing it.

DO NOT DO THAT.

We do not want reports from people about weird troubles, after they do
such things.



Re: msdos partition is too small in arm64/miniroot68.img

2021-01-07 Thread Theo de Raadt
tech-lists  wrote:

> On Thu, Jan 07, 2021 at 09:55:28AM -0700, Theo de Raadt wrote:
> >tech-lists  wrote:
> >
> >> On Wed, Jan 06, 2021 at 09:25:01AM -0700, Theo de Raadt wrote:
> >> >The miniroot is 33MB because it contains many install firmwares, and
> >> >it is 97% full.
> >> >
> >> >I suggest you find another way of installing.
> >> >
> >>
> >> Is there a technical (or some other reason I'm not seeing) why 
> >> miniroot68.fs
> >> has been made as small as it is, and not some other size like 48MB, which
> >> would allow the msdos partition to be made larger?
> >
> >Why 48MB?  Why not 2GB?  Why not make miniroot68.img be 2GB for download
> >to satisfy some bizzare usage pattern?
> >
> >All media are created to be small, no larger than they need to be.
> 
> OK I get it. The install requires an additional USB storage device. 
> 
> What I wanted to do was to write latest firmwares from
> https://github.com/pftf/RPi4 as described in
> OpenBSD/6.8/arm64/INSTALL.arm64
> into the (mdconfig-mounted) msdos partition of miniroot68.img prior to writing
> it to the sdcard, as I didn't have an additional USB storage device.

Modifying the miniroot is not a stock usage case.

I firmly believe that INSTALL.arm64 text *should not exist*.  Such
special cases increase the messiness of using OpenBSD.

> The latest firmwares (v1.22) unzip to 5.4MB but the msdos partition is only
> 4.0MB.

The firmware should be updated in the tree, and instructions encouraging
people to do weird stuff should not exist.

That is my take on this.



Re: msdos partition is too small in arm64/miniroot68.img

2021-01-07 Thread Theo de Raadt
tech-lists  wrote:

> On Wed, Jan 06, 2021 at 09:25:01AM -0700, Theo de Raadt wrote:
> >The miniroot is 33MB because it contains many install firmwares, and
> >it is 97% full.
> >
> >I suggest you find another way of installing.
> >
> 
> Is there a technical (or some other reason I'm not seeing) why miniroot68.fs
> has been made as small as it is, and not some other size like 48MB, which
> would allow the msdos partition to be made larger?

Why 48MB?  Why not 2GB?  Why not make miniroot68.img be 2GB for download
to satisfy some bizzare usage pattern?

All media are created to be small, no larger than they need to be.



Re: msdos partition is too small in arm64/miniroot68.img

2021-01-07 Thread Theo de Raadt
Christer Solskogen  wrote:

> On Wed, Jan 6, 2021 at 5:39 PM Theo de Raadt  wrote:
> 
>  The miniroot is 33MB because it contains many install firmwares, and
>  it is 97% full.
> 
> True, but the miniroot has space available to expand the msdos partition. 

The miniroot has two filesystems.

a is UFS and 97% full
i is msdos and 93% full.

We build all miniroots as small as possible.

Can this conversation backtrack please:  Explain why you think the
filesystems need to be larger.



Re: msdos partition is too small in arm64/miniroot68.img

2021-01-06 Thread Theo de Raadt
The miniroot is 33MB because it contains many install firmwares, and
it is 97% full.

I suggest you find another way of installing.

> I'm trying to install openbsd 6.8 on a raspberry pi 4/8GB. The files I
> need to add to the msdos partition are, in total, too
> large to fit (the partition is only 4MB)
> 
> Is there some method of increasing the msdos partition size
> of the miniroot.fs image? I'd be doing this from either a freebsd
> or linux desktop. On freebsd, I can virtualise the image with
> mdconfig. Or is there some other way round this, like re-writing the
> image.
> 
> thanks,
> -- 
> J.



Re: xterm dies

2020-12-27 Thread Theo de Raadt
Probably fixed by:

CVSROOT:/cvs
Module name:src
Changes by: v...@cvs.openbsd.org2020/12/23 06:53:45

Modified files:
sys/kern   : kern_event.c

Log message:
Clear error before each iteration in kqueue_scan()

This fixes a regression where kqueue_scan() may incorrectly return
EWOULDBLOCK after a timeout.

OK mpi@


Please don't use terminology like "a few days ago".   You can easily be
more precise.



Björn Gohla  wrote:

> Hi All,
> 
> Since updating to snapshot a few days ago I've been having problems with
> xterm randomly dying. I was able to capture this on another terminal:
> 
> 16:51:12 bgohla@titanic[1] ~ $ xterm: Error 50, errno 35: Resource
> temporarily unavailable
> Reason: in_put: select() failed
> 16:51:12 bgohla@titanic[1] ~ $ man select
> [1]+  Exit 50 xterm sh
> 17:54:42 bgohla@titanic ~ $
> 
> This is very annoying (I even had to start this email over because of
> it).
> 
> There don't seem to be any recent changes to xterm, so I'm out of
> ideas where to look for the source of the error.
> 
> Any ideas what one can do in this situation? Would another sysupgrade -s
> help?
> 
> Cheers,
> Björn
> 



Re: Enhancing Privacy in 2020 attached screenshot

2020-12-16 Thread Theo de Raadt
pipus  wrote:

> Stuart, one more thing, many of us have a question for you.
> Why does Theo, someone we have a huge amount of respect for, give you such 
> leeway in the forum?

Because he makes the world better.

On the other -- whoever you are -- you just smear shit over everything. 



Re: www.openbsd.org unreachable for a few days

2020-12-15 Thread Theo de Raadt
I've been told something was just fixed.

Now is a good time to retry.

Reply just to me, please.

ONLY people who observed the problems.


Ottavio Caruso  wrote:

> Hi,
> 
> I asked on Freenode#OpenBSD and apparently it's only me, but I haven't
> been able to access www.openbsd.org for a few days.
> 
> There is nothing in my firewall/router that blocks OpenBSD.org. Ping,
> traceroute and telnet don't seem to access the site. Can anybody help?
> Diagnostics follow.
> 
> $ telnet www.openbsd.org 443
> Trying 129.128.5.194...
> telnet: Unable to connect to remote host: Connection timed out
> 
> $ telnet www.openbsd.org 80
> Trying 129.128.5.194...
> telnet: Unable to connect to remote host: Connection timed out
> 
> $ host www.openbsd.org
> www.openbsd.org has address 129.128.5.194
> 
> $ ping 129.128.5.194
> PING 129.128.5.194 (129.128.5.194) 56(84) bytes of data.
> ^C
> --- 129.128.5.194 ping statistics ---
> 31 packets transmitted, 0 received, 100% packet loss, time 30696ms
> 
> $ traceroute 129.128.5.194
> traceroute to 129.128.5.194 (129.128.5.194), 30 hops max, 60 byte packets
>  1  gateway (192.168.2.1)  0.879 ms  1.433 ms  2.591 ms
>  2  192.168.1.254 (192.168.1.254)  3.400 ms  6.013 ms  11.119 ms
>  3  host81-139-176-1.in-addr.btopenworld.com (81.139.176.1)  23.841 ms
>  24.279 ms  24.892 ms
>  4  217.32.25.94 (217.32.25.94)  26.975 ms  32.948 ms  33.224 ms
>  5  217.32.25.120 (217.32.25.120)  34.331 ms  34.815 ms  35.379 ms
>  6  31.55.185.228 (31.55.185.228)  36.239 ms 31.55.185.192
> (31.55.185.192)  18.589 ms 31.55.185.208 (31.55.185.208)  23.081 ms
>  7  core1-hu0-16-0-6.colindale.ukcore.bt.net (213.121.192.16)  24.023
> ms core2-hu0-12-0-5.colindale.ukcore.bt.net (195.99.127.122)  24.013
> ms core1-hu0-16-0-7.colindale.ukcore.bt.net (213.121.192.18)  24.400
> ms
>  8  109.159.252.138 (109.159.252.138)  25.195 ms
> core2-hu0-1-0-1-1.colindale.ukcore.bt.net (195.99.127.9)  26.188 ms
> core3-hu0-8-0-0.faraday.ukcore.bt.net (195.99.127.36)  27.082 ms
>  9  62.6.201.145 (62.6.201.145)  27.534 ms 166-49-209-194.gia.bt.net
> (166.49.209.194)  28.250 ms 62.6.201.145 (62.6.201.145)  33.835 ms
> 10  166-49-209-194.gia.bt.net (166.49.209.194)  34.201 ms  34.174 ms  34.132 
> ms
> 11  40ge1-3.core1.lon2.he.net (195.66.224.21)  35.068 ms
> 100ge4-1.core1.nyc4.he.net (72.52.92.166)  101.075 ms  86.105 ms
> 12  100ge4-1.core1.nyc4.he.net (72.52.92.166)  85.940 ms  87.165 ms
> 100ge14-1.core1.tor1.he.net (184.105.80.10)  97.811 ms
> 13  100ge6-1.core1.ywg1.he.net (184.105.64.102)  122.819 ms
> 100ge14-1.core1.tor1.he.net (184.105.80.10)  98.632 ms  99.697 ms
> 14  100ge6-1.core1.ywg1.he.net (184.105.64.102)  124.813 ms
> 100ge5-2.core1.yxe1.he.net (184.104.192.70)  138.323 ms
> 100ge6-1.core1.ywg1.he.net (184.105.64.102)  134.804 ms
> 15  100ge5-2.core1.yxe1.he.net (184.104.192.70)  137.811 ms
> 100ge11-2.core1.yeg1.he.net (72.52.92.61)  164.945 ms  163.780 ms
> 16  * 100ge11-2.core1.yeg1.he.net (72.52.92.61)  164.850 ms *
> 17  * * *
> 18  * * *
> 19  * * *
> 20  * * *
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
> 28  * * *
> 29  * * *
> 
> 
> -- 
> Ottavio Caruso
> 



Re: www.openbsd.org unreachable for a few days

2020-12-15 Thread Theo de Raadt
Janne Johansson  wrote:

> Den tis 15 dec. 2020 kl 13:00 skrev Ottavio Caruso <
> ottavio2006-usenet2...@yahoo.com>:
> 
> > Hi,
> > I asked on Freenode#OpenBSD and apparently it's only me, but I haven't
> > been able to access www.openbsd.org for a few days.
> >
> > $ traceroute 129.128.5.194
> > traceroute to 129.128.5.194 (129.128.5.194), 30 hops max, 60 byte packets
> >
> >
> ...
> 
> 
> > 11  40ge1-3.core1.lon2.he.net (195.66.224.21)  35.068 ms
> > 100ge4-1.core1.nyc4.he.net (72.52.92.166)  101.075 ms  86.105 ms
> 
> 
> I heard a similar complaint elsewhere and that was going over he.net also,
> whereas I could reach it in the mean time, going over shawn to ualbert.ca
> and onwards, so I guess he.net is presently bad at routing to the correct
> places.

Sorry, you'd be incorrect blaming he.net.

UofA border is doing some kind of broken filtering, or perhaps it is
incorrect routing of replies into EDU network (cybera/canarie).

It is up to them to fix it, but there have been no replies yet.



Re: pflogd write /var/run/mypflogdinstance.pid?

2020-12-13 Thread Theo de Raadt
Harald Dunkel  wrote:

> On 12/13/20 7:10 PM, Theo de Raadt wrote:
> >
> > And I'm suggesting the arguments should look like this:
> >
> >  pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
> >  pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
> >
> > That might allow more accurate pkill targetting.
> >
> 
> Wouldn't you admit that this appears to be very fragile?

I already spoke to that earlier.

> My point is that a pid file on a volatile file system is much more
> reliable than pkill/pgrep. I am not asking you to drop pkill/pgrep,
> but I am missing the old -p option to pflogd.

If a pflogd dies because of a bug, the pid listed in the file may be
reused, and then your kill `cat pidfile` will kill the incorrect process.

You are wrong because pidfiles are NOT more reliable.


Where is your concrete reliable proposal??  I don't have one, and I admit
it.  You want to win points over which broken choice is better?



Re: pflogd write /var/run/mypflogdinstance.pid?

2020-12-13 Thread Theo de Raadt
Harald Dunkel  wrote:

> On 12/7/20 7:19 PM, Theo de Raadt wrote:
> > Yep.
> >
> > It is possible we need a better strategy --- like placing *all* original
> > argv in the [priv] title.
> >
> 
> If you change the pflogd command line in the process list, what is
> supposed to happen to the existing code using pkill or pgrep, expecting
> the *old* line?

I'm suggesting such people will just have to cope.

the current privsep looks like this:

pflogd: [priv] (pflogd)
pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)

And I'm suggesting the arguments should look like this:

pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)

That might allow more accurate pkill targetting.

I'm suggesting we consider the same for all privpse daemons which label
themselves "[priv]" right now.  It requires keeping argv constant,
and passing it down to the privsep startup code.




Re: Predict which changes will be in snapshot pulled by sysupgrade?

2020-12-09 Thread Theo de Raadt
James Cook  wrote:

> My question:
> 
> If I see a recent change in CVS, is there any way to know whether it
> will be included if I run sysupgrade right now?

No.



Re: RISC-V and OpenBSD

2020-12-09 Thread Theo de Raadt
Mihai Popescu  wrote:

> On Wed, Dec 9, 2020 at 7:57 PM Claudio Jeker 
> wrote:
> 
> > On Wed, Dec 09, 2020 at 05:30:48PM +0200, Mihai Popescu wrote:
> > > Would it be interesting from the OpenBSD point of view [1] ?
> > >
> > > [1] http://www.micromagic.com/news/RISCv-Fastest_PR.pdf
> >
> > No, this is just PR. We need HW to run on.
> >
> > --
> > :wq Claudio
> >
> 
> Of course. Some say Odroid is providing the board for the test [2]. Sounds
> interesting.
> 
> [2]
> https://www.eetimes.com/micro-magic-risc-v-core-claims-to-beat-apple-m1-and-arm-cortex-a9/

I'm not sure what your point is.

URLs and PDFs don't help the software development process.

PDF isn't turing complete, so you can't write a cpu emulator in it.

Press releases are not helpful.  Only hardware in-hand helps.



Re: pflogd write /var/run/mypflogdinstance.pid?

2020-12-07 Thread Theo de Raadt
Yep.

It is possible we need a better strategy --- like placing *all* original
argv in the [priv] title.

trondd  wrote:

> Stuart Henderson  wrote:
> 
> > On 2020-12-07, Harald Dunkel  wrote:
> > > About the PIDs: Maybe a systctl like
> > >
> > >   kernel.pid_max = 4194303
> > >
> > > known from other OSes could help to reduce the risk for PID conflicts.
> > 
> > This doesn't help if you actually want reliability, rather than just
> > "reliable most of the time".
> > 
> > There were also some concerns about what software would do with long
> > PIDs - even on a very basic level that adds another couple of columns
> > to top(1) output.
> > 
> > > If you store the PID files on a volatile file system, so you can be sure
> > > they are gone on the next reboot, anyway.
> > 
> > /var/run is cleared at boot anyway - the problem is pid reuse during
> > uptime of the system.
> > 
> > One can check that the new pid is owned by a process of the correct name
> > - but then the problem returns, the process name doesn't have enough
> > information to uniquely identify it. And if that is fixed there's no
> > need to save the pid.
> > 
> > So if there's a problem to be fixed, it is to get the information into
> > the other process string..
> 
> I think the user is looking for something like this.  Putting the interface
> name in the process title.
> 
> Mabe this doesn't work for this use case or there is some other fallout.
> And there may be other tweaks needed to support it, I don't have a dog in the
> fight to go find them, though.
> 
> Tim.
> 
> 
> Index: etc/rc.d/pflogd
> ===
> RCS file: /cvs/src/etc/rc.d/pflogd,v
> retrieving revision 1.3
> diff -u -p -r1.3 pflogd
> --- etc/rc.d/pflogd   11 Jan 2018 19:52:12 -  1.3
> +++ etc/rc.d/pflogd   7 Dec 2020 18:08:23 -
> @@ -6,7 +6,7 @@ daemon="/sbin/pflogd"
>  
>  . /etc/rc.d/rc.subr
>  
> -pexp="pflogd: \[priv\]"
> +pexp="pflogd: \[priv\].*"
>  
>  rc_pre() {
>   if pfctl -si | grep -q Enabled; then
> Index: sbin/pflogd/privsep.c
> ===
> RCS file: /cvs/src/sbin/pflogd/privsep.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 privsep.c
> --- sbin/pflogd/privsep.c 27 Nov 2019 17:49:09 -  1.34
> +++ sbin/pflogd/privsep.c 7 Dec 2020 18:08:45 -
> @@ -131,7 +131,7 @@ priv_init(int Pflag, int argc, char *arg
>   signal(SIGINT,  sig_pass_to_chld);
>   signal(SIGQUIT, sig_pass_to_chld);
>  
> - setproctitle("[priv]");
> + setproctitle("[priv] %s", interface);
>  
>   if (unveil(_PATH_RESCONF, "r") == -1)
>   err(1, "unveil");
> 



Re: pflogd write /var/run/mypflogdinstance.pid?

2020-12-07 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2020-12-07, Harald Dunkel  wrote:
> > About the PIDs: Maybe a systctl like
> >
> > kernel.pid_max = 4194303
> >
> > known from other OSes could help to reduce the risk for PID conflicts.
> 
> This doesn't help if you actually want reliability, rather than just
> "reliable most of the time".
> 
> There were also some concerns about what software would do with long
> PIDs - even on a very basic level that adds another couple of columns
> to top(1) output.

Yep.  Also expanding the pid range increases the cost of allocpid(), so
fork() becomes slower.

> > If you store the PID files on a volatile file system, so you can be sure
> > they are gone on the next reboot, anyway.
> 
> /var/run is cleared at boot anyway - the problem is pid reuse during
> uptime of the system.
> 
> One can check that the new pid is owned by a process of the correct name
> - but then the problem returns, the process name doesn't have enough
> information to uniquely identify it. And if that is fixed there's no
> need to save the pid.
> 
> So if there's a problem to be fixed, it is to get the information into
> the other process string..

It is worth considering what the 'lifetime' of a pid number.  It is a
unique number while the process is running.  After it runs, the number
is immediately available for reuse.  There is no lazy "don't use that number
yet, wait a while" scheme (adding such a scheme in OpenBSD would not solve
the general problem).



Re: pflogd write /var/run/mypflogdinstance.pid?

2020-12-06 Thread Theo de Raadt
Harald Dunkel  wrote:

> Hi folks,
> 
> I have to run several pflogd in parallel. To make pkill (i.e.
> newsyslog) work it seems to be necessary to create hard links
> pflogd1, pflogd2 etc., pointing to /sbin/pflogd. Soft links
> don't work, because they don't show up in the process table.
> This introduces new problems on the next upgrade of pflogd.
> Its unreliable and error-prone. (I lost 2 weeks of logfiles
> due to this.)
> 
> Would it be possible for pflogd to support a command line
> option -p /var/run/mypflogdinstance.pid, as common for other
> daemons? Without "-p" no pid file has to be written, as it is
> now.
> 
> I know this flag was present in ancient OpenBSD versions,
> but I never understood why such a reliable feature had
> been dropped in advance of the undependable pkill.

pid files don't really work any better than pkill, so we've removed
support all over the place.

pid files are a flawed mechanism.  Use of a stale pid file can impact
another process which has reused the pid, which is not that different
from pkill identifing the wrong program.  At least with pkill, you can
aim more carefully.

We've put some work into making programs not damage their argv.  If you
provide a strong set of arguments to the programs you start, you may be
able to pkill with a more fullsize pattern, increasing the accuracy.

It is all quite unsatisfying.  It would be better if a a parent
kept reference to the child, but that can also be unsatisfactory
when it creates too much process closeness.



Re: clock not set on boot

2020-12-05 Thread Theo de Raadt
Andy Goblins  wrote:

> Does ntpd need DNS to set the time? Because my reslov.conf points to
> 127.0.0.1 and unbound needs the time before it will work properly.

A problem of your own creation.



Re: clock not set on boot

2020-12-05 Thread Theo de Raadt
You have filtered ntpd so much that it can't do the job it wants to do.




Andy Goblins  wrote:

> > From: "Theo de Raadt" 
> >
> > ntpd is run by default, and magically will correct the time almost 
> > immediately.
> >
> > Some significant effort went into this a few years ago.
> >
> > However, the kernel message will always be there.  You can ignore it.
> >
> > Run ntpctl -s all, and you'll see the time has been corrected before
> > significant daemons start.
> 
> ntpd is running, but the clock isn't getting corrected before significant 
> daemons start. In fact, it's causing other daemons, like unbound, to fail.
> $ ntpctl -s all
> 5/5 peers valid, constraint offset 5355740s, clock unsynced, clock offset is 
> 5355739014.329ms
> ...
> 
> /var/messages:
> Oct  4 21:20:24 hostname ntpd[61157]: ntp engine ready
> Oct  4 21:20:25 hostname ntpd[61157]: constraint reply from 9.9.9.9: offset 
> 5355740.057722
> Oct  4 21:20:26 hostname unbound: [98456:0] notice: init module 0: validator
> Oct  4 21:20:26 hostname unbound: [98456:0] notice: init module 1: iterator
> Oct  4 21:20:26 hostname unbound: [98456:0] info: start of service (unbound 
> 1.11.0).
> Oct  4 21:20:27 hostname ntpd[61157]: cancel settime because dns probe failed
> Oct  4 21:20:27 hostname unbound: [25295:1] info: failed to prime trust 
> anchor -- DNSKEY rrset is not secure . DNSKEY IN
> ...
> 
> Does ntpd need DNS to set the time? Because my reslov.conf points to 
> 127.0.0.1 and unbound needs the time before it will work properly.



Re: clock not set on boot

2020-12-05 Thread Theo de Raadt
andygoblins  wrote:

> Ever since updating to 6.8, I've had trouble with the system clock not 
> getting set on boot.
> 
> I know the easy answer is to script a call to rdate, but that feels like a 
> bandaid solution.
> 
> I'm running from an EdgeRouter Lite (octeon) that afaik does not have a 
> persistent clock. Before 6.8, I always saw boot messages about how the kernel 
> was going to set the clock based on the filesystem. I don't see those 
> messages anymore, and instead see an ominous "WARNING: CHECK AND RESET THE 
> DATE!"
> 
> I assume there's been some changes into how dates and time are handled, but I 
> haven't seen anything in the release notes.
> 
> Can anyone point me in the right direction, or have a better bandaid idea 
> than calling rdate?

ntpd is run by default, and magically will correct the time almost immediately.

Some significant effort went into this a few years ago.

However, the kernel message will always be there.  You can ignore it.

Run ntpctl -s all, and you'll see the time has been corrected before
significant daemons start.




Re: Installer suggestion

2020-12-01 Thread Theo de Raadt
Christer Solskogen  wrote:

> On Tue, Dec 1, 2020 at 4:43 PM Christopher Turkel <
> turkel.christop...@gmail.com> wrote:
> 
> > Why would you want that? I’m curious.
> 
> 
> Just to place it together with the rest of the questions.  Bulk them
> together so to speak.
> Now the installation waits for input about the timezone, before it
> continues with relinking the kernel and fills /dev etc.
> 
> But it doesn't matter. Theo just explained why.

There have also been proposals that IF we the files are present in the
ramdisk, we use them. But then the questions are not in the same order
for all install methods.  Another proposal was for upgrades if the files
exist in the base, we use those.  But sometimes new files show up, or old
files go away.  So again, the order of the questions could vary depending
on install or upgrade method.  That feels like too much of a surprise,
so I have no intention of changing it.



Re: Installer suggestion

2020-12-01 Thread Theo de Raadt
Christer Solskogen  wrote:

> Would it make sense to move the timezone question to before the fetching
> and extraction of the install sets starts?

No, because the timezone files are in the sets, because they don't fit on
all the media.



Re: Supported PCI USB 3 cards

2020-11-27 Thread Theo de Raadt
Nils Blomqvist  wrote:

> I need a PCI card with USB 3 ports. Something like this is what I
> had in mind: https://amzn.to/2V8NgtT (SEDNA - PCI Express USB 3.1).
> 
> Can anyone point me in the right direction for finding out if a
> particular card is supported, or a list of supported ones?

All PCI USB cards should work fine.



Re: httpd on 6.8

2020-11-27 Thread Theo de Raadt
There is nothing in the manual page which suggests you can put
newlines in those positions.


Duncan Patton a Campbell  wrote:

> 
> 
> If I have a config file that looks like this
> 
> chroot "/var/www"
> 
> # $OpenBSD: httpd.conf,v 1.20 2018/06/13 15:08:24 reyk Exp $
> 
> server "default"  
> {
> listen on * tls port 443
> tls  
> {
> certificate 
> "/etc/letsencrypt/live/babayaga.neotext.ca/fullchain.pem"
> key "/etc/letsencrypt/live/babayaga.neotext.ca/privkey.pem"
> }
> location "/*"  
> {
> root "/htdocs"
> }
> }
> 
> types  
> {
> include "/usr/share/misc/mime.types"
> }
> 
> I get errors as follows:
> 
>  /usr/sbin/httpd -d 
> startup
> /etc/httpd.conf:18: syntax error
> /etc/httpd.conf:32: syntax error
> /usr/share/misc/mime.types:3: syntax error
> /usr/share/misc/mime.types:62: syntax error
> /usr/share/misc/mime.types:69: syntax error
> /usr/share/misc/mime.types:80: syntax error
> /usr/share/misc/mime.types:89: syntax error
> /etc/httpd.conf:35: syntax error
> no actions, nothing to do
> logger exiting, pid 19104
> server exiting, pid 99393
> server exiting, pid 30412
> server exiting, pid 68022
> 
> but using the SAME CONFIG layed out differently
> # Servers
> #
> 
> chroot "/var/www"
> 
> # $OpenBSD: httpd.conf,v 1.20 2018/06/13 15:08:24 reyk Exp $
> 
> server "default" {
> listen on * tls port 443
> tls {
> certificate 
> "/etc/letsencrypt/live/babayaga.neotext.ca/fullchain.pem"
> key "/etc/letsencrypt/live/babayaga.neotext.ca/privkey.pem"
> }
> location "/*" {
> root "/htdocs"
> }
> }
> 
> types {
> include "/usr/share/misc/mime.types"
> }
> 
> gets no errors:
> 
> babayaga:/etc# /usr/sbin/httpd -d 
> startup
> 
> If anyone has some idea about the syntax of this setup I'd really like to 
> hear from yous ;^)
> 
> Thanks,
> 
> Dhu
> 
>  -- 
>  Je suis Canadien. Ce n'est pas Francais ou Anglaise.  
>   C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-) 
> 



Re: Failed sysupgrade from 6.6 to 6.7 amd64

2020-11-15 Thread Theo de Raadt
Maxim Khitrov  wrote:

> After all these years of trouble-free upgrades, I ran into my first
> problem. I used sysupgrade to go from 6.6/amd64 to 6.7. The upgrade
> process was successful, but after bsd.upgrade did its thing and
> rebooted the system, the new kernel would not boot.
> 
> It got to the "boot>" prompt, started loading the kernel, but then the
> system would reboot right after showing "booting hd0a:bsd:
> 12957+2753552..." line. I tried booting bsd.sp, bsd.rd, and
> bsd.booted with identical results. Was able to boot from cd67.iso.
> Tried downloading the original kernel, but that didn't work either.
> Re-running the upgrade didn't help.

This seems to be the efi issue.

> Finally, decided to upgrade to 6.8, so did that from cd68.iso, which
> fixed the problem. I also replaced bootx64.efi file on the EFI
> partition after this upgrade, but I'm not actually sure if it was
> different or not.

But the issue was also in 6.8.

It is fixed in current.

> Obviously curious as to what the issue may have been, but mostly
> wondering whether any upgrade steps may have been missed as a result
> of never fully booting the 6.7 OS and running post-upgrade steps
> there.

We don't know.  At this point, no developers have machines sensitive
to the issue.



Re: System auditing and logging

2020-11-13 Thread Theo de Raadt
So you want to ktrace your entire system, with a limited set of
monitors.

I've played with this before, to identify specific behaviours
when developing pledge.  It required a large number of hacks,
and the performance was dismal.

Based upon my experience, I predict it will not work for your usage
case at all.



James  wrote:

> Thanks. I have enabled system accounting.
> 
> acct(5) seems to be limited by the fact that it is triggered on process
> exit, doesn't contain the process ID or parent process ID and can only
> store 10 characters for the command name.
> 
> ktrace could work but it's far too slow without limiting syscalls
> recorded to a specific subset.
> 
> Is there any interest in modifying ktrace to allow for specifying
> individual names of syscalls to trace?
> 
> e.g. ktrace -t c -u execve,sendmsg
> 
> On Fri, Nov 13, 2020 at 07:57:54AM -0700, Theo de Raadt wrote:
> >man accton
> >
> >James  wrote:
> >
> >> Recently a machine running OpenBSD 6.8 had its configuration changed and I
> >> believe it to have been subject to a malicious attack.
> >>
> >> This change is completely unexplainable, compromised security, and would
> >> have required root access.
> >>
> >> The log files reveal nothing out of the ordinary except for wtmp
> >> indicating 0 users are logged in:
> >>
> >> -bash-5.0# who
> >> -bash-5.0# w
> >>  1:49PM  up  2:21, 0 users, load averages: 1.35, 1.38, 1.50
> >> USERTTY FROM  LOGIN@  IDLE WHAT
> >> -bash-5.0#
> >>
> >>
> >> I would like to be able to log every exec syscall with the details of the
> >> current timestamp, calling PID, program path, arguments, and new PID.
> >>
> >> Ideally this would be implemented in the kernel. Are there any
> >> existing solutions?
> >>
> >> Thanks,
> >>
> >



Re: System auditing and logging

2020-11-13 Thread Theo de Raadt
man accton

James  wrote:

> Recently a machine running OpenBSD 6.8 had its configuration changed and I
> believe it to have been subject to a malicious attack.
> 
> This change is completely unexplainable, compromised security, and would
> have required root access. 
> 
> The log files reveal nothing out of the ordinary except for wtmp
> indicating 0 users are logged in:
> 
> -bash-5.0# who
> -bash-5.0# w
>  1:49PM  up  2:21, 0 users, load averages: 1.35, 1.38, 1.50
> USERTTY FROM  LOGIN@  IDLE WHAT
> -bash-5.0#
> 
> 
> I would like to be able to log every exec syscall with the details of the
> current timestamp, calling PID, program path, arguments, and new PID.
> 
> Ideally this would be implemented in the kernel. Are there any
> existing solutions?
> 
> Thanks,
> 



Re: question about hostname.carp

2020-11-04 Thread Theo de Raadt
hostname.if parsing does not translate 100% to an ifconfig command line.


> short question about hostname.carp1: Is it
> 
>   inet 10.0.1.1 0xff00 NONE vhid 41 pass secret carpdev em1 advbase 1 
> advskew 0
> or
>   inet 10.0.1.1 0xff00 vhid 41 pass secret carpdev em1 advbase 1 
> advskew 0
> 
> ?
> 
> Using ifconfig I get
> 
>   % ifconfig carp1 -inet
>   % ifconfig carp1 inet 10.0.1.1 0xff00 NONE vhid 41 pass secret 
> carpdev em1 advbase 1 advskew 0
>   ifconfig: NONE: bad value
> 
> but if I omit the NONE in hostname.carp1, then its not accepted at boot
> time, either ("status: invalid"). And worst of all, for carp2 it is the
> other way.
> 
> 
> Maybe I am too blind to see, but every insightful comment is highly
> appreciated.
> 
> Harri
> 



Re: Impact of 002_icmp6.patch

2020-10-29 Thread Theo de Raadt
js-openbsd-m...@webkeks.org wrote:

> I just saw
> https://ftp.openbsd.org/pub/OpenBSD/patches/6.8/common/002_icmp6.patch.sig,
> however, it's unclear from the description and the context around the
> patch if this is a read after free or write after free (or both).

I think it is fair you can study the code yourself and make your own
factual determination.

> In the case of a write after free, would this change "Only two remote
> holes in the default install, in a heck of a long time!" to three? Or
> does it need more than IPv6 being configured?

First off, is ipv6 deployment really part of the default install?  No,
not really it takes some effort to configure v6, it is not natural.  It
is active on the loopback, but then that's not remote..

But there's a bigger assumption in your mail:

We've released the errata as security because it is possibly exploitable
or could cause a crash, and we have a rapid fix release process.  It was
released without even seeing any evidence of a remote crash, nor any
evidence of a remote exploit.  Incorrect code gets fixed, and if we
judge it important we release a fix to the public in expedited fashion,
and apparently get judged for doing so.

Now that the fix is released and deployed by most openbsd users, we
quickly become uncurious and head back to other work.  The only
conversations related to this are asking how we can harden the mbuf
layer to avoid similar issues in the future.

I guess many other operating systems would wait weeks or months to
collect all the "facts" and make a fancy disclosure, but we shipped
source and binary fixes in just over 24 hours.

So, is it a remote crash?  Possibly, but we'd like to see a packet
that causes it.

Next after that, is it a remote exploit?

I think it is fair to wait for facts.

I also think you are a troll.




Re: wg(4) listen on a specific interface / address

2020-10-29 Thread Theo de Raadt
Pierre Emeriaud  wrote:

> Totally agreed. This is because of my stupid idea to share port 53 for
> this use. Maybe my understanding of sockets was wrong, but I thought
> that applications could use the bind port _if and only_ they weren't
> trying to bind the same IP+port, hence my question about this
> conflict, which could happen with other ports as well.

Such a weird perspective.  I guess you've never setup a multhomed
machine.  INADDR_ANY means all interfaces, so a daemon doesn't need
to open a new socket on each interfaces, and listen to the route socket
for new interfaces to arrive, or old ones to be disconnected.

> Thanks everyone who answered, and if anyone has the definitive answer
> about why it wg binds INADDR_ANY, I'd be interested to know.

Why does sshd bind to INADDR_ANY?  Why does httpd bind to INADDR_ANY?
The same reason for wg.  It wants to respond to requests on all interfaces.
And the loopback is not exempt.




Re: wg(4) listen on a specific interface / address

2020-10-29 Thread Theo de Raadt
Pierre Emeriaud  wrote:

> Le jeu. 29 oct. 2020 à 18:00, Brian Brombacher  a écrit 
> :
> >
> >
> > Then there’s a misconfiguration, wg driver bug, or the driver documentation 
> > is wrong in ifconfig about wgrtable.
> >
> > Routing domains are where you can specify multiple conflicting port binds 
> > and be fine, INADDR_ANY included.
> 
> On that matter there are no issues, only me/my setup. wg has no issues
> with binding INADDR_ANY if it is the only software binding on port 53
> _in that rdomain_. The issue I have is when I already have another
> software, like a dns resolver here already listening on 127.0.0.1 in
> that same rdomain.

port 53 has a well known use.  It is the firstcomer, for a critical service.

You are abusing that port.

I could easily argue there is nothing to fix in our kernel.



Re: wg(4) listen on a specific interface / address

2020-10-29 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2020-10-29, Pierre Emeriaud  wrote:
> > Le jeu. 29 oct. 2020 à 01:20, Theo de Raadt  a écrit :
> >>
> >> I believe you are running into the restriction that we don't allow an
> >> INADDR_ANY:port binding to be done after a ipaddr:port binding has been
> >> done.  It must be done beforehands.
> >
> > Sorry Theo, maybe things got lost in translation, but if my
> > understanding is correct this is not exactly the case here. wg is
> > trying to bind to INADDR_ANY, which fails because a dns daemon (in my
> > case) is already bound to 127.0.0.1:53 (in wg_socket_open() -L700 of
> > if_wg.c-, sin->sin_addr.s_addr = INADDR_ANY?).
> 
> There are extra restrictions, to prevent some software "stealing" packets
> intended for some other software. In userland software that wants to coexist
> with other software on the same pprt hut a different bound IP needs to use
> SO_REUSEADDR (I forgot exactly how the restriction work though). The problem
> you are seeing might be related to this.
> 
> Which DNS server do you have bound on 53?
> 
> > Is there a reason why wg needs such a large bind?
> 
> Unless/until it gets an option to bind to a specific IP that's all it
> can sanely do. It would definitely be useful IMO.

Or, configure it before the application software.

Or, don't try to overlay stuff onto a single port.  Look, we can tell
what is going on here, you want to tunnel over the least-filtered port
on the internet, but if you do that trying to use that port for another
thing is quite a problem of your own making.



Re: disk setup question

2020-10-29 Thread Theo de Raadt
Aleksander De  wrote:

> Are there any downsides or potential issues which may happen when
> extending boundaries for OpenBSD partition on >2TB disk while using
> MBR for booting it at the same time? I need MBR otherwise the machine
> will not boot. BIOS/RAID controller does not support UEFI.

The BIOS will use the MBR to identify the bootable partition.  Then
it will load the PBR sector as code, jump to it, and then load further
bootblock code, and kernel after that.  It is important to not have the
root partition in an earlier part of the disk (I'm being intentionally
vague).

But our bootcode does not care about the partition limits.  What happens
is disklabel looks at the MBR partition limits -- when non-MBR
partitions (ie disklabel partitions) are being created, usually during
install.  Beyond that, the MBR size is never looked at again.

Where MBR partition limits can matter, is if you go back to disklabel
again manually to create partitions.  It's splitting the disk up.  If
you are not careful, you could create overlaps.  This mostly happens to
people putting multiple operating systems on a machine.  Those people
need to be careful.  Everyone else can ignore this.



Re: suggestion for the installer

2020-10-29 Thread Theo de Raadt
Nick Holland  wrote:

> On 2020-10-29 08:00, Harald Dunkel wrote:
> > Hi folks,
> > 
> > do you think it would be possible for the installer to show
> > an eye-catching warning, if "ifconfig" reports "no carrier"
> > for the network port to configure?
> > 
> > Just a suggestion, of course
> > Harri
> 
> Why?
> What problem are you trying to solve, and how many are you
> planning on making for me in the process?
> 
> I often end up setting up OpenBSD systems with no network
> attached.  Nothing to warn me about.
> 
> I very often install OpenBSD configuring several NICs when
> only one has a network currently.  Again, PLEASE don't give
> me three, five or ten bogus warning messages.

Precisely.  vertical screen real-estate is valuable.  People
often look up higher at what they've already done, and a warning
would consume 1 line per interface, and reduce the visible context
for a person performing an multi-network install manually, thereby
increasing potential error.



Re: wg(4) listen on a specific interface / address

2020-10-29 Thread Theo de Raadt
Pierre Emeriaud  wrote:

> Le jeu. 29 oct. 2020 à 01:20, Theo de Raadt  a écrit :
> >
> > I believe you are running into the restriction that we don't allow an
> > INADDR_ANY:port binding to be done after a ipaddr:port binding has been
> > done.  It must be done beforehands.
> 
> Sorry Theo, maybe things got lost in translation, but if my
> understanding is correct this is not exactly the case here. wg is
> trying to bind to INADDR_ANY, which fails because a dns daemon (in my
> case) is already bound to 127.0.0.1:53 (in wg_socket_open() -L700 of
> if_wg.c-, sin->sin_addr.s_addr = INADDR_ANY?).
> 
> Is there a reason why wg needs such a large bind?

I don't know why wg does that, because I haven't looked at the code.
Your configuration is definately pushing the limits.



Re: wg(4) listen on a specific interface / address

2020-10-28 Thread Theo de Raadt
Pierre Emeriaud  wrote:

> Le mar. 27 oct. 2020 à 23:46, j...@snoopy.net.nz  a écrit 
> :
> >
> >
> >
> > Hi Pierre,
> >
> > The error may indicate that port 53 on 127.0.0.1 is already used by another 
> > service. This appears to be confirmed by your netstat example. This is 
> > probably a dns service.
> 
> Thanks Joe. This is indeed a dns daemon, several in fact. But nothing
> should prevent wireguard from using port 53 on any other IP address
> than 127.0.0.1 here. (well, nothing but the code that has been
> implemented)

I believe you are running into the restriction that we don't allow an
INADDR_ANY:port binding to be done after a ipaddr:port binding has been
done.  It must be done beforehands.



Re: Internal microphone not working

2020-10-28 Thread Theo de Raadt
Ashton Fagg  wrote:

> I've translated that since I'm not sure those among us speak rude,
> codescending clown.

And now far fewer people want to help you.   Such a winner...



Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)

2020-10-28 Thread Theo de Raadt
This particular diff is in snapshots.  That's a shortcut which will let
more people try it quicker, and report back.

> thanks to the fix from Mark, see 
> https://marc.info/?l=openbsd-tech=160383074317608=2 the problem is 
> solved for my machine.
> 
> Best regards,
> Sven
> 
> On 10/10/20 11:56 AM, Sven Wolf wrote:
> > Hi,
> > 
> > on my Lenovo V130 I've to build a custom kernel without radeondrm and 
> > amdgpu.
> > 
> > https://marc.info/?l=openbsd-misc=159276382718317=2
> > 
> > The modified efiboot.c, see 
> > https://marc.info/?l=openbsd-misc=159401011632149=2, doesnt work on 
> > this machine.
> > 
> > Best regards,
> > Sven
> > 
> > On 10/9/20 9:32 PM, Kastus Shchuka wrote:
> >> On Fri, Oct 09, 2020 at 03:37:37PM +0400, Michel von Behr wrote:
> >>> Hi all,
> >>> I'm trying to run snapshot on a Chuwi Lapbook laptop (Intel Gemini 
> >>> Lake),
> >>> but I get stuck at boot time with the message "entry point at: 
> >>> 0x1001000".
> >>> Based on previous discussions [1] it looks like the problem is with
> >>> BOOTX64.EFI
> >>> For now I'll be running -stable, but I would like to follow -current. Is
> >>> there a way to run -current with an old version of BOOTX64.EFI for 
> >>> example?
> >>> (i.e., the only alternatives I'm seeing is either 1) compiling a GENERIC
> >>> kernel with the older version of BOOTX64.EFI src, or 2) (try to) 
> >>> compile a
> >>> custom/smaller kernel to avoid the issue).
> >>>
> >>> [1] https://marc.info/?l=openbsd-misc=159147446008114=2
> >>>
> >>> Any pointing to the right direction is welcome.
> >>
> >> I had the same problem with EFI on ASRock J4105M system, essentially 
> >> failing
> >> to boot a kernel larger than certain size. I posted my solution here:
> >>
> >> https://marc.info/?l=openbsd-misc=159401011632149=2
> >>
> >> I guess the patch requires more testing before asking for it to be
> >> committed.
> >>
> >> Thanks,
> >>
> >> Kastus
> >>
> 



Re: OpenBSD UEFI on QEMU emulator

2020-10-26 Thread Theo de Raadt
Kevin Shell  wrote:

> On Mon, Oct 26, 2020 at 08:46:55AM -0600, Theo de Raadt wrote:
> >
> > There are two versions of this code, for the small and large install media.
> >
> > /usr/src/distrib/amd64/ramdisk_cd
> >
> > /usr/src/distrib/amd64/iso
> >
> > Someone who wants this should do it.
> >
> I see the Makefile uses the GNU tool mkhybrid,
> which does not support multiple el torito boot images,
> why not use the BSD makefs that is in OpenBSD tree to create the iso file,
> it supports multiple el torito boot images for both BIOS and UEFI,
> FreeBSD does it this way.

you are invited to make a diff, and then test your output file to ensure
no regressions on a wide variety of machines.




Re: OpenBSD UEFI on QEMU emulator

2020-10-26 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2020-10-24, Kevin Shell  wrote:
> > The OpenBSD .iso image file is not
> > hybrid image(both BIOS/UEFI iso9660 and USB boot drive support),
> > Linux, FreeBSD, NetBSD all produce hybrid iso images,
> 
> OpenBSD produces a separate .img file, just choose the iso if you want an
> iso, choose img if you want an image for a USB boot drive.
> 
> Are you sure about NetBSD? I didn't check their ISO but they do provide
> separate img files and there's no indication in the install guide that it
> is hybrid. http://www.netbsd.org/docs/guide/en/chap-inst.html
> 
> (Also, despite their hybrid iso, FreeBSD still sees the need to provide
> a separate USB image).
> 
> > I want to know why OpenBSD not do the same. :-)
> 
> I guess nobody has seen enough benefit to changing things for it to be
> worth spending the time A) implementing it (without using GPL tools)
> and B) testing it on a wide variety of machines to make sure it doesn't
> break something that currently works.
> 
> B is the real problem of course.

There are two versions of this code, for the small and large install media.

/usr/src/distrib/amd64/ramdisk_cd

/usr/src/distrib/amd64/iso

Someone who wants this should do it.



Re: man netstart(8) OpenBSD-6.8

2020-10-25 Thread Theo de Raadt
Jason McIntyre  wrote:

> On Sun, Oct 25, 2020 at 10:16:54AM -0600, Theo de Raadt wrote:
> > Jason McIntyre  wrote:
> > 
> > > whereas /etc/netstart is actually doing:
> > > 
> > > - configure non-physical:   (1)
> > > aggr trunk svlan vlan carp pppoe
> > > - routing   (2)
> > > - rest of non-physical: (3)
> > > tun tap gif etherip gre egre mobileip pflow wg
> > > 
> > > we could try to keep this list up to date, but it may be easier to just
> > > generally describe what netstart is doing.
> > 
> > I think we goes wrong by trying to maintain these as lists, and part of
> > where this goes wrong is weak definition of the reasons for the
> > ordering.  (Meaning, the developers who tweak netstart to handle the
> > concerns I'm about to describe, don't tend to think about the manual
> > page).
> > 
> > The (1) list of non-physical can probably be called "link-layer control
> > interfaces".  Or let's find a name for this.  These devices mutate the
> > presentation of other devices.  That's why their configuration needs to
> > be done before the physical device.
> > 
> > (2) The physical device is then brought up, including IP addressing. The
> > things in (1) need to be done beforehands, or the physical device is
> > participating in the wrong layer of network.
> > 
> > the (3) list of non-physical devices are layer-2 or layer-3 and operate
> > on devices which are already configured with some some sort of
> > "addressing" configured.
> > 
> > It would be nice to have our networking people come up with nice names
> > for group (1) and (2); words which succinctly describe the
> > classification like I've done above.  We need to increase understanding
> > of this order, rather than just abstractly listing names of devices with
> > complicated behaviours.
> > 
> > Once that is done, I still think it is problematic for us to list all
> > devices in each catagory:
> > 
> > a) new subsystems will be forgotten
> > b) the order of instantiation will sometimes be listed wrong -- for some
> >of these the order is highly significant.
> > 
> > We can try to list as many as possible, but people who want the precise
> > list (and order) should look in the netstart code.  The lists will get
> > long and wrong.  If we find we cannot maintain the lists correctly
> > because it is duplicated information, man page wording like "such as"
> > could be used, also something which leads people to consider the script
> > source as authoritative, ie. have them go read the script 
> > 
> 
> ok, here is a start.
> 
> i have left the description as "non-physical", because i think that is
> clear. we could easily amend it. ifconfig.8 create talks about "network
> pseudo-devices" - that could be a possibility.

You've deleted all the interface names, so now there are no examples.
I disagree strongly.   That creates a hurdle and people won't learn how
our network pieces are configured into a multi-layer stack.




Re: man netstart(8) OpenBSD-6.8

2020-10-25 Thread Theo de Raadt
Jason McIntyre  wrote:

> whereas /etc/netstart is actually doing:
> 
> - configure non-physical:   (1)
> aggr trunk svlan vlan carp pppoe
> - routing   (2)
> - rest of non-physical: (3)
> tun tap gif etherip gre egre mobileip pflow wg
> 
> we could try to keep this list up to date, but it may be easier to just
> generally describe what netstart is doing.

I think we goes wrong by trying to maintain these as lists, and part of
where this goes wrong is weak definition of the reasons for the
ordering.  (Meaning, the developers who tweak netstart to handle the
concerns I'm about to describe, don't tend to think about the manual
page).

The (1) list of non-physical can probably be called "link-layer control
interfaces".  Or let's find a name for this.  These devices mutate the
presentation of other devices.  That's why their configuration needs to
be done before the physical device.

(2) The physical device is then brought up, including IP addressing. The
things in (1) need to be done beforehands, or the physical device is
participating in the wrong layer of network.

the (3) list of non-physical devices are layer-2 or layer-3 and operate
on devices which are already configured with some some sort of
"addressing" configured.

It would be nice to have our networking people come up with nice names
for group (1) and (2); words which succinctly describe the
classification like I've done above.  We need to increase understanding
of this order, rather than just abstractly listing names of devices with
complicated behaviours.

Once that is done, I still think it is problematic for us to list all
devices in each catagory:

a) new subsystems will be forgotten
b) the order of instantiation will sometimes be listed wrong -- for some
   of these the order is highly significant.

We can try to list as many as possible, but people who want the precise
list (and order) should look in the netstart code.  The lists will get
long and wrong.  If we find we cannot maintain the lists correctly
because it is duplicated information, man page wording like "such as"
could be used, also something which leads people to consider the script
source as authoritative, ie. have them go read the script 



Re: man netstart(8) OpenBSD-6.8

2020-10-24 Thread Theo de Raadt
Rachel Roch  wrote:

> Is it just me or is the man entry for netstart(8) missing a reference to 
> wg(4) ?

... and 300 other network interfaces.

In otherwords, no, it should not be there.



Re: sysupgrade --download ?

2020-10-23 Thread Theo de Raadt
Harald Dunkel  wrote:

> I stumbled over a bad mirror for sysupgrade.
> 
> Would it be possibe to add an option "-d" to sysupgrade, to just
> download and verify the required files?

  sysupgrade -n

> A subsequent call without
> "-d" should verify the signatures in the download directory again
> and proceed.

  sysupgrade


It already exists.



Re: ssl/libssl certificate validation broken?

2020-10-22 Thread Theo de Raadt
Daniel Jakots  wrote:

> On Thu, 22 Oct 2020 21:49:20 -0500, "Rafael Possamai"
>  wrote:
> 
> > >Hi Bob, it was in the middle of the night and I got quite kinda
> > >stressed because all services depending on our ldap proxy stopped
> > >working after the upgrade and it took me a while to figure the
> > >problem out.  
> > 
> > Perhaps this is unsolicited advice, but maybe you can setup a test
> > system first, perform major upgrade on it to make sure everything
> > works. If so, then do it in production. 
> > 
> 
> Even better, try -current a few weeks before release (a possible hint
> is -beta). This way you can get any encountered bug fixed in time for
> -release. Your prod but also every one else will benefit from it.

It's very good advice.  I can't speak for Bob, but I've been unable
to sleep during this outage.



Re: Multiple USB NICs

2020-10-20 Thread Theo de Raadt
Stuart Longland  wrote:

> On 21/10/20 9:55 am, Lee Nelson wrote:
> >> Alternatively use a single nic with vlans, and break out to separate
> >> ports on a managed switch.
> >>
> > Yes, that could work too, but this is one side of a pfsync/carp
> > redundant firewall setup, so I want to keep it as simple as possible.
> 
> Silly question, what hardware are the USB NICs plugging into?
> 
> USB trades off determinism for hot-pluggability, and it seems a
> firewall, you absolutely do want an interface to appear in a specific
> location.  I'd be looking at something that plugs into the system
> peripheral bus somehow (PCIe, PCI, ISA, … etc).

Oh come on, you know the answer before you ask it.

Using cheap hardware and expecting free software developers to
pull magic out of their ass to make it solve unsolveable problems, and
produce a result as too as state of the art expensive hardware --- or
even cheaper hardware --- with DEDICATED PORTS -- it is madness.  We
can't do it.  And we said so.

And Lee gets it.  But do the rest of the thread participants?

I think it's fine for us as a community to humour the attempt for a bit,
but THEN THE DISCUSSION MIGHT AS WELL END, as the consequences of the
choice ARE WHAT THEY ARE.

You get what you paid for.  And we (OpenBSD) played no part in the
decision or the consequences, hotplug is what it is.

Can we end this discussion?




Re: Multiple USB NICs

2020-10-19 Thread Theo de Raadt
Lee Nelson  wrote:

> If I have multiple USB Ethernet adapters of identical make and model,
> how does OpenBSD distinguish them over time.

In the order their drivers reach "interface attach" code.  There are
multiple reasons the drivers could reach this out of order.

> In other words if
> there's a reboot or the adapters get unplugged and moved around and
> plugged back in, is there a way to make sure that the adapters
> associated with axen0 and axen1 maintain those associations?

No.

> Is there some way to pin an interface to the adapters MAC address?

No method comes to mind.

Well there is a method, but it is incompatible with KARL kernel
relinking so I don't think people should use that, and hence I'm not
going to explain it.

> A related question: if the adapters never move, and always stay in the
> same place on their respective USB hubs, will they always be numbered
> the same (axen0, axen1, etc)?

Cannot gaurantee that. Especially if they are on different usb busses,
or the initial probe fails, some probes may occur late and thus adjust
the order.



OpenBSD 6.8 released, - Oct 18, 2020

2020-10-18 Thread Theo de Raadt



- OpenBSD 6.8 RELEASED -

October 18, 2020.

We are pleased to announce the official release of OpenBSD 6.8.
This day marks the OpenBSD project's 25th anniversary.  As we celebrate
our 49th release, we remain proud of OpenBSD's record of more than
twenty years with only two remote holes in the default install.

As in our previous releases, 6.8 provides significant improvements,
including new features, in nearly all areas of the system:

 - New/extended platforms:
o New powerpc64 platform, supporting PowerNV (non-virtualized)
  systems with POWER8 and POWER9 CPUs, such as Raptor Computing
  Systems Talos II and Blackbird systems. POWER8 support has not
  been tested on real hardware yet.

 - Improvements to time measurements, mostly in the kernel:
o Added support in the kernel and libc for timecounting in userland,
  eliminating the need for a context switch everytime a process
  requests the current time, thereby improving speed and
  responsiveness in programs which make many gettimeofday(2) calls,
  especially browsers and office software.
  The userland timecounters are enabled on the amd64, arm64, macppc,
  octeon and sparc64 architectures.
o Added a ktrace(1) -T option to make time-related system calls more
  prominent.
o Added tsc_delay(), a delay(9) implementation based on the TSC, to
  amd64.
o Used an LFENCE instruction everywhere RDTSC is used for a time
  measurement, reducing the jitter in TSC skew measurements.
o Introduced gettime(9) and getuptime(9) and substituted these for
  time_second(9) and time_uptime(9) throughout the kernel to prevent
  split-read problems on 32-bit platforms.
o Synchronized each core's CP0 cycle counter using the IO clock
  counter on mips64 and octeon, making the cycle counter usable as
  timecounter.
o Improved CPU frequency scaling in automatic performance mode by
  removing accounting for offline CPUs.

 - Various kernel improvements:
o Added intrmap, an interrupt to CPU mapping API that is used by
  hardware drivers to use multiple CPUs for interrupt handling.
o Added an ioctl PCIOCGETVPD allowing userland to access read-only
  support information about pci devices via the vpd register.
o Set ddb(4) "/t" to show a trace via TID on all architectures.
o Introduced kstat(1), a subsystem to allow the kernel to expose
  statistics to userland.
o Added kstat to cnmac(4).
o Added support for remote coverage to kcov(4).
o Moved sysctl(2) CTL_DEBUG from DEBUG to the new DEBUG_SYSCTL.
o Prevented creation of bogus sd(4) devices for nvme(4) namespaces
  which are configured but have size 0.
o Added READ(12)/WRITE(12) support to cd(4).
o Used READ(16)/WRITE(16) commands for disks large enough to require
  them to access the last sectors, fixing large 512E devices plugged
  into USB to ATA/ATAPI bridges which mistakenly use 4K sector
  addresses/sizes.
o Restored VGA fonts on VT switch, preventing an unusable screen
  when switching to a VT with a custom VGA font from X.
o Ensured only pseudo-terminal devices use reprint delays.
o Prevented improper disabling of the backlight in umstc(4) when
  brightness is adjusted to 0.
o Provided an optimized implementation of ffs(3) in the kernel on
  arm64/powerpc/powerpc64.
o Rewrote m88k mutex code as a slight variation of the MI mutex
  code, potentially improving stability and rendering mutex spinning
  time visible in top(1).
o Reworked kernel loading with octboot, the OpenBSD/octeon
  bootloader, which now does not rely on a mounted filesystem.
o Ensured scsi(4) devices do not attempt to process bogus MODE SENSE
  data.

 - Various new userland features:
o Imported login_ldap(8), using ldap(1) rather than openldap.
o Added support for set -o pipefail to ksh(1), potentially helping
  error checking.
o Cleared the screen in ksh(1)'s vi mode before redrawing the line
  with ^L.
o Implemented the gensub(), systime() and strftime() functions for
  awk(1).
o Allowed specification of supported TLS protocols in ftp(1) "-S
  protocols".
o Switched the default man(1) pager from "more(1) -s" to less(1).
o Supported -T html -O tag in man(1) by passing a file:// URI to the
  pager.
o Added fstat(1) support for looking up unix domain sockets by file
  name.
o Added / as an alias for g (grep) in top(1).
o Provided a naptime variable for userspace via kvm_read(3), usable
  by vmstat(8).
o Allowed switching between alternate devices (-F) with sndioctl(1).
o Added the ability to set and display video(1) control values
  directly on the CLI.
o Allowed the combination of video(1) "-dc" options, reset and
  display 

Re: direct audio HW access

2020-10-17 Thread Theo de Raadt
Jan Stary  wrote:

> On Oct 17 11:29:58, dera...@openbsd.org wrote:
> > Jan Stary  wrote:
> > 
> > > On Oct 17 11:02:19, dera...@openbsd.org wrote:
> > > > Jan Stary  wrote:
> > > > 
> > > > > Currently, the decription of sndiod -a says
> > > > > 
> > > > >   If the flag is off, then it's automatically closed,
> > > > >   allowing other programs to have direct access to the audio 
> > > > > device,
> > > > >   or the device to be disconnected. The default is off.
> > > > > 
> > > > > That's not true anymore: programs only access the audio HW
> > > > > through the running sndiod, right?
> > > > 
> > > > and if there is no running sndiod, then someone who has written a
> > > > program to access the audio hardware directly, can.
> > > 
> > > crw-rw  1 root  _sndiop   42,   0 Oct 17 19:04 /dev/audio0
> > > crw-rw  1 root  _sndiop   42,   1 Oct 16 09:29 /dev/audio1
> > > crw-rw  1 root  _sndiop   42,   2 Oct 15 21:24 /dev/audio2
> > > crw-rw  1 root  _sndiop   42,   3 Oct 15 21:24 /dev/audio3
> > > crw-rw  1 root  _sndiop   42, 192 Oct 15 21:24 /dev/audioctl0
> > > crw-rw  1 root  _sndiop   42, 193 Oct 15 21:24 /dev/audioctl1
> > > crw-rw  1 root  _sndiop   42, 194 Oct 15 21:24 /dev/audioctl2
> > > crw-rw  1 root  _sndiop   42, 195 Oct 15 21:24 /dev/audioctl3
> > > 
> > > The device is chgrp'ed precisely so that they _can't_, right?
> > 
> > What if the other program is run as root, and the reader has permission?
> 
> Well, a program run as root can do whatever it wants.
> 
> What I meant was the wording in the sndiod -a documentation:
> for "other programs to have direct access to the audio device",
> they would have to be in the _sndiop group or be root.
> 
> I don't think that's the intended meaning: before the change,
> a user program (such as sox(1)) could play directly to the device
> when sndiod -a off was not using it. Now it can't.
> The current wording seems to be a relict.

This is the sndiod page.  It is describing the behaviour of the sndiod.
It is describing how it opens and closes devices.

Does it still open and close devices that way?

I'm not talking about whether someone use it.  Obviously someone as
root can rely on this open or close behaviour, if the open and close
behaviour code is still there.






Re: direct audio HW access

2020-10-17 Thread Theo de Raadt
Jan Stary  wrote:

> On Oct 17 11:02:19, dera...@openbsd.org wrote:
> > Jan Stary  wrote:
> > 
> > > Currently, the decription of sndiod -a says
> > > 
> > >   If the flag is off, then it's automatically closed,
> > >   allowing other programs to have direct access to the audio device,
> > >   or the device to be disconnected. The default is off.
> > > 
> > > That's not true anymore: programs only access the audio HW
> > > through the running sndiod, right?
> > 
> > and if there is no running sndiod, then someone who has written a
> > program to access the audio hardware directly, can.
> 
> crw-rw  1 root  _sndiop   42,   0 Oct 17 19:04 /dev/audio0
> crw-rw  1 root  _sndiop   42,   1 Oct 16 09:29 /dev/audio1
> crw-rw  1 root  _sndiop   42,   2 Oct 15 21:24 /dev/audio2
> crw-rw  1 root  _sndiop   42,   3 Oct 15 21:24 /dev/audio3
> crw-rw  1 root  _sndiop   42, 192 Oct 15 21:24 /dev/audioctl0
> crw-rw  1 root  _sndiop   42, 193 Oct 15 21:24 /dev/audioctl1
> crw-rw  1 root  _sndiop   42, 194 Oct 15 21:24 /dev/audioctl2
> crw-rw  1 root  _sndiop   42, 195 Oct 15 21:24 /dev/audioctl3
> 
> The device is chgrp'ed precisely so that they _can't_, right?

What if the other program is run as root, and the reader has permission?



Re: direct audio HW access

2020-10-17 Thread Theo de Raadt
Jan Stary  wrote:

> Currently, the decription of sndiod -a says
> 
>   If the flag is off, then it's automatically closed,
>   allowing other programs to have direct access to the audio device,
>   or the device to be disconnected. The default is off.
> 
> That's not true anymore: programs only access the audio HW
> through the running sndiod, right?

and if there is no running sndiod, then someone who has written a
program to access the audio hardware directly, can.  The device is
supposed to only have one open.

I believe what changed is that the library no longer attempts to use
the hardware directly but uses the sndiod input.

Isn't that what is going on?



Re: sysupgrade doesn't like the path

2020-10-10 Thread Theo de Raadt
Ed Ahlsen-Girard  wrote:

> sysupgrade is looking for files in 6.9 (which isn't being found). Is
> this due to a slow mirror upgrade or just "near release stuff"?

fw_update, sysupgrade, pkg_add, syspatch, and some other things have
heuristic issues near release, and it is difficult to fix because
what we release gets a bit incoherent and weird. we don't want these
things to probe too much and then for the probes to be attackable.



Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

2020-09-28 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2020-09-28, Greg Thomas  wrote:
> >  "Have sysupgrade just do the right thing. For example, there could be
> > a _sysupgrade user in the systems /etc/passwd, whose $HOME would
> > indicate the preferred location for sets"
> >
> > Holy fucking overkill.
> 
> meh. It *is* a problem on some systems, especially if the disk layout
> was done pre-sysupgrade.

sysupgrade.sh was added 2019/04/25.  it has the following tags:

OPENBSD_6_8: 1.40.0.4
OPENBSD_6_8_BASE: 1.40
OPENBSD_6_7: 1.37.0.4
OPENBSD_6_7_BASE: 1.37
OPENBSD_6_6: 1.25.0.4
OPENBSD_6_6_BASE: 1.25
OPENBSD_6_5: 1.25.0.2

we only "support" the current release (6.7), the previous release (6.6).

So, people have disk layouts which predate our "support" cycle.  sysupgrade
was not intended to deal with strange layouts.  Many of us feel that sysupgrade
should not bend over to deal with strange layouts.

So we are at an impasse.  The recommended solution is for people to stop
making sysupgrade-incompatible layouts in the future, and to consider
repairing their incompatible layouts from the past.

if sysupgrade doesn't work, people have the old ways of doing things.
doctor doctor it hurts when i layout my disk strangely...



Re: Issues with TP-Link UE300

2020-09-27 Thread Theo de Raadt
In other words, you don't know but are very eager to use your mail client
right now.


Torsten  wrote:

> Sorry
> 
> Still connected to USB, I looked it up before replying
> 
> It looks more like a hardware design issue of the device it is connected to 
> plus many other issues related to the “Dongle” itself.
> 
>  
> 
> T 
> 
>  
> 
>  
> 
> From: Joel Carnat  
> Sent: 28 September 2020 00:21
> To: Torsten 
> Cc: misc@openbsd.org
> Subject: Re: Issues with TP-Link UE300
> 
>  
> 
> Well, this is no wifi device. This is an ethernet dongle.
> 
> That particular one:
> 
> https://www.tp-link.com/en/home-networking/computer-accessory/ue300/
> 
> Envoyé de mon iPad
> 
> 
> 
> 
> 
> Le 28 sept. 2020 à 00:55, Torsten   > a écrit :
> 
> HI
> As far as I can tell, WiFi is nominal speed, not designated speed
> Another dominating factors for that would be USB connection type, hardware 
> bus connections, motherboard design, direct processor lanes to where
> 
> Wifi is what it is, never as good as hard wired 100mb/1000mb or even 10gb 
> connections
> 
> Best
> T 
> 
> -Original Message-
> From: owner-m...@openbsd.org   
> mailto:owner-m...@openbsd.org> > On Behalf Of Joel 
> Carnat
> Sent: 27 September 2020 22:43
> To: misc@openbsd.org  
> Subject: Issues with TP-Link UE300
> 
> Hi,
> 
> I have plugged a TP-Link UE300 on my ThinkPad X260 running OpenBSD -snapshot 
> and it seems I can't get more than 100Mbps.
> 
> The dongle attaches and get an IP address. But the speed seems limited.
> Same behaviour when attached to the USB3 port of my APU4D4 (running 6.7).
> When plugged in a MacBook Pro (running macos), it gets Gbps speed.
> 
> I have noticed that it gets attached to cdce0; I thought the RTL8153 chipset 
> would give me an ure0 device.
> 
> Is this expected?
> Is there something I can do to get Gbps out of this device?
> 
> Thanks for help,
> Jo
> 
> --
> OpenBSD 6.8 (GENERIC.MP) #85: Sun Sep 27 13:39:51 MDT 2020
> 
> cdce0 at uhub0 port 15 configuration 2 interface 0 "TP-LINK USB 10/100/1000 
> LAN" rev 3.00/30.00 addr 4
> 
> # doas usbdevs -v 
>  
> Controller /dev/usb0:
> addr 01: 8086: Intel, xHCI root hub
> super speed, self powered, config 1, rev 1.00
> driver: uhub0
> addr 02: 8087:0a2b Intel, Bluetooth
> full speed, self powered, config 1, rev 0.01
> driver: ugen0
> addr 03: 5986:0706 SunplusIT Inc, Integrated Camera
> high speed, power 500 mA, config 1, rev 0.12
> driver: uvideo0
> addr 04: 2357:0601 TP-LINK, USB 10/100/1000 LAN
> super speed, power 64 mA, config 2, rev 30.00, iSerial 0100
> driver: cdce0
> 
> 
> 



Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

2020-09-27 Thread Theo de Raadt
Stuart Henderson  wrote:

> >  3. Have sysupgrade just do the right thing. For example, there could be
> > a _sysupgrade user in the systems /etc/passwd, whose $HOME would
> > indicate the preferred location for sets ... But best understand the
> > problem before designing a solution :)
> >
> > I guess that is reverse order of preference :)
> 
> There have been proposals (probably either here or on the tech@ list) to
> allow changing the path before, but IIRC not a robust diff to do this yet
> (problems with proposals included removing files that should not be
> removed under certain bad input).

The correct proposal is:

 Install your machines in a normal way.

It is not unreasonable.



Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

2020-09-27 Thread Theo de Raadt
Theo de Raadt  wrote:

> sysupgrade cannot handle strange setups.  By the time we started
> building it, there weren't enough free bytes left in bsd.rd to
> embed an AI to come with the crazy shit people do.

to cope with, I mean.

Q. "bsd.rd, can you come to my house and fix this?"
A. "No."



Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

2020-09-27 Thread Theo de Raadt
Why 42? The lists account.  wrote:


> On Sun, Sep 27, 2020 at 04:25:58PM -0400, Ian Darwin wrote:
> > > ...
> > > after the download of the new sets and the reboot, I would have been
> > > prompted as to what to do i.e. Install, Upgrade, or Shell.  Then for a
> > > keyboard layout (e.g. de) and for the name of the disk containing OpenBSD
> > > (i.e. the system root partition) or "/").
> > 
> > Something is wwrong here. That is not how sysupgrade works. Probably you
> > didn't install updated boot blocks and it has been failing to "switch
> > to bsd.upgrade" when rebooting after the download, and your latest
> > change installed the updated boot blocks, and now it is working.
>  
> I am not sure about that.

Your system is layed out strangely and sysupgrade cannot handle all
absurd layouts.

You can go back to manual upgrades.  Or you can reinstall your system
to look more normal.


sysupgrade cannot handle strange setups.  By the time we started
building it, there weren't enough free bytes left in bsd.rd to
embed an AI to come with the crazy shit people do.




Re: Primepower 250 vs Sunfire v215

2020-09-24 Thread Theo de Raadt
Kihaguru Gathura  wrote:

> Do you have experience with the Oracle 3.2TB NVMe PCIE 3.0 Solid State
> Drive with the V215?

Wow, you have a thick wallet.  Use a regular laptop NVME + adapter card
for PCIE and find somewhere else to spend the money.



Re: iwm0: fatal firmware error on Dell Latitude E5570

2020-09-24 Thread Theo de Raadt
Uwe Werler  wrote:

> On 24 Sep 12:24, Jan Stary wrote:
> > On Sep 24 11:36:24, h...@stare.cz wrote:
> > > This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
> > > iwm stopped working, saying
> > > 
> > >   iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
> > >   iwm0: fatal firmware error
> > >   iwm0: could not remove MAC context (error 35)
> > >   iwm0: fatal firmware error
> > >   iwm0: could not remove MAC context (error 35)
> > >   iwm0: fatal firmware error
> > >   iwm0: could not remove MAC context (error 35)
> > >   [etc]
> > > 
> > > This is after sysupgrade and a fw_update.
> > > Is anyone seeing the same?
> > > 
> > > Last changes to sys/dev/pci/*iwm* are months ago,
> > > and I have seen it work this week ...
> > 
> > After recompiling current, everything works again. Note that
> > it's GENERIC.MP now, as opposed to GENERIC installed by the sysupgrade.
> > (Can that be related to a iwm error?)
> > 
> > Jan
> > 
> 
> Hi Jan,
> 
> I have a similiar problem when using sysupgrade on Dell 7400 and on one Dell
> 7280 - installer switches to bsd.sp. I tried to debug that but when I boot
> into ramdisk it properly detects MP cpu. Checked that several times. I have
> another 7280 with exact the same config (dd'ed the hd) where it doesn't
> happen. That's strange.

I think kernel random relinking and other address space randomization is
exposing either an uninitialized variable or alignment attribute the
chip wants but the driver doesn't satisfy.



Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

2020-09-22 Thread Theo de Raadt
>In my use-case, the program’s correct functionality is less
>important than ensuring that the program cannot break out.

Astounding.  It's like you don't see correct execution environment for
a program as THE foundational aspect of security; while at the same
time this rests on the assuption that unveil and pledge are correct
code.  So some stuff has to be correct, but other stuff doesn't, and
then the handwaving begins.

I'm done talking about this.



Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

2020-09-22 Thread Theo de Raadt
>My primary use-case is that I would like to port a Linux web app
>(the Rust Playground) to OpenBSD.  The Rust Playground allows
>users to supply arbitrary source code, which is then compiled
>and executed.  I have no control over the contents of said code,
>so I have no way to ensure that these programs will call pledge(2)
>themselves.  Calling pledge(2) externally allows me to sandbox the
>untrusted binaries.

No it does not.  You keep using that vague word "sandbox", the word
has become pointless because it allows people to handwave away concerns
about "what happens when the software hits the boundaries".  In a real
backyard sandbox when the toy truck falls outside the box onto the grass
it's no big deal, but in the tech-space sandbox means bolting on "security"
without investing in actual "security".

I'll give it one more shot.

pledge is not a virtual machine.

It is a deliberately designed collection of POSIX subsets.  Every
subset you can generate is non-complaint with POSIX.  You have no idea
if the correctly-operating program won't hit one of those behavioral
changes, and then it is performing unintended behaviour.  The addition
of unveil and pledge enforcement has violated the assumptions of the
original program.  At a very fundamental level the program will
misbehave because you are putting it into an incorrect execution
environment.  The "containment method" WILL introduce changes in program
behaviour.

Let me be clear, the process you are engaging in is not ENGINEERING.
It is much closer to moving sand with plastic Tonka trucks.

>To be clear, I am only using execpromises because it is the only way
>I know of to solve my problem under OpenBSD.

I thought there were good usage cases for execpromises when I designed
it, but I've been unable to find them.

I was hoping people would not abuse it, but here we are.  You are
blindly accepting downsides which you cannot see.

That is why I intend to delete execpromises.



Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

2020-09-22 Thread Theo de Raadt
>I actually agree with this.  Designing a program with pledge in
>mind is always better.  However, that requires that the program be
>trusted, and there still may be some corner cases in which I can
>tighten down the pledge more than the program itself can.

I disagree. I don't believe you can correctly produce security, because
the pledge operation puts the program into an unexpected non-POSIX
operational environment, and will introduce new potential error conditions
the program does not expect.

>So I can sandbox ftp(1) more than ftp(1) can reasonably sandbox itself.

I very strongly disagree.  At best the pledge/unveil-wrapper will work in
a specific one-time configuration, and not be generalizable.

We do not want users to be experimenting with things they don't understand,
more precisely, things they cannot understand because this high-level pledge
command is changing big underlying conditions.

>To be fair, one could argue that ftp(1) should have a command-line
>option that enables these lockdown options and disables the features
>unsupported under this mode.

Disagree.  This is not supposed to be user visible.

>That isn’t actually not the main use case for pledge(1),
>at least for me.  The main use-case is to sandbox untrusted,
>potentially malicious executables.

That is propostrous.

You think it's a good idea to throw untrusted programs into an
environment they were not designed...

But I argue the behavioral changes (especially relating the unveil not
seeing files, or the subtle behaviour of pledge around "stat", or
lockeds objects being left lingering when the program terminates
unexpected, are *USER HOSTILE*, and we don't want to help people using
this excessively sharp tool cutting their hands off and coming to misc@
to tell us long stories which summarize to "I am using pledge wrong
and I don't understand the failure modes"

>I do not know any way to
>implement something like the Rust Playground securely on OpenBSD
>without using execpromises, at least without requiring at least part
>of the application to run as root.  With execpromises, sandboxing
>untrusted executables is trivial.  That’s what pledge(1) is for.

No it is not trivial!  You are running code in *NON-POSIX MODES*.

>In my main use-case, I know what pledges I am willing to allow
>untrusted code to have.  If it tries to do something that the
>sandbox doesn’t allow, it *should* fail.  I expect that some
>functionality *will* break.  That’s okay in my application.

But you are wrong.  There are non-terminating situations in unveil
and pledge, where a program which doesn't test for unexpected error
returns or specific errno's, as this is NOT A CORRECT POSIX ENVIRONEMT,
will go down a wrong path and do the wrong thing.

That is the opposite of sandboxing.



  1   2   3   4   5   6   7   8   9   10   >