OpenBSD Errata: August 11, 2021 (perl)

2021-08-10 Thread Sebastian Benoit
An errata patch for perl has been released for OpenBSD 6.9.

perl(1) Encode (3p) loads a module from an incorrect relative path.

Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility.  Source code patches can be found on the
respective errata page:

  https://www.openbsd.org/errata69.html



OpenBSD Errata: August 11, 2021 (kernel)

2021-08-10 Thread Sebastian Benoit
An errata patch for the kernel has been released for OpenBSD 6.8 and
OpenBSD 6.9.

In a specific configuration, wg(4) leaked mbufs.

Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility.  Source code patches can be found on the
respective errata page:

  https://www.openbsd.org/errata68.html
  https://www.openbsd.org/errata69.html



scp: tweak man page for -3 by default

2021-08-10 Thread Christian Weisgerber
scp: tweak documentation and error message for -3 by default
 
Now that the -3 option is enabled by default, flip the documentation
and an error message from "requires -3" to "blocked by -R".

OK?
 
diff 453220bf36dcff10addeceb44e98f71bfeddcd53 
f457be8f3b007fb662dd10fb565ab79b602109f5
blob - 972269af7f61d7643a68fbcfa1e7a6a9b7d207e1
blob + b8d969ef781d4ef665f82dbc1a10d20e0da6e307
--- usr.bin/ssh/scp.1
+++ usr.bin/ssh/scp.1
@@ -67,10 +67,10 @@ as host specifiers.
 .Pp
 When copying between two remote hosts, if the URI format is used, a
 .Ar port
-may only be specified on the
+cannot be specified on the
 .Ar target
 if the
-.Fl 3
+.Fl R
 option is used.
 .Pp
 The options are as follows:
@@ -260,7 +260,7 @@ The program must understand
 options.
 .It Fl s
 Use the SFTP protocol for file transfers instead of the legacy SCP protocol.
-Using SFTP provides avoids invoking a shell on the remote side and provides
+Using SFTP avoids invoking a shell on the remote side and provides
 more predictable filename handling, as the SCP protocol
 relied on the remote shell for expanding
 .Xr glob 3
blob - ce133d87af2fff873e3202cecde7d91c6c94171f
blob + 7ee66c26bce50a4bf6e0132fddb41a7850f26e83
--- usr.bin/ssh/scp.c
+++ usr.bin/ssh/scp.c
@@ -1063,7 +1063,7 @@ toremote(int argc, char **argv, enum scp_mode_e mode, 
if (tport != -1 && tport != SSH_DEFAULT_PORT) {
/* This would require the remote support URIs */
fatal("target port not supported with two "
-   "remote hosts without the -3 option");
+   "remote hosts and the -R option");
}
 
freeargs();

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



Re: ssh match.c: Remove always true condition

2021-08-10 Thread Martin Vahlensieck
Ping, diff reattached with extra context for easier review.

