Re: The 16 partitions thread

2020-04-30 Thread bofh
On Thu, Apr 30, 2020 at 11:13 AM Consus  wrote:

> On Thu, Apr 30, 2020 at 07:22:35AM -0500, Ed Ahlsen-Girard wrote:
> > I read the 16 partitions thread and think, "I marvel at their patience
> > with interlocutors who have not read the relevant source code and give
> > no indication that they would understand it if they did."
>
> Yeah, stupid users, right? Who needs them anyways.
>

You say that sarcastically, but that only shows that you don't know
anything about OpenBSD.  It has been stated many many times that OpenBSD is
written by the developers, for those said developers.  And they're sharing
it with us.

Think about that a little and then look at what you said again.


Re: Sound is good on OpenBSD

2020-04-30 Thread Abel Abraham Camarillo Ojeda
On Wed, Apr 29, 2020 at 7:46 AM Alexandre Ratchov  wrote:

> On Wed, Apr 29, 2020 at 11:46:06AM +0200, Moises Simon wrote:
> > On Tue, Apr 28, 2020 at 03:38:58PM -0500, Abel Abraham Camarillo Ojeda
> wrote:
> > > I think increasing -b option in sndiod helps to prevent audio jumping,
> I
> > > hear music with a local mpd with music directory over nfs, plus a lot
> of
> > > firefox and chrome and hear no jumps , etc
> > >
> > > regards
> >
> > I can confirm. For me setting -b 8640 stops the audio jumping.
> >
> > Thanks Abel.
> >
>
> what devices are you using? azalia? usb?
>


azalia0 at pci0 dev 31 function 3 "Intel 100 Series HD Audio" rev 0x21: msi
azalia0: codecs: Realtek ALC298, Intel/0x2809, using Realtek ALC298
audio0 at azalia0

$ grep sndiod /etc/rc.conf.local
sndiod_flags=-b12000

dmesg just in case:

 OpenBSD 6.7-beta (GENERIC.MP) #125: Sun Apr 12 14:56:53 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8431632384 (8041MB)
avail mem = 8163483648 (7785MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb9908000 (58 entries)
bios0: vendor LENOVO version "R0GET56W (1.56 )" date 08/31/2017
bios0: LENOVO 20JVS17D00
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT BOOT BATB
SLIC SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4)
RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) RP09(S4) RP10(S4) RP11(S4)
RP12(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2960.10 MHz, 06-4e-03
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2860.65 MHz, 06-4e-03
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2860.64 MHz, 06-4e-03
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2860.64 MHz, 06-4e-03
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 

loading DBD-Pg under base httpd, works but it's wrong way

2020-04-30 Thread Chris Bennett
I've had a hell of a time getting Pg.so to load under base httpd.

env LD_DEBUG=1 chroot /var/www script.pl
gives errors about DynaLoader not being able to load due to a missing
library.

After looking at Postgresql libraries loaded using pg_config --libs
I moved just those libs under /var/www.

Still no luck. However I did get barely enough of a hint with searches
to figure out that it wasn't finding libpq.a and libpq.so.6.11
But those are located under /usr/local/lib. I couldn't figure out how to
push over that directory into the search paths.
So I moved a copy of those under /var/www/usr/lib/ vs
/var/www/usr/local/lib/
Works just fine.

I know that this is the wrong solution, but I'm clueless where and how
to add the right search path.
Any clues would be extremely appreciated!

Chris Bennett




Re: RCS file ownership?

2020-04-30 Thread Lévai , Dániel
Hi all!

Years ago, I mean 10+, I was -- strangely -- quite actively using RCS for local 
configuration file history management, and fell into the same pit myself.

I made this [1] off the cuff diff then, and reading this thread thought that I 
need to see how badly it would apply for today's tree.
Well, surprisingly, it succeeded without any rejections, so here it is, maybe 
someone will find it useful.

It's automatic, so no option to enable this when invoking rcs(1).

Also, all I did was just regenerating the diff, not compiled or tested now... 
And I'm pretty sure I have had some troubles with it back then...

Anyway, enjoy :)

Dani

[1] https://gist.github.com/levaidaniel/dfc71d782a6e023459c04a3f30ff5a6e

