Re: [patch] netcat: support --crlf

On Wed, 23 Aug 2023, Pietro Cerutti wrote: > Hi, > > here at FreeBSD, we vendor in your netcat with a few local modifications. > > I'm working on adding support to --crlf. I have a diff against the FreeBSD > version here: https://reviews.freebsd.org/D41489 > > I'd like this to be upstreamed.

Re: sshd: reduce preauth log verbosity

On Fri, 18 Aug 2023, Tobias Heider wrote: > Hi, > > I was looking at my authlog today and as expected on a server exposed on the > public internet it is filled with random scanners and brute force attacks. > One thing I noticed is that there is a lot of information we log multiple > times for

Re: ssh nits

On Thu, 9 Mar 2023, Darren Tucker wrote: > On Thu, 9 Mar 2023 at 02:09, joshua stein wrote: > > cppcheck found these, are they worth fixing? > > > > In the non-fail case, done is set to NULL and then free()d. > > free(NULL) is legal but maybe worth removing? > > ssh uses this pattern a lot,

Re: ssh-pkcs11.c: fix some error messages

On Tue, 7 Mar 2023, Theo Buehler wrote: > Some error messages don't match the function calls. There's still this > one that looks weird. Not sure what it should say to be helpful: > "unexpected ec signature length" perhaps? > > if (siglen < 64 || siglen > 132 || siglen % 2) { >

KRL 4/4: regression test for signing/verification

Hi, The final OpenSSH key revocation list (KRL) diff for now :) This extends the existing krl.sh regression test to exercise signing and verification. (This depends on the last two diffs) ok? Index: krl.sh === RCS file:

KRL 3/4: plumb in signing and verification to ssh-keygen

Hi, This is another OpenSSH key revocation list (KRL) change: to support KRL signing and verification in ssh-keygen(1). The KRL format has supported signing of KRLs and verification of KRL signatures for a long time, but there is currently no way to generate a signed KRL or check the signature

KRL 2/4: Refactor parsing and signature verification

Hi, This is the second of the OpenSSH key revocation list (KRL) diffs. This one refactors KRL parsing, and particularly signature verification. It splits the KRL parsing logic into three phases: signature verification, key trust verification and everything else. The idea is to make this easier

KRL 1/4: extension mechanism

Hi, This is the first of a few changes to krl.c and related code. This defines and implements an extension mechanism for KRLs. This takes the form of new (sub-)section types that contain named extensions. These may be flagged as "critical" which causes the KRL parser to treat them as

Re: openssh: update ed25519 and squash into a single file

On Fri, 13 Jan 2023, Damien Miller wrote: > Hi, > > Forewarning: this is a big, noisy diff. Also on Github at > https://github.com/djmdjm/openssh-wip/pull/18 > > This updates the ED25519 code to the latest version of SUPERCOP (20221122), > but the real motivatio

Re: libcbor v0.10.0

On Fri, 30 Dec 2022, Theo Buehler wrote: > On Fri, Dec 30, 2022 at 10:09:16AM +1100, Damien Miller wrote: > > This updates libcbor to upstream version v.0.10.0. This version includes > > clang15 header fixes and fixes a few memory leaks. Full release notes > > are at h

Re: clang 15 and zlib

On Wed, 28 Dec 2022, Todd C. Miller wrote: > OK millert@ as well. There is no point in trying to fix this locally > when upstream zlib will be changing it in the near(?) future. He committed to removing the K function declarations when C23 is finalised:

Re: OpenSSH and -current out-of-tree patched for ~C?

On Wed, 30 Nov 2022, Theo de Raadt wrote: > >> It allows a much tighter pledge in the client, so less attack surface > >> against a bad server. > > > >So it's to prevent a malicious SSH server from exploiting a client who > >choses to use ~C to open up the ssh> prompt and create or

Re: ssh-keygen(1): by default generate ed25519 key (instead of rsa)

I think it's time; RFC 8709 has been a thing for a couple of years now and a bit of gentle pressure is good. ok djm, but cc openssh@ so others can chime in -d On Sun, 6 Nov 2022, Job Snijders wrote: > Dear all, > > Support for using Ed25519 for server and user authentication was > introduced

