Re: sparc64 boot issue on qemu

2020-06-01 Thread Theo de Raadt
Jason A. Donenfeld  wrote:

> Wow, that's magic, and works perfectly:
> https://data.zx2c4.com/openbsd-qemu-sparc64-pretty-vga-with-serif-font.png
> Pretty font too.
> 
> It sounds like the issue we're facing here is that the addr function
> is missing from QEMU's firmware? Would it be quasi interesting to
> remove use of it from OpenBSD? Or should we take this over to QEMU
> instead and get it implemented?

They should impliment emulation of the hardware properly.

Or maybe relabel their work as "qemu sparc64-best-bullshit-we-got"



Re: bioctl: Allow passphrase files to be chmod 400

2020-06-01 Thread Klemens Nanni
On Mon, Jun 01, 2020 at 06:28:40PM -0400, Daniel Jakots wrote:
> To be sure I don't accidentally overwrite the passphrase files, I'd
> like to make them read only. The current code expects them to be
> readable and writable. I took the new code from ssh (sshkey_perm_ok
> function).
Permissions only protect you against non-root users;  for more there's
chflags(1), e.g. `chflags schg ./keyfile ; sysctl kern.securelevel=1'.



bioctl: Allow passphrase files to be chmod 400

2020-06-01 Thread Daniel Jakots
Hi,

To be sure I don't accidentally overwrite the passphrase files, I'd
like to make them read only. The current code expects them to be
readable and writable. I took the new code from ssh (sshkey_perm_ok
function).

While there, I changed the error message (also based on ssh) so the
user has a better idea of what the program wants.

Index: bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.144
diff -u -p -r1.144 bioctl.c
--- bioctl.c25 Apr 2020 14:37:43 -  1.144
+++ bioctl.c1 Jun 2020 22:10:31 -
@@ -1328,8 +1328,8 @@ derive_key(u_int32_t type, int rounds, u
err(1, "can't stat passphrase file");
if (sb.st_uid != 0)
errx(1, "passphrase file must be owned by root");
-   if ((sb.st_mode & ~S_IFMT) != (S_IRUSR | S_IWUSR))
-   errx(1, "passphrase file has the wrong permissions");
+   if ((sb.st_mode & 077) != 0)
+   errx(1, "passphrase file must not be accessible by 
others");
 
if (fgets(passphrase, sizeof(passphrase), f) == NULL)
err(1, "can't read passphrase file");


Cheers,
Daniel



Re: Xwindows keymap weirdness

2020-06-01 Thread Marc Espie
On Mon, Jun 01, 2020 at 03:37:45PM -0600, Anthony J. Bentley wrote:
> Marc Espie writes:
> > > To setup the right alt key as compose, you can either:
> > > 
> > > - run 'setxkbmap -option compose:ralt' somewhere in your session
> > >   startup script
> > > 
> > > - create /etc/X11/xorg.conf.d/90-keyboard.conf containing
> > > 
> > > --- Cut ---
> > > Section "InputClass"
> > > Identifier "Kbd"
> > > MatchDriver "kbd"
> > > Option "XkbOptions" "compose:ralt"
> > > EndSection
> > > --- Cut ---
> >
> > I used to understand that shit back in xmodmap days.
> > I'll admit I'm completely lost with setxkbmap
> >
> > Along the same lines, how can you simply disable caps lock ?
> 
> caps:none
> 
> Personally I run with caps:ctrl_modifier (caps becomes ctrl).
> 
> These variants are documented in xkeyboard-config(7) (needs a large
> terminal to be readable).


Oh wow, this doc is a complete piece of shit.
I finally figured it out the relationship between setxkbmap
and xkeyboard-config thanks to the lines you gave.

It would be sooo enlightening to have a few EXAMPLES in setxkbmap(1)
that does explain how xkeyboard-config(7) actually works.

Last time I looked, I thought I need to create my own description that would
be compiled through xkbcomp(1), that's how misleading this so called
"documentation" is.

Thank you Anthony!



BIOCINSTALLBOOT/sparc64 installboot: EFBIG on too big boot loaders

2020-06-01 Thread Klemens Nanni
Installing an unstripped boot loader on softraid on sparc64 fails
without proper error message.

Make BIOCINSTALLBOOT return a proper errno, make installboot(8) use it
to provide proper usage errors plus unique code paths for debugging.

At first, I made sr_ioctl_installboot() use sr_error() in the relevant
spot and this made the kernel print my errors, however the following
piece in softraid.c:sr_bio_handler() means using sr_error() will hide
the error code from the ioctl(2) call, i.e. installboot(8) would
report no error message on stderr and exit zero:

if (sc->sc_status.bs_msg_count > 0)  
rv = 0;

So instead, use a proper errno that yields a simple

# ./obj/installboot sd2 /usr/mdec/bootblk /ofwboot.new
installboot.sr: softraid installboot failed: File too large



Background:  I built ofwboot on one machine ("make" without
"make install", then copy obj/ofwboot over), the resulting executable
was not stripped during build (happens during "make install") and was
about twice as big:

# ls -l /ofwboot*   
-rw-r--r--  1 root  wheel  106688 May 23 22:42 /ofwboot
-rwxr-xr-x  1 knwheel  272452 May 24 00:20 /ofwboot.new
-rwxr-xr-x  1 root  wheel  106752 May 24 01:21 /ofwboot.new.strip

It took me longer than anticipated to find out that installboot(8)
fails beause my new boot loader was too big:

# installboot sd2 /usr/mdec/bootblk /ofwboot.new
installboot: softraid installboot failed

# installboot -v sd2 /usr/mdec/bootblk /ofwboot.new
Using / as root
installing bootstrap on /dev/rsd2c
using first-stage /usr/mdec/bootblk, second-stage /ofwboot.new
boot block is 6882 bytes (14 blocks @ 512 bytes = 7168 bytes)
sd2: softraid volume with 1 disk(s)
sd2: installing boot loader on softraid volume
installboot: softraid installboot failed

That's it, no details or additional messages from the kernel.
While this was primarily my own fault, perhaps there are more legitimate
reasons foor bootblk/ofwboot builds to exceed their maximum size.

Feedback? OK?


diff --git a/sys/dev/softraid.c b/sys/dev/softraid.c
index dce30576d..8fab24ecc 100644
--- a/sys/dev/softraid.c
+++ b/sys/dev/softraid.c
@@ -3704,11 +3704,11 @@ sr_ioctl_installboot(struct sr_softc *sc, struct 
sr_discipline *sd,
goto done;
}
 
-   if (bb->bb_bootblk_size > SR_BOOT_BLOCKS_SIZE * DEV_BSIZE)
-   goto done;
-
-   if (bb->bb_bootldr_size > SR_BOOT_LOADER_SIZE * DEV_BSIZE)
+   if (bb->bb_bootblk_size > SR_BOOT_BLOCKS_SIZE * DEV_BSIZE ||
+   bb->bb_bootldr_size > SR_BOOT_LOADER_SIZE * DEV_BSIZE) {
+   rv = EFBIG;
goto done;
+   }
 
secsize = sd->sd_meta->ssdi.ssd_secsize;
 
diff --git a/usr.sbin/installboot/sparc64_softraid.c 
b/usr.sbin/installboot/sparc64_softraid.c
index 776cf4a64..851c48a19 100644
--- a/usr.sbin/installboot/sparc64_softraid.c
+++ b/usr.sbin/installboot/sparc64_softraid.c
@@ -96,6 +96,6 @@ sr_install_bootldr(int devfd, char *dev)
fprintf(stderr, "%s: installing boot loader on "
"softraid volume\n", dev);
if (ioctl(devfd, BIOCINSTALLBOOT, ) == -1)
-   errx(1, "softraid installboot failed");
+   err(1, "softraid installboot failed");
}
 }



TCP congestion window pinned by integer arithmetic

2020-06-01 Thread Brian Brombacher
Hi,

RFC 5681 Section 3.1 has an Implementation Note that covers the bug fixed by 
the following patch.  I ran into this bug testing on a high latency link.  My 
congestion window was pinned to a specific value and could not open further, 
causing a lack of bandwidth utilization.

I chose if/assign rather than max(9) for clarity with the RFC; however, both 
work fine.

Cheers,
Brian


Index: tcp_input.c
===
RCS file: /home/brian/cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.364
diff -u -r1.364 tcp_input.c
--- tcp_input.c 6 Dec 2019 14:43:14 -   1.364
+++ tcp_input.c 1 Jun 2020 21:16:26 -
@@ -1707,8 +1707,11 @@
u_int cw = tp->snd_cwnd;
u_int incr = tp->t_maxseg;
 
-   if (cw > tp->snd_ssthresh)
+   if (cw > tp->snd_ssthresh) {
incr = incr * incr / cw;
+   if (incr == 0)
+   incr = 1;
+   }
if (tp->t_dupacks < tcprexmtthresh)
tp->snd_cwnd = ulmin(cw + incr,
TCP_MAXWIN << tp->snd_scale);



Re: Xwindows keymap weirdness

2020-06-01 Thread Anthony J. Bentley
Marc Espie writes:
> > To setup the right alt key as compose, you can either:
> > 
> > - run 'setxkbmap -option compose:ralt' somewhere in your session
> >   startup script
> > 
> > - create /etc/X11/xorg.conf.d/90-keyboard.conf containing
> > 
> > --- Cut ---
> > Section "InputClass"
> > Identifier "Kbd"
> > MatchDriver "kbd"
> > Option "XkbOptions" "compose:ralt"
> > EndSection
> > --- Cut ---
>
> I used to understand that shit back in xmodmap days.
> I'll admit I'm completely lost with setxkbmap
>
> Along the same lines, how can you simply disable caps lock ?

caps:none

Personally I run with caps:ctrl_modifier (caps becomes ctrl).

These variants are documented in xkeyboard-config(7) (needs a large
terminal to be readable).



Re: Xwindows keymap weirdness

2020-06-01 Thread Marc Espie
On Mon, Jun 01, 2020 at 03:46:09PM +0200, Matthieu Herrb wrote:
> On Mon, Jun 01, 2020 at 03:28:52PM +0200, Stéphane Aulery wrote:
> > Hello,
> > 
> > Le 01/06/2020 14:55, Matthieu Herrb a écrit :
> > > 
> > > > 
> > > > (I have just tried with a test user with nothing configured besides
> > > > LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper
> > > > characters)
> > > 
> > > I'm using a real US keyboard with AltGr or the Menu Key (depending on
> > > the actual keyboard) set as Compose and typing full compose sequences
> > > to get diacritics. ieand so on.
> > 
> > I use a Bépo keyboard but this but
> > 
> > Your experience interests me. I use a Bépo keyboard but I plan to switch to
> > a QWERTY + compose keyboard like you do. I hope this will give better
> > compatibility between systems and less software config remapping.
> > 
> > I do not see how to configure this in console.
> 
> I'm only using this under X. the OpenBSD console is plain ASCII and
> has no support for for UTF8 characters, so no need to enter them.
> 
> To setup the right alt key as compose, you can either:
> 
> - run 'setxkbmap -option compose:ralt' somewhere in your session
>   startup script
> 
> - create /etc/X11/xorg.conf.d/90-keyboard.conf containing
> 
> --- Cut ---
> Section "InputClass"
> Identifier "Kbd"
> MatchDriver "kbd"
> Option "XkbOptions" "compose:ralt"
> EndSection
> --- Cut ---

I used to understand that shit back in xmodmap days.
I'll admit I'm completely lost with setxkbmap

Along the same lines, how can you simply disable caps lock ?



Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
On Mon, Jun 1, 2020 at 2:37 PM Mark Cave-Ayland
 wrote:
> Oh wow it looks great!

Totally. I was super impressed as well.

> I also have commit access to OpenBIOS so I can tidy that up
> and get it posted over on the OpenBIOS mailing list. Probably the main thing 
> is to
> figure out what to do if the specified word doesn't exist. I'll also try and 
> find a
> few mins to fire up my Mac Mini to see if it exists there to work out if it 
> should be
> restricted to SPARC only.
>
> Note that I did my last merge a few days ago so it will be a little while 
> before it
> hits QEMU git master, but I can certainly get it added in time for the next 
> official
> QEMU release.

Oh, whoops, I just sent it to qemu-devel. Feel free to discard that
and commit it to the proper place. Given your forth chops, it makes
sense that you're in fact an OpenBIOS committer. :)

Jason



Re: sparc64 boot issue on qemu

2020-06-01 Thread Mark Cave-Ayland
On 01/06/2020 21:08, Jason A. Donenfeld wrote:

> On Mon, Jun 1, 2020 at 1:54 PM Mark Cave-Ayland
>  wrote:
>>
>> On 01/06/2020 08:23, Jason A. Donenfeld wrote:
>>
>>> On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
>>>  wrote:

 AFAICT the problem here is the Forth being used at
 https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511: 
 since the
 addr word isn't part of the IEEE-1275 specification, it is currently 
 unimplemented in
 OpenBIOS.
>>>
>>> Actually, it looks to me like after this line runs:
>>>
>>> OF_interpret("stdout @ is my-self "
>>> "addr char-height addr char-width "
>>> "addr window-top addr window-left",
>>> 4, , , , );
>>>
>>> windowleft and windowtop contain legit addresses, but romwidth and
>>> romheight have garbage in them. It might be possible to chalk this up
>>> to bogus QEMU firmware, in which case, whatever.
>>
>> Sadly I think that's more due to luck than anything else. If you have a 
>> working boot
>> loader then can you try booting qemu-system-sparc64 with -prom-env 
>> 'auto-boot?=false'
>> and then entering the following definition of addr at the Forth prompt:
>>
>> : addr
>>   parse-word $find if
>> cell +
>>   then
>> ;
>>
>> followed by:
>>
>> boot
>>
>> That should give you a definition of addr that will return the address of a 
>> value
>> type in Forth.
> 
> Wow, that's magic, and works perfectly:
> https://data.zx2c4.com/openbsd-qemu-sparc64-pretty-vga-with-serif-font.png
> Pretty font too.
> 
> It sounds like the issue we're facing here is that the addr function
> is missing from QEMU's firmware? Would it be quasi interesting to
> remove use of it from OpenBSD? Or should we take this over to QEMU
> instead and get it implemented?

Oh wow it looks great! I also have commit access to OpenBIOS so I can tidy that 
up
and get it posted over on the OpenBIOS mailing list. Probably the main thing is 
to
figure out what to do if the specified word doesn't exist. I'll also try and 
find a
few mins to fire up my Mac Mini to see if it exists there to work out if it 
should be
restricted to SPARC only.

Note that I did my last merge a few days ago so it will be a little while 
before it
hits QEMU git master, but I can certainly get it added in time for the next 
official
QEMU release.


ATB,

Mark.



Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
On Mon, Jun 1, 2020 at 2:08 PM Jason A. Donenfeld  wrote:
>
> Hi Mark,
>
> On Mon, Jun 1, 2020 at 1:54 PM Mark Cave-Ayland
>  wrote:
> >
> > On 01/06/2020 08:23, Jason A. Donenfeld wrote:
> >
> > > On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
> > >  wrote:
> > >>
> > >> AFAICT the problem here is the Forth being used at
> > >> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511:
> > >>  since the
> > >> addr word isn't part of the IEEE-1275 specification, it is currently 
> > >> unimplemented in
> > >> OpenBIOS.
> > >
> > > Actually, it looks to me like after this line runs:
> > >
> > > OF_interpret("stdout @ is my-self "
> > > "addr char-height addr char-width "
> > > "addr window-top addr window-left",
> > > 4, , , , );
> > >
> > > windowleft and windowtop contain legit addresses, but romwidth and
> > > romheight have garbage in them. It might be possible to chalk this up
> > > to bogus QEMU firmware, in which case, whatever.
> >
> > Sadly I think that's more due to luck than anything else. If you have a 
> > working boot
> > loader then can you try booting qemu-system-sparc64 with -prom-env 
> > 'auto-boot?=false'
> > and then entering the following definition of addr at the Forth prompt:
> >
> > : addr
> >   parse-word $find if
> > cell +
> >   then
> > ;
> >
> > followed by:
> >
> > boot
> >
> > That should give you a definition of addr that will return the address of a 
> > value
> > type in Forth.
>
> Wow, that's magic, and works perfectly:
> https://data.zx2c4.com/openbsd-qemu-sparc64-pretty-vga-with-serif-font.png
> Pretty font too.
>
> It sounds like the issue we're facing here is that the addr function
> is missing from QEMU's firmware? Would it be quasi interesting to
> remove use of it from OpenBSD? Or should we take this over to QEMU
> instead and get it implemented?

I just sent a patch up to qemu-devel. We'll see what they think. You
should be CC'd on it.
https://lore.kernel.org/qemu-devel/20200601203143.93424-1-ja...@zx2c4.com/

Last nit would be figuring out how to prevent it from prompting me for
"root device: ", "swap device: ", but I'm guessing that's just some
prom variable or partition label I need to fiddle with, rather than a
real bug worthy of this list.

Jason



Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
Hi Mark,

On Mon, Jun 1, 2020 at 1:54 PM Mark Cave-Ayland
 wrote:
>
> On 01/06/2020 08:23, Jason A. Donenfeld wrote:
>
> > On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
> >  wrote:
> >>
> >> AFAICT the problem here is the Forth being used at
> >> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511: 
> >> since the
> >> addr word isn't part of the IEEE-1275 specification, it is currently 
> >> unimplemented in
> >> OpenBIOS.
> >
> > Actually, it looks to me like after this line runs:
> >
> > OF_interpret("stdout @ is my-self "
> > "addr char-height addr char-width "
> > "addr window-top addr window-left",
> > 4, , , , );
> >
> > windowleft and windowtop contain legit addresses, but romwidth and
> > romheight have garbage in them. It might be possible to chalk this up
> > to bogus QEMU firmware, in which case, whatever.
>
> Sadly I think that's more due to luck than anything else. If you have a 
> working boot
> loader then can you try booting qemu-system-sparc64 with -prom-env 
> 'auto-boot?=false'
> and then entering the following definition of addr at the Forth prompt:
>
> : addr
>   parse-word $find if
> cell +
>   then
> ;
>
> followed by:
>
> boot
>
> That should give you a definition of addr that will return the address of a 
> value
> type in Forth.

Wow, that's magic, and works perfectly:
https://data.zx2c4.com/openbsd-qemu-sparc64-pretty-vga-with-serif-font.png
Pretty font too.

It sounds like the issue we're facing here is that the addr function
is missing from QEMU's firmware? Would it be quasi interesting to
remove use of it from OpenBSD? Or should we take this over to QEMU
instead and get it implemented?

Jason



Re: sparc64 boot issue on qemu

2020-06-01 Thread Mark Cave-Ayland
On 01/06/2020 08:23, Jason A. Donenfeld wrote:

> On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
>  wrote:
>>
>> AFAICT the problem here is the Forth being used at
>> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511: 
>> since the
>> addr word isn't part of the IEEE-1275 specification, it is currently 
>> unimplemented in
>> OpenBIOS.
> 
> Actually, it looks to me like after this line runs:
> 
> OF_interpret("stdout @ is my-self "
> "addr char-height addr char-width "
> "addr window-top addr window-left",
> 4, , , , );
> 
> windowleft and windowtop contain legit addresses, but romwidth and
> romheight have garbage in them. It might be possible to chalk this up
> to bogus QEMU firmware, in which case, whatever.

Sadly I think that's more due to luck than anything else. If you have a working 
boot
loader then can you try booting qemu-system-sparc64 with -prom-env 
'auto-boot?=false'
and then entering the following definition of addr at the Forth prompt:

: addr
  parse-word $find if
cell +
  then
;

followed by:

boot

That should give you a definition of addr that will return the address of a 
value
type in Forth.


ATB,

Mark.



Re: drop addtrust from cert.pem?

2020-06-01 Thread Theo Buehler
On Mon, Jun 01, 2020 at 06:04:17PM +0100, Stuart Henderson wrote:
> OK to drop the expired AddTrust cert from cert.pem?

Thanks for taking care of this (and for checking the firefox set). I see
no reason to keep it.

ok

> I checked against the firefox set, there are no new/removed certs that
> work with libressl there. There are now two with GENERALIZEDTIME notAfter
> dates from before 2050 that don't work though (I only remember seeing one
> of those when I last looked).. but that is a separate issue.
> 
> /C=EE/O=AS Sertifitseerimiskeskus/CN=EE Certification Centre Root 
> CA/emailAddress=p...@sk.ee
> /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum 
> Trusted Network CA 2

Ugh...



drop addtrust from cert.pem?

2020-06-01 Thread Stuart Henderson
OK to drop the expired AddTrust cert from cert.pem?

I checked against the firefox set, there are no new/removed certs that
work with libressl there. There are now two with GENERALIZEDTIME notAfter
dates from before 2050 that don't work though (I only remember seeing one
of those when I last looked).. but that is a separate issue.

/C=EE/O=AS Sertifitseerimiskeskus/CN=EE Certification Centre Root 
CA/emailAddress=p...@sk.ee
/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum 
Trusted Network CA 2


Index: cert.pem
===
RCS file: /cvs/src/lib/libcrypto/cert.pem,v
retrieving revision 1.20
diff -u -p -r1.20 cert.pem
--- cert.pem10 Apr 2020 12:13:17 -  1.20
+++ cert.pem1 Jun 2020 16:59:23 -
@@ -350,58 +350,6 @@ LysRJyU3eExRarDzzFhdFPFqSBX/wge2sY0PjlxQ
 LnPqZih4zR0Uv6CPLy64Lo7yFIrM6bV8+2ydDKXhlg==
 -END CERTIFICATE-
 
-### AddTrust AB
-
-=== /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
-Certificate:
-Data:
-Version: 3 (0x2)
-Serial Number: 1 (0x1)
-Signature Algorithm: sha1WithRSAEncryption
-Validity
-Not Before: May 30 10:48:38 2000 GMT
-Not After : May 30 10:48:38 2020 GMT
-Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, 
CN=AddTrust External CA Root
-X509v3 extensions:
-X509v3 Subject Key Identifier: 
-AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
-X509v3 Key Usage: 
-Certificate Sign, CRL Sign
-X509v3 Basic Constraints: critical
-CA:TRUE
-X509v3 Authority Key Identifier: 
-
keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
-DirName:/C=SE/O=AddTrust AB/OU=AddTrust External TTP 
Network/CN=AddTrust External CA Root
-serial:01
-
-SHA1 Fingerprint=02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68
-SHA256 
Fingerprint=68:7F:A4:51:38:22:78:FF:F0:C8:B1:1F:8D:43:D5:76:67:1C:6E:B2:BC:EA:B4:13:FB:83:D9:65:D0:6D:2F:F2
--BEGIN CERTIFICATE-
-MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
-MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
-IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
-MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
-FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
-bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
-dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
-H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
-uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
-mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
-a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
-E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
-WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
-VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
-Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
-cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
-IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
-AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
-YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
-6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
-Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
-c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
-mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
--END CERTIFICATE-
-
 ### AffirmTrust
 
 === /C=US/O=AffirmTrust/CN=AffirmTrust Commercial



Re: Xwindows keymap weirdness

2020-06-01 Thread Stuart Henderson
On 2020/06/01 15:56, Stéphane Aulery wrote:
> Le 01/06/2020 15:46, Matthieu Herrb a écrit :
> > On Mon, Jun 01, 2020 at 03:28:52PM +0200, Stéphane Aulery wrote:
> > > Le 01/06/2020 14:55, Matthieu Herrb a écrit :
> > > >
> > > > >
> > > > > (I have just tried with a test user with nothing configured besides
> > > > > LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper
> > > > > characters)
> > > >
> > > > I'm using a real US keyboard with AltGr or the Menu Key (depending on
> > > > the actual keyboard) set as Compose and typing full compose sequences
> > > > to get diacritics. ieand so on.
> > > 
> > > I use a Bépo keyboard but this but
> > > 
> > > Your experience interests me. I use a Bépo keyboard but I plan to
> > > switch to
> > > a QWERTY + compose keyboard like you do. I hope this will give better
> > > compatibility between systems and less software config remapping.
> > > 
> > > I do not see how to configure this in console.
> > 
> > I'm only using this under X. the OpenBSD console is plain ASCII and
> > has no support for for UTF8 characters, so no need to enter them.
> 
> This explains why I cannot enter accented characters through SSH. I can't
> edit a plain UTF-8 file remotely then... when the server has no X server
> running. Doh!

It doesn't matter if the server is running X or not, it is down to the
terminal used on the machine with the SSH client, and the setting for
LC_CTYPE.

By default ssh passes TERM to the server but not LC_CTYPE. You might
find it helpful to set "SendEnv LC_CTYPE" in .ssh/config on the client and
"AcceptEnv LC_CTYPE" in /etc/ssh/sshd_config on the server (some other OS
do this by default).



Re: userland clock_gettime proof of concept

2020-06-01 Thread Christian Weisgerber
Theo de Raadt:

> > Then you still need to check on every call whether the clockid has
> > changed (because the kern.timecounter.hardware sysctl was changed)
> > and refetch the function pointer in that case.
> 
> Then really, we should remove that sysctl support.
> 
> Because otherwise I don't see how it can work.  Aren't there deadlock
> or spinning conditions?  Or at minimum, situtions where time won't flow
> linearly.

The patch as-is works fine when kern.timecounter.hardware is toggled
back and forth between tsc with userland gettime support and, say,
acpihpet0 without.  tk_user marks whether the currently selected
timecounter has userland support, the wrapper checks that and falls
back to the system call.

Reading the code, I don't see a reason why this shouldn't work fine,
and experimentally it does work.  Changing kern.timecounter.hardware
is transparent.

kettenis@'s suggestion of extending this from on/off to
clockid1/clockid2/.../off makes sense to me.  Most architectures
will likely only have one timecounter for which userland support
is possible, but sparc64 has indeed two (tick, stick).

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: userland clock_gettime proof of concept

2020-06-01 Thread Theo de Raadt
Christian Weisgerber  wrote:

> On 2020-05-31, "Theo de Raadt"  wrote:
> 
> >> > particular timecounter type can be supported.  My proposal would be to
> >> > implement a function *on all architecture* that takes the clockid as
> >> > an argument and returns a pointer to the function that implements
> >> > support for that timecounter.  On architectures without support, ir
> >> > when called with a clockid that isn't supported, that function would
> >> > simply return NULL.
> >> 
> >> Sure. All architectures will register their clocks with a unique ID in
> >> timetc.h, right? And then we do clockfun[clockid]() in libc, right?
> >
> > No, don't do that on every call -- instead, get the function pointer once.
> 
> Then you still need to check on every call whether the clockid has
> changed (because the kern.timecounter.hardware sysctl was changed)
> and refetch the function pointer in that case.

Then really, we should remove that sysctl support.

Because otherwise I don't see how it can work.  Aren't there deadlock
or spinning conditions?  Or at minimum, situtions where time won't flow
linearly.

All of that tweaking is junk working around bugs and incomplete software.



Re: Xwindows keymap weirdness

2020-06-01 Thread Christian Weisgerber
Marc Espie:

> If I type 'c
> 
> I get a ç  in programs like firefox or chrome, BUT I get
> ć   in xterm ?
> 
> why are things different ? which program is right ?

GTK comes with its own compose rules that are occasionally different
from the default X11 ones.

Personally, I disable GTK's compose processing with GTK_IM_MODULE=xim.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: userland clock_gettime proof of concept

2020-06-01 Thread Christian Weisgerber
On 2020-05-31, "Theo de Raadt"  wrote:

>> > particular timecounter type can be supported.  My proposal would be to
>> > implement a function *on all architecture* that takes the clockid as
>> > an argument and returns a pointer to the function that implements
>> > support for that timecounter.  On architectures without support, ir
>> > when called with a clockid that isn't supported, that function would
>> > simply return NULL.
>> 
>> Sure. All architectures will register their clocks with a unique ID in
>> timetc.h, right? And then we do clockfun[clockid]() in libc, right?
>
> No, don't do that on every call -- instead, get the function pointer once.

Then you still need to check on every call whether the clockid has
changed (because the kern.timecounter.hardware sysctl was changed)
and refetch the function pointer in that case.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Xwindows keymap weirdness

2020-06-01 Thread Stéphane Aulery

Le 01/06/2020 15:46, Matthieu Herrb a écrit :

On Mon, Jun 01, 2020 at 03:28:52PM +0200, Stéphane Aulery wrote:

Le 01/06/2020 14:55, Matthieu Herrb a écrit :
>
> >
> > (I have just tried with a test user with nothing configured besides
> > LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper
> > characters)
>
> I'm using a real US keyboard with AltGr or the Menu Key (depending on
> the actual keyboard) set as Compose and typing full compose sequences
> to get diacritics. ieand so on.

I use a Bépo keyboard but this but

Your experience interests me. I use a Bépo keyboard but I plan to 
switch to

a QWERTY + compose keyboard like you do. I hope this will give better
compatibility between systems and less software config remapping.

I do not see how to configure this in console.


I'm only using this under X. the OpenBSD console is plain ASCII and
has no support for for UTF8 characters, so no need to enter them.


This explains why I cannot enter accented characters through SSH. I 
can't edit a plain UTF-8 file remotely then... when the server has no X 
server running. Doh!





What are the pitfalls?


I don't know. I've a number of things in mind, but I'm not sure
they're relevant. The existing Compose rules allow me to enter all
important UTF-8 characters I need outside of ASCII: French diacritics,
non-breaking spaces, median point, Euro sign, etc.

Oh yes: one issue: I almost never test non default keyboard layouts in
Xenocara because of this (no /etc/kbdtype file on my OpenBSD machines)
:)


Ok, thanks.

--
Stéphane Aulery



Re: Xwindows keymap weirdness

2020-06-01 Thread Matthieu Herrb
On Mon, Jun 01, 2020 at 03:28:52PM +0200, Stéphane Aulery wrote:
> Hello,
> 
> Le 01/06/2020 14:55, Matthieu Herrb a écrit :
> > 
> > > 
> > > (I have just tried with a test user with nothing configured besides
> > > LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper
> > > characters)
> > 
> > I'm using a real US keyboard with AltGr or the Menu Key (depending on
> > the actual keyboard) set as Compose and typing full compose sequences
> > to get diacritics. ieand so on.
> 
> I use a Bépo keyboard but this but
> 
> Your experience interests me. I use a Bépo keyboard but I plan to switch to
> a QWERTY + compose keyboard like you do. I hope this will give better
> compatibility between systems and less software config remapping.
> 
> I do not see how to configure this in console.

I'm only using this under X. the OpenBSD console is plain ASCII and
has no support for for UTF8 characters, so no need to enter them.

To setup the right alt key as compose, you can either:

- run 'setxkbmap -option compose:ralt' somewhere in your session
  startup script

- create /etc/X11/xorg.conf.d/90-keyboard.conf containing

--- Cut ---
Section "InputClass"
Identifier "Kbd"
MatchDriver "kbd"
Option "XkbOptions" "compose:ralt"
EndSection
--- Cut ---

> 
> What are the pitfalls?

I don't know. I've a number of things in mind, but I'm not sure
they're relevant. The existing Compose rules allow me to enter all
important UTF-8 characters I need outside of ASCII: French diacritics,
non-breaking spaces, median point, Euro sign, etc.

Oh yes: one issue: I almost never test non default keyboard layouts in
Xenocara because of this (no /etc/kbdtype file on my OpenBSD machines)
:)

-- 
Matthieu Herrb



Re: Xwindows keymap weirdness

2020-06-01 Thread Stéphane Aulery

Hello,

Le 01/06/2020 14:55, Matthieu Herrb a écrit :




(I have just tried with a test user with nothing configured besides
LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper 
characters)


I'm using a real US keyboard with AltGr or the Menu Key (depending on
the actual keyboard) set as Compose and typing full compose sequences
to get diacritics. ieand so on.


I use a Bépo keyboard but this but

Your experience interests me. I use a Bépo keyboard but I plan to switch 
to a QWERTY + compose keyboard like you do. I hope this will give better 
compatibility between systems and less software config remapping.


I do not see how to configure this in console.

What are the pitfalls?

--
Stéphane Aulery



Re: Xwindows keymap weirdness

2020-06-01 Thread Matthieu Herrb
On Mon, Jun 01, 2020 at 02:16:16PM +0200, Marc Espie wrote:
> I occasionnally use setxkbmap 'us(intl)' in order to have diacritics
> as dead keys.
> 
> I have LC_CTYPE=en_US.UTF-8
> 
> If I type 'c
> 
> I get a ç  in programs like firefox or chrome, BUT I get
> ć   in xterm ?
> 
> why are things different ?

Because firefox or chrome probably don't use
/usr/X11R6/share/X11/locale/en_US.UTF-8/Compose (the rules used by
Xlib) but their own Compose rules. I don't know if there is some other
"standard" toolkit (gtk+3?) providing alternative rules or if they
just hard-code their own rules somewhere.

> which program is right ?

There may be  an international standard (ISO, XDG, ... ?) that
controls those rules and  what X.Org is shipping in
/usr/X11R6/share/X11/locale/en_US.UTF-8/Compose But I can't find a
reference.

So I would say that xterm is right: the compose sequence for ç is
,c. And as you got it there is a ć character in some alphabets
reachable with 'c or  ' c

You  have a  key in the default us(intl) XKB
layout (it's on the the 4th group for the '5' key) but I don't
remember how to reach that group :)

> 
> (I have just tried with a test user with nothing configured besides
> LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper characters)

I'm using a real US keyboard with AltGr or the Menu Key (depending on
the actual keyboard) set as Compose and typing full compose sequences
to get diacritics. ieand so on.


-- 
Matthieu Herrb



Xwindows keymap weirdness

2020-06-01 Thread Marc Espie
I occasionnally use setxkbmap 'us(intl)' in order to have diacritics
as dead keys.

I have LC_CTYPE=en_US.UTF-8

If I type 'c

I get a ç  in programs like firefox or chrome, BUT I get
ć   in xterm ?

why are things different ? which program is right ?

(I have just tried with a test user with nothing configured besides
LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper characters)



Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
On Sun, May 31, 2020 at 7:22 AM Otto Moerbeek  wrote:
> Thanks, the following works indeed.
>
> -Otto
>
> Index: bootblk.fth
> ===
> RCS file: /cvs/src/sys/arch/sparc64/stand/bootblk/bootblk.fth,v
> retrieving revision 1.9
> diff -u -p -r1.9 bootblk.fth
> --- bootblk.fth 2 Apr 2020 06:06:22 -   1.9
> +++ bootblk.fth 31 May 2020 13:17:25 -
> @@ -716,7 +716,8 @@ create cur-blockno -1 l, -1 l,  \ Curren
>  2drop
>  ;
>
> -" load-base " evaluate constant loader-base
> +\\ Do not overwrite bootblocks
> +" load-base " evaluate 2000 + constant loader-base
>
>  : load-file-signon ( load-file len boot-path len -- load-file len boot-path 
> len )
> ." Loading file" space 2over type cr ." from device" space 2dup type cr

I can confirm that this enabled -current to boot now perfectly, so in
case it helps:

OK zx2c4@



Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
 wrote:
>
> AFAICT the problem here is the Forth being used at
> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511: 
> since the
> addr word isn't part of the IEEE-1275 specification, it is currently 
> unimplemented in
> OpenBIOS.

Actually, it looks to me like after this line runs:

OF_interpret("stdout @ is my-self "
"addr char-height addr char-width "
"addr window-top addr window-left",
4, , , , );

windowleft and windowtop contain legit addresses, but romwidth and
romheight have garbage in them. It might be possible to chalk this up
to bogus QEMU firmware, in which case, whatever.

Jason



Re: ospfctl json support

2020-06-01 Thread Richard Chivers
Hi,

Just a quick bump, wondering if someone could take a look at the diff,
conscious there appears to have been a lot going on recently!

I want to do some more detailed work on the json output, but would
ideally get this first iteration in first.

Richard

On Sat, May 23, 2020 at 9:28 AM Richard Chivers  wrote:
>
> Hi,
>
> I have attached the first iteration of the ospf json support. Sorry
> about the large commit,
> but it had to come in one go, if we didn't want a broken implementation.
>
> I will go back and update output.c and output_json.c to remove the detail flag
> and instead pass through the cli parse_result as is done in bgpctl -j sh rib,
> but thought it made sense to get the main commit out of the way and
> then circle back
> to these tweaks next week.
>
> In general I think there should be a consideration over how times are output.
>
> At present this diff outputs time using the pretty standard approach
> used in ospfctl all along,
> which is also what bgpctl -j sh rib does.
>
> I question whether for durations and uptime we should perhaps
> introduce something like
>
> uptime_seconds: 30
> uptime_seconds: null
>
> as well as or rather than:
>
> uptime: "6d06h31m"
> uptime: "00:00:00"
>
> I'm not sure if the above is a standard format (6d06h31m) that can be parsed
> easily in many languages, which is part of what json support adds to the mix,
> if it is then it is the best of both worlds already!
>
> I can take a dig into this, but i'm sure someone will know off hand,
> if so what is the RFC or equiv?
>
> The only aspects I have not tested are:
>
> ospfctl -j show database summary
> ospfctl -j show database opaque
>
> These have no results in my configuration.
>
> I do question wheter ospfctl -j show database summary just needs removing?
> I will perhaps have a dig into ospfd and see what generates the relevant imsg.