On Wed, Jul 21, 2021 at 12:10:31PM +0200, Martin Vahlensieck wrote:
> Hi
> 
> After the last commit where consecutive `*' are folded, *pattern is
> never '*' here.
> 
> Best,
> 
> Martin
> 
> Index: match.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/match.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 match.c
> --- match.c   3 Nov 2020 22:53:12 -   1.43
> +++ match.c   21 Jul 2021 09:59:59 -
> @@ -69,7 +69,7 @@ match_pattern(const char *s, const char 
>   return 1;
>  
>   /* If next character in pattern is known, optimize. */
> - if (*pattern != '?' && *pattern != '*') {
> + if (*pattern != '?') {
>   /*
>* Look instances of the next character in
>* pattern, and try to match starting from
> 

Index: match.c
===
RCS file: /cvs/src/usr.bin/ssh/match.c,v
retrieving revision 1.43
diff -u -p -U12 -r1.43 match.c
--- match.c 3 Nov 2020 22:53:12 -   1.43
+++ match.c 10 Aug 2021 14:31:45 -
@@ -60,25 +60,25 @@ match_pattern(const char *s, const char 
return !*s;
 
if (*pattern == '*') {
/* Skip this and any consecutive asterisks. */
while (*pattern == '*')
pattern++;
 
/* If at end of pattern, accept immediately. */
if (!*pattern)
return 1;
 
/* If next character in pattern is known, optimize. */
-   if (*pattern != '?' && *pattern != '*') {
+   if (*pattern != '?') {
/*
 * Look instances of the next character in
 * pattern, and try to match starting from
 * those.
 */
for (; *s; s++)
if (*s == *pattern &&
match_pattern(s + 1, pattern + 1))
return 1;
/* Failed. */
return 0;
}



Re: snmpd: allow sending traps with SNMPv3

2021-08-10 Thread Martijn van Duren
On Mon, 2021-08-09 at 21:44 +0200, Martijn van Duren wrote:
> On Tue, 2021-07-27 at 21:28 +0200, Martijn van Duren wrote:
> > This diff allows sending traps in SNMPv3 messages.
> > It defaults to the global seclevel, but it can be specified on a per
> > rule basis.
> > 
> > Diff requires both previous setting engineid and ober_dup diff.
> > 
> > Tested with netsnmp's snmptrapd and my WIP diff.
> > 
> > The other 2 outstanding diffs are for receiving SNMPv3 traps.
> > 
> > OK?
> > 
> > martijn@
> > 
> Resending now that the engineid diff is in.
> 
> Still awaiting the commit of ober_dup diff[0].
> 
> OK once that one goes in?
> 
> Also, rereading the diff, splitting the trap receiver in two might be a
> bit clutch. Once again invoking the manpage gurus.
> 
> martijn@
> 
> [0] https://marc.info/?l=openbsd-tech=162698527126249=2
> 
The listen on diff committed this morning broke this patch.
Updated version

In case someone wants a quick example of how to test this:
$ cat snmpd.conf
trap receiver 127.0.0.1 user test
user test authkey test1234 auth hmac-sha256 enckey test1234 enc aes
$ doas ./snmpd -df snmpd.conf  
startup
snmpe: listening on udp 0.0.0.0:161
snmpe: listening on udp :::161
snmpe 800075cb81afa75034471524f4b8c3608f47d7f5dff8f28584e99f87d8854128: ready
^C
$ doas cat /etc/snmp/snmptrapd.conf
snmpTrapdAddr 127.0.0.1
createUser -e 
0x800075cb81afa75034471524f4b8c3608f47d7f5dff8f28584e99f87d8854128 test SHA256 
test1234 AES test1234
authUser log test
$ doas snmptrapd -fLe &
[1] 72884
trapd> NET-SNMP version 5.9
$ doas ./snmpd -df snmpd.conf
snmpd> startup
snmpd> snmpe: listening on udp 0.0.0.0:161
snmpd> snmpe: listening on udp :::161
snmpd> snmpe 800075cb81afa75034471524f4b8c3608f47d7f5dff8f28584e99f87d8854128: 
ready
trapd> 2021-08-10 12:50:21 localhost [UDP: [127.0.0.1]:42772->[0.0.0.0]:0]:
trapd> SNMPv2-MIB::sysUpTime.0 = Timeticks: (2) 0:00:00.02 
SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::coldStart.0

Don't forget to replace my engineid with your personal one in snmptrapd.conf.

martijn@

Index: parse.y
===
RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
retrieving revision 1.66
diff -u -p -r1.66 parse.y
--- parse.y 10 Aug 2021 06:49:33 -  1.66
+++ parse.y 10 Aug 2021 10:57:36 -
@@ -134,11 +134,11 @@ typedef struct {
 %token HANDLE DEFAULT SRCADDR TCP UDP PFADDRFILTER PORT
 %token   STRING
 %token   NUMBER
-%typehostcmn
+%typeusmuser community optcommunity
 %typelistenproto listenflag listenflags
 %typesrcaddr port
 %typeoptwrite yesno seclevel
-%type  objtype cmd
+%type  objtype cmd hostauth hostauthv3 usmauthopts usmauthopt
 %type   oid hostoid trapoid
 %type  auth
 %type   enc
@@ -243,13 +243,13 @@ main  : LISTEN ON listen_udptcp
free($3);
}
| TRAP RECEIVER host
-   | TRAP HANDLE hostcmn trapoid cmd {
-   struct trapcmd *cmd = $5.data;
+   | TRAP HANDLE trapoid cmd {
+   struct trapcmd *cmd = $4.data;
 
-   cmd->cmd_oid = $4;
+   cmd->cmd_oid = $3;
 
if (trapcmd_add(cmd) != 0) {
-   free($4);
+   free($3);
free(cmd);
yyerror("duplicate oid");
YYERROR;
@@ -268,8 +268,8 @@ main: LISTEN ON listen_udptcp
| PFADDRFILTER yesno{
conf->sc_pfaddrfilter = $2;
}
-   | SECLEVEL seclevel {
-   conf->sc_min_seclevel = $2;
+   | seclevel {
+   conf->sc_min_seclevel = $1;
}
| USER STRING   {
const char *errstr;
@@ -701,15 +701,93 @@ hostoid   : /* empty */   
{ $$ = NULL; }
| OBJECTID oid  { $$ = $2; }
;
 
-hostcmn: /* empty */   { $$ = NULL; }
-   | COMMUNITY STRING  { $$ = $2; }
+usmuser: USER STRING   {
+   if (strlen($2) > SNMPD_MAXUSERNAMELEN) {
+   yyerror("User name too long: %s", $2);
+   free($2);
+   YYERROR;
+   }
+   $$ = $2;
+   }
+   ;
+
+community  : COMMUNITY STRING  {
+   if (strlen($2) > SNMPD_MAXCOMMUNITYLEN) {
+   yyerror("Community too long: %s", $2);
+   free($2);
+   

Re: [patch] Preserve keymap adjustments on suspend/resume

2021-08-10 Thread ropers
Would this also preserve the LED status (Num, Scroll Lock, etc.)?

(I'm nobody important and probably can't help, but I'm curious.)

Thanks and regards,
Ian


On 09/08/2021, Sergii Rudchenko  wrote:
> Pardon my impatience -- I am a newbie and I don't really know what
> should happen next (if anything?). I have skipped any introduction from
> my original email, imitating the communication style in this list --
> straight to the point and because it was already long.
>
> Although this is my first patch to OpenBSD I am familiar with inner
> workings of operating systems from few books[1] and commercial
> development of a driver for Windows (CE and NT) back in 2005.  Thanks to
> the very clear organization of OpenBSD code it is a pleasure to study
> and figure things out.
>
> I have spent a week on massaging this problem, discovering corner cases,
> testing and ironing out regressions. I did my best to keep the patch at
> minimum while retaining correctness and clarity. Some changes like the
> move of t_keymap field (apart from the change of type) were done to
> re-align it with NetBSD. I was in doubt about locking, but tracing the
> path of ioctl handling I have not found anything preventing two CPU
> cores from executing wskbd ioctls in parallel on amd64 (and it is a
> NOLOCK syscall). In fact, now I wonder why wskbd_softc is not protected.
>
> Now a little bit on the motivation...
>
> My current day job does not involve system programming anymore and I
> miss it often. Also, with kids growing up I feel I can afford to
> contribute to important open projects with my experience and skills.  I
> fiddle with OpenBSD for a long time and I admire how simple, stable and
> well-documented it is. In our age of pervasive electronic waste, robust
> software often makes a difference between a useful computer and garbage.
>
> I realize that changes in wscons related to custom keymaps and USB
> keyboards is something of little priority.  Nevertheless, this is one
> annoying thing I randomly picked up and got to the bottom of it on my
> short staycation and it was a sufficiently low entry barrier. I hope
> it may be useful for other OpenBSD users, especially on laptop computers
> which may not have a USB keyboard connected yet at boot time.
>
> My longer-term aspiration is extending and maintaining hardware
> support, especially on ARM (I own a Pinebook Pro and few RPis).
>
> I would appreciate a bit of guidance or feedback.
>
>
> Best regards,
> Sergii Rudchenko
>
> [1] Of which the most prominent are:
> - "Modern Operating Systems (3rd edition)" by Andrew S. Tannenbaum
> - "The Design And Implementation Of The Freebsd Operating System"
> by Marshall Kirk McKusick and George V. Neville-Neil
> - "Linux Kernel Development (2nd edition)" by Robert Love
>
> P.S. Sorry for the git patch with a prefix, I came across
> https://www.openbsd.org/faq/faq5.html#Diff too late. As far I understand
> it should be fine with -p1
>
>