ssh internal refactor

Hi, I just committed a fairly large refactoring of openssh's key handling code. It *should* be completely invisible, but if you notice any new problems then please let open...@openssh.com know. Thanks, Damien

Re: [PATCH] ssh: don't make the umask more permissive than the user has set

On Tue, 4 Oct 2022, Alex Henrie wrote: > Daniel Kahn Gillmor suggested this exact change on the openssh-unix-dev > mailing list in 2008, but I couldn't find any reply. [1] > > Ignoring the current umask makes it hard to fulfill the Defense > Information Systems Agency's Security Technical

Re: libfido2 update

On Sun, 28 Aug 2022, Stuart Henderson wrote: > On 2022/08/24 17:09, Damien Miller wrote: > > Hi, > > > > https://www.mindrot.org/misc/libfido2-1.11.0.diff contains an update > > for src/libfido2 from 1.8 to 1.11 (about 10 months of upstream > > development). >

Re: libfido2 update

On Wed, 24 Aug 2022, Damien Miller wrote: > Hi, > > https://www.mindrot.org/misc/libfido2-1.11.0.diff contains an update > for src/libfido2 from 1.8 to 1.11 (about 10 months of upstream > development). > > I've tested it with OpenSSH, which is the only thing in src/ t

libfido2 update

Hi, https://www.mindrot.org/misc/libfido2-1.11.0.diff contains an update for src/libfido2 from 1.8 to 1.11 (about 10 months of upstream development). I've tested it with OpenSSH, which is the only thing in src/ that uses it as well as compiling www/chromium and performing a FIDO login with it.

Re: ksh: PROMPT_COMMAND

On Thu, 4 Aug 2022, Christian Weisgerber wrote: > Damien Miller: > > > bash has a PROMPT_COMMAND that allows a command to be executed before > > each PS1 prompt is displayed. I've found this useful on occasion, so > > this is the same thing for ksh(1). > > PS1 is

ksh: PROMPT_COMMAND

Hi, bash has a PROMPT_COMMAND that allows a command to be executed before each PS1 prompt is displayed. I've found this useful on occasion, so this is the same thing for ksh(1). In particular, this allows PROMPT_COMMAND to be set to a user-defined shell function that can modify PS1, though it

Re: randomise arc4random() rekey interval

On Fri, 29 Jul 2022, Theo de Raadt wrote: > The question is what _rs_random_u32() will do when it calls > _rs_stir_if_needed(). > > There is one potential problem. lib/libcrypto/arc4random/*.h contains > portable wrappers for _rs_forkdetect(), which actually do things. > memset(rs, 0,

Re: randomise arc4random() rekey interval

On Thu, 28 Jul 2022, Damien Miller wrote: > On Wed, 27 Jul 2022, Theo de Raadt wrote: > > > + rs->rs_count += rekey_fuzz & (REKEY_BASE - 1); > > > > I mean, why not use % here > > Sure, that's reasonable.

Re: randomise arc4random() rekey interval

On Wed, 27 Jul 2022, Theo de Raadt wrote: > + rs->rs_count += rekey_fuzz & (REKEY_BASE - 1); > > I mean, why not use % here Sure, that's reasonable. > And then, set the default to a pow2. > > But if someone changes it to not pow2, it still works. > > The & is premature

Re: randomise arc4random() rekey interval

On Wed, 27 Jul 2022, Theo de Raadt wrote: > I love it. > > > +#define REKEY_BASE (1<<20) /* NB. *must* be a power of 2 */ > > Why insist on that? Because I need to do this later: + rs->rs_count += rekey_fuzz & (REKEY_BASE - 1); because we can't use arc4random_uniform() in this context.

randomise arc4random() rekey interval

Hi, arc4random() rekeys currently rekeys from the kernel every 1.6MB. It costs us almost nothing to make this interval non-deterministic, so let's do that. With the below it will rekey randomly somewhere between 1MB and 2MB. ok? Index: crypt/arc4random.c

Re: vsw.4: mention veb next to bridge