‐‐‐ Original Message ‐‐‐
> Date: Thu, 30 Apr 2020 10:37:38 +0100
> From: Craig Skinner skin...@britvault.co.uk
> To: misc@openbsd.org
> Subject: Re: RCS file ownership?
> Message-ID: 20200430103738.1f7304f6@fir.internal
>
> G'day Adam/all,
>
> On Wed, 29 Apr 2020 12:43:42 -0500 Adam Thompson wrote:
>
> > When I use co(1) with "-l" to check out a file (and/or "ci -l") is
> > there any way to preserve file ownership and not have it reset to
> > the user running co(1) or ci(1)?
>
> Attached is a script I've used for years to work around this issue.
>
> No licence, do what you want with it.
>
> Rather rubbish to do this in the shell
>
> cop = check out, permissions
> cip = check in, permissions
>
> $ ls -ltrhF /usr/local/bin/c* | fgrep ciop
> -r-xr-xr-x 1 root bin 1.8K Jun 29 2013 /usr/local/bin/ciop*
> lrwxr-xr-x 1 root wheel 4B Apr 13 2015 /usr/local/bin/cop@ -> ciop
> lrwxr-xr-x 1 root wheel 4B Apr 13 2015 /usr/local/bin/cip@ -> ciop
>
> Cheers,
>
> --
>
> Craig Skinner | http://linkd.in/yGqkv7
>
> [Attachment of type application/octet-stream removed.]



Re: relayd: Why doesn't "tls keypair" look for the fullchain certificate?

2020-04-30 Thread Chad Hoolie
Hello,

Great idea - thanks a bunch!

--Chad

‐‐‐ Original Message ‐‐‐
On Thursday 30. April 2020 kl. 19:07, Anthony J. Bentley  
wrote:

> Chad Hoolie writes:
>
> > Why does "tls keypair" in relayd.conf look for the regular and not the
> > fullchain certificate?
>
> Certificate filenames are defined by your acme-client.conf.
>
> > Thus, forcing users who want an A+ certificate to spend hours
> > searching the web for this hack?
> > cd /etc/ssl
> > doas mv foobar.com.crt foobar.com.crt.bak
> > doas ln -s foobar.com.fullchain.pem foobar.com.crt
>
> Rather than symlink, just tell acme-client to create certificates with
> the filename relayd expects.
>
> domain example.com {
> domain key "/etc/ssl/private/example.com.key"
> domain full chain certificate "/etc/ssl/example.com.crt"
> sign with letsencrypt
> }




Re: relayd: Why doesn't "tls keypair" look for the fullchain certificate?

2020-04-30 Thread Anthony J. Bentley
Chad Hoolie writes:
> Why does "tls keypair" in relayd.conf look for the regular and not the
> fullchain certificate?

Certificate filenames are defined by your acme-client.conf.

> Thus, forcing users who want an A+ certificate to spend hours
> searching the web for this hack?
>
> cd /etc/ssl
> doas mv foobar.com.crt foobar.com.crt.bak
> doas ln -s foobar.com.fullchain.pem foobar.com.crt

Rather than symlink, just tell acme-client to create certificates with
the filename relayd expects.

domain example.com {
domain key "/etc/ssl/private/example.com.key"
domain full chain certificate "/etc/ssl/example.com.crt"
sign with letsencrypt
}



Re: The 16 partitions thread

2020-04-30 Thread Consus
On Thu, Apr 30, 2020 at 07:22:35AM -0500, Ed Ahlsen-Girard wrote:
> Some people read replies in misc and say, "wow, Theo and the OBSD devs
> are obnoxiously harsh.'
> 
> I read the 16 partitions thread and think, "I marvel at their patience
> with interlocutors who have not read the relevant source code and give
> no indication that they would understand it if they did."

Yeah, stupid users, right? Who needs them anyways.



Re: RCS file ownership?

2020-04-30 Thread Theo de Raadt
Adam Thompson  wrote:

