Re: [PermitRootLogin - installer vs sshd defaults]

> 1. Shouldn't the installer's suggested default answers reflect the > defaults on the system, and if not, why? > > 2. Shouldn't PermitRootLogin default settings be synchronised as per the > above, and if not, why? OpenSSH is also used by lots of downstream groups. It has defaults. The OpenBSD

Re: octeon usb devs

On Tue, Jan 12, 2016 at 11:44:48PM +0200, Artturi Alm wrote: > Likely some other configs have more exhaustive list of devices supported, > but even these would be great to have, especially uhub* at uhub?, > as ERL physically has only one port limiting it's use to a single umass. > > -Artturi

gre, pf and overworking

Dear Tech Reader, Maybe this would be misc but i am trying to avoid some useless answer. This is openbsd 5.8 patched ( -r OPENBSD_5_8 ) All my block rule log. Nothing appear in tcpdump -teni pflog0 But pf drop packet (set skip or pfctl -d) solve problem. [0]-[blue]-[/cloudgate] # ping -c2 -w2

Re: Checking MAC address of incoming unicast packets

On Mon, 4 Jan 2016, Stefan Fritsch wrote: > On Sun, 3 Jan 2016, Theo de Raadt wrote: > > >> dlg writes: > > >> > should we just do it unconditionally? is there a downside to that? > > > > > >It may decrease performance a tiny bit. Since such bits tend to add > > >up, I would be hesitant to enable

[PermitRootLogin - installer vs sshd defaults]

Ping. - Forwarded message from Raf Czlonka - Date: Sat, 12 Dec 2015 22:19:01 + User-Agent: Mutt/1.5.24 (2015-08-30) From: Raf Czlonka To: tech@openbsd.org Subject: PermitRootLogin - installer vs sshd defaults Hi all, In April, sshd(8)'s

Important SSH patch coming soon

Important SSH patch coming soon. For now, every on all operating systems, please do the following: Add undocumented "UseRoaming no" to ssh_config or use "-oUseRoaming=no" to prevent upcoming #openssh client bug CVE-2016-0777. More later.

Request for testing: amd64 interrupt acknowledgement issue

Hi, After some extensive hair pulling by OpenBSD developers and discussions with friendly folks at Microsoft, we've come to a conclusion that the reason why Hyper-V legacy network controller doesn't work on OpenBSD is due to particularities in the low level interrupt acknowledgement code.

Re: gre, pf and overworking

On Thu, Jan 14, 2016 at 3:14 PM, sven falempin wrote: > > On Thu, Jan 14, 2016 at 1:08 PM, sven falempin > wrote: > >> Dear Tech Reader, >> Maybe this would be misc but i am trying to avoid some useless answer. >> This is openbsd 5.8 patched (

[patch] mg: Prevent out-of-bounds read when PATH="/:..."

I looked for more instances of the pattern that lead to reading one byte before an allocated buffer in which(1) when PATH begins with "/:". I found only one, in the function csexists() in usr.bin/mg/cscope.c. While at it, I replaced the manual length check before snprintf() with a check of the

Re: sys_pipe.c uiomove() conversion

pipe_write() has an orig_resid = uio->uio_resid(). So orig_resid better be a size_t also. Looks good otherwise. ok with the updated diff below? Index: kern/sys_pipe.c === RCS file: /cvs/src/sys/kern/sys_pipe.c,v retrieving revision

xhci fix

This should fix the problem various people reported when using urtwn(4) over xhci(4). This problem did not disappear but after iwm(4) got imported bugs@ reports stopped ;) It's a screw up in my initial understanding of the documentation. When a multiple-TRB transfer descriptor span the end of

Fix IWM_MAX_CMD_PAYLOAD_SIZE in iwm(4)

In iwm(4), IWM_MAX_PAYLOAD_SIZE needs to be at least one byte smaller. "IWM_MAX_CMD_PAYLOAD_SIZE + sizeof(struct iwm_cmdheader)" must be smaller than 4096, otherwise the payload length could get truncated to 0 in this assignment from iwm_send_cmd(), because 4096 doesn't fit into 12 bits:

Re: Make em(4) more mpsafe again

Juuso Lapinlampi partyvan.eu> writes: > > - * These parameters control when the driver calls the routine to reclaim > > - * transmit descriptors. > > + * Thise parameter controls the minimum number of available transmit > > + * descriptors needed before we attempt transmission of a packet. > >

Re: xhci fix

On 14/01/16(Thu) 22:14, Martin Pieuchot wrote: > This should fix the problem various people reported when using urtwn(4) > over xhci(4). This problem did not disappear but after iwm(4) got > imported bugs@ reports stopped ;) > > It's a screw up in my initial understanding of the documentation.

Re: [patch]: Small which(1) man page error

I think using _PATH_DEFPATH in the absence of PATH is better. - todd Index: Makefile === RCS file: /cvs/src/usr.bin/which/Makefile,v retrieving revision 1.8 diff -u -p -u -r1.8 Makefile --- Makefile15 Apr 2013 16:34:19 -

Re: [patch] which(1): out of bounds read

On Thu, 14 Jan 2016 01:28:02 +0100, Max Fillinger wrote: > If PATH starts with "/:", which(1) reads outside of allocated memory. > Maybe that caused the non-reproduceable coredump mentioned in [0]? Committed, thanks. - todd