On Wed, 20 Jul 2022, Chris Cappuccio wrote: > Klemens Nanni [k...@openbsd.org] wrote: > > veb(4) works just fine in this setup, so don't give the impression only > > bridge(4) would work. > > In related items, is it time to tedu bridge(4) and vether(4) ? Is there > anything veb(4) and vport(4)

Re: Picky, but much more efficient arc4random_uniform!

On Wed, 18 May 2022, Otto Moerbeek wrote: > instrumenting the code to count the number of arc4random calls I see thsi: > > openbsd; elapsed = 2.835819; calls = 12340949 > bitmask; elapsed = 4.335576; calls = 17836216 > bitmask+reuse; elapsed = 3.710277; calls = 15245337 > > (this is a different

Re: Picky, but much more efficient arc4random_uniform!

On Tue, 17 May 2022, Raimo Niskanen wrote: > Why reinvent the wheel? > > Here is a pretty good walkthrough of established methods: > > https://www.pcg-random.org/posts/bounded-rands.html > > It sounds to me as if your suggested methor essentially is > "Bitmask with Rejection -- Apple's

Re: Picky, but much more efficient arc4random_uniform!

On Mon, 16 May 2022, Luke Small wrote: > Yeah, I see your point. > > I suppose it depends on how conservative you want to be and whether > you want to supply options to people like getchar_unlocked when it > isn’t essential. > > It could be made manually fork-safe if I could make a simple feature

Re: Picky, but much more efficient arc4random_uniform!

On Sat, 14 May 2022, Luke Small wrote: > Look at my code. I don’t even use a modulus operator. I perform hit and > miss with a random bitstream. > > How can I have a bias of something I don’t do? I return a bitstream which > meets the parameters of being a value less than the upper bound. Much

Re: Picky, but much more efficient arc4random_uniform!

On Sun, 15 May 2022, Luke Small wrote: > Do I really have to use specific terminology to make a point? > > I'm not educated enough on chacha20 enough to know whether, like I > pointed out, whether choosing 5 bits from the middle of (or even from > the tail end of one and the beginning of another)

Re: Reserved address behavior (alternate broadcast and 240/4)

On Wed, 4 May 2022, Seth David Schoen wrote: [snip] > Anyway, one thing we would like to propose that OpenBSD update is the > in_canforward treatment of 240/4 (former class E) addresses. Apparently > mainly as a result of proposals in 2008 to make these addresses more > usable, most OSes now no

Re: ssh: sshkey.c: reduce code duplication

On Wed, 4 May 2022, Martin Vahlensieck wrote: > Hi > > I noticed that sshkey_unshield_private contains a exact duplicate > of the code in private2_check_padding. So by pulling > private2_check_padding up, the code can be reused. Or is there > a reason for this split? Thanks - this has been

Re: ssh: channels.c: Fix comment and add a const

applied On Wed, 4 May 2022, Martin Vahlensieck wrote: > Hi > > channel_new no longer frees remote_name. So update the comment > accordingly. As remote_name is not modified, it can be const > as well. > > Best, > > Martin > > Index: channels.c >

Re: ssh: mux.c: mark argument as const

applied - thanks On Wed, 4 May 2022, Martin Vahlensieck wrote: > Index: mux.c > === > RCS file: /home/reposync/cvs/src/usr.bin/ssh/mux.c,v > retrieving revision 1.92 > diff -u -p -r1.92 mux.c > --- mux.c 11 Jan 2022 01:26:47

Re: Security support status of xnf(4) and xbf(4)

On Fri, 25 Mar 2022, Demi Marie Obenour wrote: > Linux’s netfront and blkfront drivers recently had a security > vulnerability (XSA-396) that allowed a malicious backend to potentially > compromise them. In follow-up audits, I found that OpenBSD’s xnf(4) > currently trusts the backend domain. I

Re: Mention Smart Battery Data Spec in smbus.h

without commenting on the substance of this change, it should definitely not be added to the copyright block On Fri, 4 Mar 2022, patrick keshishian wrote: > Hello, > > I took a wrong turn, and got interested in where the SMBATT_CMD_* > defines were sourced. > > Adding a reference to Smart

Re: ssh/sshd change in snaps

On Wed, 17 Nov 2021, Damien Miller wrote: > On Tue, 16 Nov 2021, Damien Miller wrote: > > > Another couple of fixes in tomorrow's snaps. One to avoid errors like: > > > > > channel 3: chan_read_failed for istate 3 > > > > Another avoids a situation wher

Re: ssh/sshd change in snaps

On Tue, 16 Nov 2021, Damien Miller wrote: > Another couple of fixes in tomorrow's snaps. One to avoid errors like: > > > channel 3: chan_read_failed for istate 3 > > Another avoids a situation where sshd could get stuck spinning on poll() > if it fails. > > (Bot

Re: ssh/sshd change in snaps

On Sat, 13 Nov 2021, Damien Miller wrote: > On Thu, 11 Nov 2021, Damien Miller wrote: > > > Hi, > > > > Snaps is now carrying a change to ssh/sshd that converts their > > mainloops from select(2) to poll/ppoll(2). This change should be > > completely trans

Re: ssh/sshd change in snaps

On Thu, 11 Nov 2021, Damien Miller wrote: > Hi, > > Snaps is now carrying a change to ssh/sshd that converts their > mainloops from select(2) to poll/ppoll(2). This change should be > completely transparent, but please be on the lookout for any weird > behaviour. Bugs in th

ssh/sshd change in snaps

Hi, Snaps is now carrying a change to ssh/sshd that converts their mainloops from select(2) to poll/ppoll(2). This change should be completely transparent, but please be on the lookout for any weird behaviour. Bugs in the revised mainloop are most likely to appear as crashes, hangs or ssh/sshd

Re: New hw.perfpolicy behavior

On Wed, 3 Nov 2021, Stuart Henderson wrote: > > See also https://en.wikichip.org/wiki/race-to-sleep - it's generally > > more energy efficient to run the CPU at full speed so it can finish its > > work faster and get back to a low-power state sooner > > So there's not really any point in doing

Re: New hw.perfpolicy behavior

On Tue, 2 Nov 2021, Theo de Raadt wrote: > Paul de Weerd wrote: > > > A recent commit by Theo changed the hw.perfpolicy behavior to always > > run at full speed when AC power is on. This means that my workstation > > (and servers, once I upgrade them) now consumes significantly more > > power,

Re: OpenSSH: RSA/SHA1 disabled by default

On Tue, 7 Sep 2021, Martijn van Duren wrote: > On Mon, 2021-08-30 at 10:08 +1000, Damien Miller wrote: > > Hi, > > > > RSA/SHA1, a.k.a the "ssh-rsa" signature type is now disabled by default > > in OpenSSH. > > > > While The SSH pr

snaps: scp uses SFTP protocol by default

Hi, Just letting you know that the snaps rolling out now have scp defaulting to use the SFTP protocol by default. We hope to keep this change in the next release, so please report any problems you encounter either here (tech@), to bugs@ or to openssh@. One thing to be aware of: copying to/from a

OpenSSH: RSA/SHA1 disabled by default

-- Date: Mon, 30 Aug 2021 09:53:10 From: Damien Miller To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2021/08/29 17:53:10 Modified files: usr.bin/ssh: myproposal.h Log

Re: ssh match.c: Remove always true condition

On Thu, 19 Aug 2021, Martin Vahlensieck wrote: > Ping. > > On Tue, Aug 10, 2021 at 04:33:52PM +0200, Martin Vahlensieck wrote: > > Ping, diff reattached with extra context for easier review. > > > > On Wed, Jul 21, 2021 at 12:10:31PM +0200, Martin Vahlensieck wrote: > > > Hi > > > > > > After

Re: scp(1) changes in snaps

On Fri, 6 Aug 2021, Christian Weisgerber wrote: > Damien Miller: > > > Just a head-up: snaps currently contain a set of changes[1] to > > make scp(1) use the SFTP protocol by default. > > > Please report any incompatibilities or bugs that you encounter here > >

scp(1) changes in snaps

Hi, Just a head-up: snaps currently contain a set of changes[1] to make scp(1) use the SFTP protocol by default. This has a number of advantages, mostly relating to the improved security that comes from avoiding the use of a protocol that shambled out of the 1980s (SCP/RCP). A certain amount in

ssh/sshd configuration parsing

Hi, I just committed some changes to ssh/sshd configuration parsing that have been in snaps for the last few days. These changes switch parsing from using a naive tokeniser to one that better follows shell-style rules for quoting and comments. This does make config parsing stricter in a number

Re: ssh: zap unused family parameter from ssh_connect_direct()

ok djm On Sun, 11 Oct 2020, Klemens Nanni wrote: > CVS log shows that the following commit removed usage of it: > > sshconnect.c > revision 1.241 > date: 2013/10/16 02:31:46; author: djm; state: Exp; lines: +29 -45; > Implement client-side hostname canonicalisation to

Re: sync libfido2 with upstream

On Mon, 17 Aug 2020, Damien Miller wrote: > On Mon, 10 Aug 2020, Damien Miller wrote: > > > Hi, > > > > This syncs libfido2 with the current state of upstream. It includes > > a few new APIs that I want to use in OpenSSH to improve FIDO token > > support (req

Re: sync libfido2 with upstream

On Mon, 10 Aug 2020, Damien Miller wrote: > Hi, > > This syncs libfido2 with the current state of upstream. It includes > a few new APIs that I want to use in OpenSSH to improve FIDO token > support (require-PIN and fixing some corner-case bugs around multiple > inserte

Re: Fwd: explicit_bzero vs. alternatives

On Mon, 10 Aug 2020, Amit Kulkarni wrote: > moving to tech@ > > -- Forwarded message - > From: Philipp Klaus Krause > Date: Mon, Aug 10, 2020 at 4:34 AM > Subject: explicit_bzero vs. alternatives > To: > > > OpenBSD has the explicit_bzero function to reliably (i.e. even if

sync libfido2 with upstream

Hi, This syncs libfido2 with the current state of upstream. It includes a few new APIs that I want to use in OpenSSH to improve FIDO token support (require-PIN and fixing some corner-case bugs around multiple inserted tokens). ok? (major crank for ABI change) Index: Makefile

sync libcbor to 0.7.0

Hi, This syncs lib/libcbor from our v0.5.0+patches to the released v0.7.0 AFAIK the changes are mostly inconsequential to the current uses in-tree (there is a stack exhaustion fix that is worth having), but being at an actual release rather than a frankenpatch will make future updates a bit

Re: ssh: Register tun channel cleanup callback when ExitOnForwardFailure is set

On Mon, 17 Feb 2020, Remi Pommarel wrote: > When remote side fails to create tun (e.g. tun device is already opened) > it notifies the client with an SSH2_MSG_CHANNEL_OPEN_FAILURE message and > channel is marked dead on client side. But because tun forward channel > is not an interactive channel

Add #define for RFC8622 IPTOS_DSCP_LE codepoint

Hi, This adds a #define for the "lower effort" DSCP code point specified by https://tools.ietf.org/html/rfc8622 People have asked to be able to use this OpenSSH for "don't care" traffic. ok? Index: sys/netinet/ip.h === RCS file:

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

On Fri, 24 Jan 2020, Stuart Henderson wrote: > That works - etc/rc.d/sshd diff to match as follows: > > Index: sshd > === > RCS file: /cvs/src/etc/rc.d/sshd,v > retrieving revision 1.5 > diff -u -p -r1.5 sshd > --- sshd 22 Jan

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

On Fri, 24 Jan 2020, Antoine Jacoutot wrote: > Great :-) > Ok aja committed, the proctitle looks like this now in case the rc scripts need further tweaking: $ pgrep -lf sshd 12844 sshd: /usr/sbin/sshd -f /etc/ssh/sshd_config [listener] 0 of 10-100 startups

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

On Thu, 23 Jan 2020, Damien Miller wrote: > On Thu, 23 Jan 2020, Damien Miller wrote: > > > What information would you like there? We could put the first N listen > > addrs in the proctitle if that would help. > > Maybe like this: > > 63817 ?? S0:00.05

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

On Thu, 23 Jan 2020, Damien Miller wrote: > On Wed, 22 Jan 2020, Stuart Henderson wrote: > > > On 2020/01/21 15:39, Damien Miller wrote: > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: d...@cvs.openbsd.org2020/01/

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

On Wed, 22 Jan 2020, Stuart Henderson wrote: > On 2020/01/21 15:39, Damien Miller wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57 > > > > Modified files: > > usr.bin/ssh: s

Re: GRE datagram socket support

On Wed, 22 Jan 2020, David Gwynne wrote: > Has anyone got an opinion on this? I am still interested in doing more > packet capture things on OpenBSD using GRE as a transport, and the idea > of maintaining this out of tree just makes me feel tired. This is cool. I don't spot any major problems

OpenSSH U2F/FIDO support in base

Hi, I just committed all the dependencies for OpenSSH security key (U2F) support to base and tweaked OpenSSH to use them directly. This means there will be no additional configuration hoops to jump through to use U2F/FIDO2 security keys. Hardware backed keys can be generated using "ssh-keygen -t

Re: tcpdump(8) mention USB interfaces in -i

goddamn it, I could have used this last week :/ (ok djm) On Wed, 6 Nov 2019, Stuart Henderson wrote: > Found this diff when updating an old tree, ok? > > > Index: usr.sbin/tcpdump/tcpdump.8 > === > RCS file:

Re: HID devices without numbered reports

On Tue, 29 Oct 2019, Patrick Wildt wrote: > Ok, so it turns out that this is related with opening/closing > the uhid(4) device. Because every open(2) and close(2) also > opens and closes the pipe. I think for ehci we somehow can > save the toggle and restore it on re-open, and for xhci we >

Re: HID devices without numbered reports

On Mon, 28 Oct 2019, Damien Miller wrote: > BTW, the token still becomes unresponsive after the first transaction, > but looking at a sniff (using an OpenViszla), it seems we're getting the > DATA0/DATA1 flipping incorrect on the wire. > > On OpenBSD, this is the last rx of

Re: HID devices without numbered reports

On Fri, 25 Oct 2019, Patrick Wildt wrote: > > So from what I understood the Yubikey expects the transfer to happen > > on the Interrupt OUT pipe instead of doing a control transfer. Read- > > ing some code and documentation, it looks like that we should by de- > > fault send our reports on the

HID devices without numbered reports

Hi, Some HID devices do not list any report IDs for communication, e.g. my Yubikey5: > uhidev0: iclass 3/0 > uhid0 at uhidev0: input=64, output=64, feature=0 > ugen0 at uhub0 port 2 configuration 1 "Yubico YubiKey FIDO+CCID" rev > 2.00/5.12 addr 2 on Linux, these can be talked to by sending to

Re: Potential null pointer dereference in sshkey shielding

On Wed, 26 Jun 2019, Reynir Björnsson wrote: > Hello, > > I have noticed a potential NULL pointer dereference in the recent code > for ssh key shielding. Essentially, during error handling > explicit_bzero(enc, enclen) is called. This should be fine when enc is > NULL as long as enclen is zero.

Re: ssh-askpass(1): fix indicator size with multiple screens

On Sun, 16 Jun 2019, Matthieu Herrb wrote: > On Sun, Jun 09, 2019 at 04:47:53PM +0200, Matthieu Herrb wrote: > > Hi, > > > > ssh-askpass(1) is trying to be clever and computes the size of its > > indicator relatively to the screen resolution. > > > > Unfortunatly, when multiple screens are

Re: register DoT in /etc/services?

On Sun, 27 Jan 2019, Theo de Raadt wrote: > I need to add I worry for the future, the 512-1023 reserved space is > being gobbled at a rapid pace by new services, which not only decreases > the port# entropy but reduces the total number of reserved ports which > can be allocated. Fewer software

Re: qsort comparision function bug

On Mon, 21 Jan 2019, Dariusz Sendkowski wrote: > Wouldn't it lead to undefined behavior? > According to the standard: "... The value of the result of an integer > arithmetic or conversion function cannot be represented (7.8.2.1, 7.8.2.2, > 7.8.2.3, 7.8.2.4, 7.22.6.1, 7.22.6.2, 7.22.1) ..." > This

Re: www/64.html - OpenSSH version 7.8 or 7.9?

On Thu, 18 Oct 2018, jungle boogie wrote: > I see the release notes are alive: > https://www.openssh.com/txt/release-7.9 > > Might want to change the link on https://www.openssh.com leading to the > release, still showing 7.8. not everything updates at once, some things need to be committed

Re: close filedescriptors of children

On Wed, 7 Mar 2018, Gerhard Roth wrote: > Below is an updated patch that includes proc.c of switchd and vmd. > It also passes the 'debug' flag to proc_init() so that it won't touch > std* in that case. FWIW sshd unconditionally clobbers stdin and stdout and will also clobber stderr if the debug

Re: ssh: don't close fds multiple times and don't close(-1)

ok djm On Mon, 5 Feb 2018, Theo Buehler wrote: > In channel_close_fd(), the file descriptors for the socket, stdin, > stdout and stderr aren't necessarily distinct, so closing them results > in EBADF. In addition, the diff adds a couple of positivity checks to > avoid calling close(-1). > >

Re: base system multi-booting in MBR

On Wed, 31 Jan 2018, Alexei Malinin wrote: > Hello. > > If the base system supported multi-booting in MBR would the community be > interested in it? Doesn't it already? "machine boot sd0X"

Re: use inline functions instead of __statement

On Thu, 4 Jan 2018, David Gwynne wrote: > my theory is that __statement (a gcc extension) was used to allow > macros to evaluate their argument(s) once by assigning it to a local > variable, and then returning a value. this is difficult with normal > macros. Not understanding - doesn't this: >

Re: sshd(8) logging of client disconnect from ClientAliveInterval

ok by me On Wed, 18 Oct 2017, Darren Tucker wrote: > On Tue, Oct 17, 2017 at 09:10:38PM +0300, Lars Noodén wrote: > > Here is a replacement patch. > > I meant reusing the existing function rather than cloning it. It's > currently static so it needs to be exported but IMO that's better than >

freezero(NULL, 0)

Hi, memset(NULL, 0, 0) is (strictly speaking) undefined behaviour, but there's no reason that freezero(3) needs to follow suit. This mentions that freezero(NULL, 0) is valid in the manpage, so that anyone who copies this API should get it right too. ok? Index: malloc.3

Re: systemd compat for doas

On Mon, 3 Jul 2017, Franco Fichtner wrote: > > > On 2. Jul 2017, at 8:59 PM, Ted Unangst wrote: > > > > If the username starts with a digit, but isn't a number, treat it like root. > > I question the simplicity of this patch due to the fact that it leaves > no head room

Re: [PATCH 02/04] Adjust AES testcase to the new implementation

ok On Mon, 24 Apr 2017, Mike Belopuhov wrote: > Adjusts the regress test. > > --- > regress/sys/crypto/aes/Makefile | 2 +- > regress/sys/crypto/aes/aestest.c | 10 +- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git regress/sys/crypto/aes/Makefile

Re: tcpdump: decode BGP Administrative Shutdown Communication

On Wed, 19 Apr 2017, Job Snijders wrote: > The realisation that a shutdown communication may contain \0 (since NUL is a > valid UTF-8 char) \0 isn't a valid UTF-8 character. UTF-8 sets the MSB on code points > 127: https://en.wikipedia.org/wiki/UTF-8#Description

Re: rebound quantum entanglement

On Thu, 15 Sep 2016, Chris Cappuccio wrote: > That rebound acts like a nameserver is what prompted the idea to > hijack the resolver. But it's really a tool that takes over certain > duties from the libc resolver, so the libc resolver should be properly > configurable to hand over duties, or not.

Re: Default softraid crypto PBKDF2 rounds

On Wed, 7 Sep 2016, Andreas Bartelt wrote: > yes, due to the larger internal state of the blowfish algorithm which is > harder to efficiently realize in dedicated hardware. However, since bcrypt's > internal state effectively is of fixed size, scrypt would be an even better > option since it

Re: Default softraid crypto PBKDF2 rounds

On Tue, 6 Sep 2016, David Coppa wrote: > Il 6 settembre 2016 14:56:32 CEST, Filippo Valsorda ha > scritto: > >Hello, > > > >I recently had the occasion to dive into the softraid crypto code [1] > >and was quite pleased with the cleanliness of it all. However, I found >

Announce: OpenSSH 7.3 released

h.com/report.html Security bugs should be reported directly to open...@openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom.

Re: [armv7] introducing tipru(4)

On Wed, 6 Jul 2016, Ian Sutton wrote: > * tipru comes disabled by default. Attempts to enable tipru, and > following modification of the instruction/data/shared memory > spaces, are only allowed when the system's securelevel(7) is equal > or lesser than zero. When the system's

Re: [ntpd] Simultaneously listen on IPv4 and IPv6

On Tue, 17 May 2016, Henning Brauer wrote: > > What about systems with net.inet6.ip6.v6only=0? > > Those haven't been taken into consideration by yours truly and might be > the compelling argument to have this code :) That sysctl isn't hooked up to anything, it should be removed. (compare

Re: spamd - blacklists

On Tue, 15 Mar 2016, li...@wrant.com wrote: > What's going on with the BGP as a transport then, is it available to > the general public? Must be much better than the fubar DNS. Nackts > thing and we'd be attempting carping on tunnelled over DNS syndrome. Years ago I added the pftable keyword

OpenSSH Security Advisory: xauth command injection

OpenSSH Security Advisory: x11fwd.adv This document may be found at: http://www.openssh.com/txt/x11fwd.adv 1. Affected configurations All versions of OpenSSH prior to 7.2p2 with X11Forwarding enabled. 2. Vulnerability Missing sanitisation of untrusted input allows an

Re: Xorg stipple

On Wed, 9 Mar 2016, joshua stein wrote: > Is anyone seriously finding video/Xorg bugs through the default X > stipple pattern anymore? Xorg changed the default to draw a black > background a while ago (with stipple enabled using the -retro flag), > but we have this local change that reverted it

Re: utf8 hack for ls

rather than scattering hacks in each program that needs to output utf8 to the console, how about making something for libutil that they all can use? On Sun, 25 Oct 2015, Ted Unangst wrote: > it only gets deeper and thicker... > > this decodes chars and prints ? for bytes it doesn't like, as

Re: ChachaPoly-03: Chacha20-Poly1305 AEAD construction as per RFC7634

On Mon, 26 Oct 2015, Mike Belopuhov wrote: > OK? Will this get the nonce right on BE systems? > + /* initial counter is 1 */ > + ctx->nonce[0] = 1; > + memcpy(ctx->nonce + CHACHA20_CTR, key + CHACHA20_KEYSIZE, > + CHACHA20_SALT);

Re: [PATCH] SSH tunnels without root permissions

On Tue, 6 Oct 2015, Ossi Herrala wrote: > ping? > > On Fri, Sep 18, 2015 at 06:46:20PM +0300, Ossi Herrala wrote: > > Hi everyone, > > > > The following patch makes it possible to build SSH layer 2 (and layer > > 3) tunnels without using root permissions when connecting. > > > > This is

Re: UTF-8 string filtering

On Sat, 12 Sep 2015, Stefan Sperling wrote: > > On Fri, Sep 04, 2015 at 03:17:31PM +1000, Damien Miller wrote: > > Hi, > > > > For a long time OpenBSD has been careful about filtering potentially- > > hostile strings that were destined for logs or TTYs u

UTF-8 string filtering

0x206D, 0x206D }, + { 0x206E, 0x206E }, + { 0x206F, 0x206F }, + /* C.9 Tagging characters */ + { 0xE0001, 0xE0001 }, + { 0xE0020, 0xE007F }, +}; diff --git a/utf8_stringprep.c b/utf8_stringprep.c new file mode 100644 index 000..dcbd304 --- /dev/null +++

Re: NTRU Open Source Project / Post-quantum era

On Sat, 23 May 2015, ertetlen barmok wrote: Hello, https://github.com/NTRUOpenSourceProject When will LibreSSL have ciphers for the Post-quantum era? http://tech.slashdot.org/story/15/05/15/007248/are-we-entering-a-golden-age-of-quantum-computing-research From wikipedia: NTRU is a

  1   2   >