> AFAICT, GNU RCS (v5.9.4, ca. 2015, examined) creates a temp file,
> unlinks the target file, then renames the temp file.  I beleve this
> guarantees(-ish, modulo "special" filesystems including NFS and
> FreeBSD's directory-SUID behaviour) that resulting file ownership =
> euid.

mktemp and rename sound like reasonable.

> The GNU docs mention the repo owner in passing a few times but do not
> have a section describing multi-user operation.

The documentation is irrelevant.  It should focus on what the code does,
why it seems to do it, and about whether the resulting behaviour is
convenient.

> I'm not sure which other implementations you'd be worried about

All of them.

> - I thought OpenBSD's RCS was the direct descendant of NetBSD's and
> shares common lineage with the other *BSDs?

The top of each source file claims otherwise.  It is a rewrite.

> All in all, it looks like RCS and its docs were written in the era
> when UNIX machines were - more or less by universally - used by
> multiple people, and you just had an innate sense of how multi-user
> file ownership would work.  Most of my UNIX machines now resemble
> appliances, and exactly zero of them are multi-user in the classical
> sense.

Documentation is irrelevant.  



Re: RCS file ownership?

2020-04-30 Thread Adam Thompson
Being neither a C programmer nor a Texinfo fan, checking GNU RCS is a 
bit painful, and my conclusions aren't guaranteed.



AFAICT, GNU RCS (v5.9.4, ca. 2015, examined) creates a temp file, 
unlinks the target file, then renames the temp file.  I beleve this 
guarantees(-ish, modulo "special" filesystems including NFS and 
FreeBSD's directory-SUID behaviour) that resulting file ownership = 
euid.


The GNU docs mention the repo owner in passing a few times but do not 
have a section describing multi-user operation.


The Tichy docs also don't mention file ownership.  I'm trying to review 
the O'Donovan book, too, but it's been a long time since I had to tool 
up to handle raw PS... not quite there yet.


Purdue RCS appears to be the direct ancestor of GNU RCS.

I'm not sure which other implementations you'd be worried about - I 
thought OpenBSD's RCS was the direct descendant of NetBSD's and shares 
common lineage with the other *BSDs?


All in all, it looks like RCS and its docs were written in the era when 
UNIX machines were - more or less by universally - used by multiple 
people, and you just had an innate sense of how multi-user file 
ownership would work.  Most of my UNIX machines now resemble appliances, 
and exactly zero of them are multi-user in the classical sense.


-Adam


On 2020-04-29 21:53, Theo de Raadt wrote:

Sorry, but my mail goes further.

It says it should be correct.  For some definition of correct.  It
should either behave somehow for a logical reason, or it should behave
in the historical fashion.  Or once the historical behaviour is looked
at, if there is an argument that is wrong, then it should be changed
with logic about "this is an improvement" backing the argument.

I think it is wrong to document how *this* rcs implimentation behaves,
without comparing it against others.

My guess is 50% that the others don't unlink, but rewrite the file.

And the changes it might require to be compatible are not substantial.
At most a 20 line diff, to a few programs in the family.

athom...@athompso.net wrote:


Thank you for that detail!

Addressing this one corner case would require substantial changes, I 
think.  Not worth

it, in my opinion.

I think it would be worthwhile describing the multi-user mode of 
operation of RCS in
the manual, as it's currently completely absent/omitted. Patch coming 
soon, maybe

tomorrow if I can make time.

-Adam

On Apr. 29, 2020 21:28, Theo de Raadt  wrote:

 athom...@athompso.net wrote:

 > Heh, good point.  Didn't even occur to me because as it happens, I 
am

 > running as root and would like to not change the ownership.-Adam
 > On Apr. 29, 2020 13:32, Anders Andersson  
wrote:

 >
 >   On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson 


 >   wrote:
 >   >
 >   > When I use co(1) with "-l" to check out a file (and/or "ci -l") 
is

 >   there
 >   > any way to preserve file ownership and *not* have it reset to 
the

 >   user
 >   > running co(1) or ci(1)?
 >   > I don't see anything in rcs(1), co(1) or ci(1) that even 
mentions

 >   the
 >   > fact that the file will wind up owned by the user running the
 >   command.
 >   > Ideas?  Pointers to documentation?
 >
 >   How could it possibly do anything else unless you always run co 
as

 >   root?

 Our rcs tools do:

 52628 co   RET   kbind 0
 52628 co   CALL  unlink(0x7f7ed1f3)
 52628 co   NAMI  "ls.c"
 52628 co   RET   unlink -1 errno 2 No such file or directory
 52628 co   CALL  open
 (0x7f7ed1f3,0x601,0100444)
 52628 co   NAMI  "ls.c"
 52628 co   RET   open 4
 52628 co   CALL  kbind(0x7f7ec908,24,0x847da2a816b5d817)

 Which appears to be this:

 else {
 (void)unlink(dst);

 if ((fd = open(dst, O_WRONLY|O_CREAT|O_TRUNC, mode)) 
== -1)

 err(1, "%s", dst);

 I don't know what older or gnu rcs do.  I guess whichever way this is 
done
 it must balance concerns between atomicity of concurrent reads 
performed
 by earlier processes, versus replacement of a potentially active 
file.


 If the latter is chosen, it would unlink(), perform the open more
 carefully, check that it is in the right place with fstat, but then
 it needs some work for ftruncate (to get rid of extra file contents
 at the end).  If the open() failed, it might try an unlink followed 
by

 open()?

 Other rcs implimentations need to be checked.  It is better if they 
work

 the same.





Re: How to enable TLS 1.3?

2020-04-30 Thread Chad Hoolie
Thanks a lot for the help Martijn.

Fingers crossed it will appear soon. Our search engine rankings depend on it!

--Chad

‐‐‐ Original Message ‐‐‐
On Thursday, April 30, 2020 4:16 PM, Martijn van Duren 
 wrote:

> If it's not in the manpage it's probably not there.
> I did gave a quick look through the relayd source, but from what I saw
> there's no TLS1.3 support there.
>
> On 4/30/20 3:55 PM, Chad Hoolie wrote:
>
> > Any idea about relayd though? I don't see any mentioning of 1.3 in man 
> > relayd.conf:
> > tls
> > no tlsv1.2
> > Disable the TLSv1.2 protocol. The default is to enable
> > TLSv1.2.
> > sslv3 Enable the SSLv3 protocol. The default is no sslv3.
> > tlsv1 Enable all TLSv1 protocols. This is an alias that
> > includes tlsv1.0, tlsv1.1, and tlsv1.2. The default is
> > no tlsv1.
> > tlsv1.0
> > Enable the TLSv1.0 protocol. The default is no tlsv1.0.
> > tlsv1.1
> > Enable the TLSv1.1 protocol. The default is no tlsv1.1.
> > --Chad
> > ‐‐‐ Original Message ‐‐‐
> > On Thursday, April 30, 2020 3:04 PM, Martijn van Duren 
> > openbsd+m...@list.imperialat.at wrote:
> >
> > > On 4/30/20 1:19 PM, Chad Hoolie wrote:
> > >
> > > > Hello,
> > > > I'm using httpd with acme-client and Let's Encrypt 
> > > > (https://www.romanzolotarev.com/openbsd/acme-client.html).
> > > > This setup, however, only seems to support TLS 1.2, whereas TLS 1.3 is 
> > > > needed to achieve A+ ratings across the board.
> > > > Anybody know how to make the upgrade?
> > > > --Chad
> > >
> > > httpd(8):
> > > protocols string Specify the TLS protocols to enable for this server.
> > > If not specified, the value "default" will be used (secure protocols;
> > > TLSv1.2-only). Refer to the tls_config_parse_protocols(3) function for
> > > other valid protocol string values.
> > > tls_config_parse_protocols(3):
> > > Valid keywords are tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3, all (all
> > > supported protocols),
> > > untested, but seems pretty self-explanatory.




Re: How to enable TLS 1.3?

2020-04-30 Thread Kevin Chadwick
On 2020-04-30 13:55, Chad Hoolie wrote:
> Any idea about relayd though? I don't see any mentioning of 1.3 in man 
> relayd.conf:

I'm not a dev but tls1.3 dropped RSA and I think requires ecdsa key support that
relayd currently lacks.

Although httpd was originally based on relayd. I assume the code is different
here because of relayds more complex tls interception and acceleration 
abilities.

Pound and nginx may be alternatives, but they likely won't protect the key so
well, if an exploit is found.



Re: How to enable TLS 1.3?

2020-04-30 Thread Chad Hoolie
Any idea about relayd though? I don't see any mentioning of 1.3 in man 
relayd.conf:

tls
  no tlsv1.2
  Disable the TLSv1.2 protocol.  The default is to enable
  TLSv1.2.

  sslv3   Enable the SSLv3 protocol.  The default is no sslv3.

  tlsv1   Enable all TLSv1 protocols.  This is an alias that
  includes tlsv1.0, tlsv1.1, and tlsv1.2.  The default is
  no tlsv1.

  tlsv1.0
  Enable the TLSv1.0 protocol.  The default is no tlsv1.0.

  tlsv1.1
  Enable the TLSv1.1 protocol.  The default is no tlsv1.1.

--Chad

‐‐‐ Original Message ‐‐‐
On Thursday, April 30, 2020 3:04 PM, Martijn van Duren 
 wrote:

> On 4/30/20 1:19 PM, Chad Hoolie wrote:
>
> > Hello,
> > I'm using httpd with acme-client and Let's Encrypt 
> > (https://www.romanzolotarev.com/openbsd/acme-client.html).
> > This setup, however, only seems to support TLS 1.2, whereas TLS 1.3 is 
> > needed to achieve A+ ratings across the board.
> > Anybody know how to make the upgrade?
> > --Chad
>
> httpd(8):
> protocols string Specify the TLS protocols to enable for this server.
> If not specified, the value "default" will be used (secure protocols;
> TLSv1.2-only). Refer to the tls_config_parse_protocols(3) function for
> other valid protocol string values.
>
> tls_config_parse_protocols(3):
> Valid keywords are tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3, all (all
> supported protocols),
>
> untested, but seems pretty self-explanatory.




Re: How to enable TLS 1.3?

2020-04-30 Thread Martijn van Duren
If it's not in the manpage it's probably not there.
I did gave a quick look through the relayd source, but from what I saw  
there's no TLS1.3 support there.


On 4/30/20 3:55 PM, Chad Hoolie wrote:
> Any idea about relayd though? I don't see any mentioning of 1.3 in man 
> relayd.conf:
> 
> tls
>   no tlsv1.2
>   Disable the TLSv1.2 protocol.  The default is to enable
>   TLSv1.2.
> 
>   sslv3   Enable the SSLv3 protocol.  The default is no sslv3.
> 
>   tlsv1   Enable all TLSv1 protocols.  This is an alias that
>   includes tlsv1.0, tlsv1.1, and tlsv1.2.  The default is
>   no tlsv1.
> 
>   tlsv1.0
>   Enable the TLSv1.0 protocol.  The default is no tlsv1.0.
> 
>   tlsv1.1
>   Enable the TLSv1.1 protocol.  The default is no tlsv1.1.
> 
> --Chad
> 
> ‐‐‐ Original Message ‐‐‐
> On Thursday, April 30, 2020 3:04 PM, Martijn van Duren 
>  wrote:
> 
>> On 4/30/20 1:19 PM, Chad Hoolie wrote:
>>
>>> Hello,
>>> I'm using httpd with acme-client and Let's Encrypt 
>>> (https://www.romanzolotarev.com/openbsd/acme-client.html).
>>> This setup, however, only seems to support TLS 1.2, whereas TLS 1.3 is 
>>> needed to achieve A+ ratings across the board.
>>> Anybody know how to make the upgrade?
>>> --Chad
>>
>> httpd(8):
>> protocols string Specify the TLS protocols to enable for this server.
>> If not specified, the value "default" will be used (secure protocols;
>> TLSv1.2-only). Refer to the tls_config_parse_protocols(3) function for
>> other valid protocol string values.
>>
>> tls_config_parse_protocols(3):
>> Valid keywords are tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3, all (all
>> supported protocols),
>>
>> untested, but seems pretty self-explanatory.
> 
> 



The 16 partitions thread

2020-04-30 Thread Ed Ahlsen-Girard
Some people read replies in misc and say, "wow, Theo and the OBSD devs
are obnoxiously harsh.'

I read the 16 partitions thread and think, "I marvel at their patience
with interlocutors who have not read the relevant source code and give
no indication that they would understand it if they did."

-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL




Re: How to enable TLS 1.3?

2020-04-30 Thread Martijn van Duren
On 4/30/20 1:19 PM, Chad Hoolie wrote:
> Hello,
> 
> I'm using httpd with acme-client and Let's Encrypt 
> (https://www.romanzolotarev.com/openbsd/acme-client.html).
> 
> This setup, however, only seems to support TLS 1.2, whereas TLS 1.3 is needed 
> to achieve A+ ratings across the board.
> 
> Anybody know how to make the upgrade?
> 
> --Chad
> 
httpd(8):
protocols string Specify the TLS protocols to enable for this server.   
If not specified, the value "default" will be used (secure protocols; 
TLSv1.2-only).  Refer to the tls_config_parse_protocols(3) function for 
other valid protocol string values.


tls_config_parse_protocols(3):
Valid keywords are tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3, all (all
supported protocols),

untested, but seems pretty self-explanatory.



Re: installation hangs/crashes on 2007 iMac

2020-04-30 Thread Jan Stary
On Apr 29 14:12:24, open...@2al.ch wrote:
> I have an Macmini2,1 from mid 2007 with similar specs [1] and presumably
> similar firmware. I tested a whole lot of combinations for booting it and
> came to the following conclusion:
> 
> To boot OpenBSD you have to use the internal SATA or ATA devices.
> 
> That means you need to use the CD/DVD-drive as installation medium
> (installXX.iso). Alternatively you can replace the CD/DVD-drive with a
> hard drive and use that as installation medium.
> 
> Booting from USB only works for MacOS X.
> 
> EFI-Booting (32-bit on my setup) works fine. To speed up boot time after
> the installation of OpenBSD, use the Mac-proprietary bless(1) command [2]
> once (by booting some MacOS or MacOS installation medium). It writes
> your preferred boot volume into NV-RAM, thus skips the boot volume
> search (grey boot screen after turning the machine on) and continues
> booting OpenBSD immediately.

Just for completeness: when you boot into macOS again,
it will apparently bless the macOS partition again;
so you have to bless OpenBSD again
before rebooting from macOS.

Jan



relayd: Why doesn't "tls keypair" look for the fullchain certificate?

2020-04-30 Thread Chad Hoolie
Hi,

Why does "tls keypair" in relayd.conf look for the regular and not the 
fullchain certificate?

Thus, forcing users who want an A+ certificate to spend hours searching the web 
for this hack?

cd /etc/ssl
doas mv foobar.com.crt foobar.com.crt.bak
doas ln -s foobar.com.fullchain.pem foobar.com.crt

From: http://blog.snailtext.com/posts/sni-relayd-support-in-six-point-six.html

-- Chad



How to enable TLS 1.3?

2020-04-30 Thread Chad Hoolie
Hello,

I'm using httpd with acme-client and Let's Encrypt 
(https://www.romanzolotarev.com/openbsd/acme-client.html).

This setup, however, only seems to support TLS 1.2, whereas TLS 1.3 is needed 
to achieve A+ ratings across the board.

Anybody know how to make the upgrade?

--Chad



Re: RCS file ownership?

2020-04-30 Thread Craig Skinner
G'day Adam/all,

On Wed, 29 Apr 2020 12:43:42 -0500 Adam Thompson wrote:
> When I use co(1) with "-l" to check out a file (and/or "ci -l") is
> there any way to preserve file ownership and *not* have it reset to
> the user running co(1) or ci(1)?


Attached is a script I've used for years to work around this issue.

No licence, do what you want with it.

Rather rubbish to do this in the shell


cop = check out, permissions
cip = check in, permissions


$ ls -ltrhF /usr/local/bin/c* | fgrep ciop
-r-xr-xr-x  1 root  bin 1.8K Jun 29  2013 /usr/local/bin/ciop*
lrwxr-xr-x  1 root  wheel 4B Apr 13  2015 /usr/local/bin/cop@ -> ciop
lrwxr-xr-x  1 root  wheel 4B Apr 13  2015 /usr/local/bin/cip@ -> ciop


Cheers,
-- 
Craig Skinner | http://linkd.in/yGqkv7


ciop
Description: Binary data