From: "Brandon Mercer" Subject: Re: another yubikey diff To: "Theo de Raadt" Cc: "Mark Kettenis" , "Miod Vallat" , tech@openbsd.org Date: Fri, 22 Aug 2025 11:09:44 -0400 On Fri, Aug 22, 2025, at 11:03 AM, Theo de Raadt wrote: > Brandon Mercer wrote: > > > On Fri, Aug 22, 2025, at 10:42 AM, Theo de Raadt wrote: > > > > Mark Kettenis wrote: > > > > > > From: "Theo de Raadt" > > > > Date: Fri, 22 Aug 2025 08:31:19 -0600 > > > > > > > > Why not invert this with a "donotconnect" variable, then your diff > > > > shrinks significantly. > > > > > > Not really; the struct wkbddev_attach_args is typically allocated on > > > the stack, without an explicit memset, so the new member must be set. > > > > So change all those stack allocations to = { 0 } > > > > And change one driver to set .noconnect = 1; > > > > Making the default noconnect is going to explode someone's head later > > on when they write a new kbd driver. > > > > My reply has nothing to do with the diff and more to do with a particular use case. My > > typical usage is to use my OTP to sign into my machine upon boot. If I have to fiddle > > with wsconsctl in order to use the yubikey OTP, then my initial sign on requires me to > > sign in first. This makes me lean towards fixing the yubikey tools so it's easier to > > reprogram the default behavior of slot one not to spam OTP's on each press. I do agree > > that their tooling is arduous at very best > > Without a way to disable OTP on a device, this is where we land. > > > and this default behavior is prohibitive. > > the new default behaviour is keeping us sane, and I in particular don't care > how people who don't work on fixing the tools feel about it. > > Or is this a request for a refund? If we were able to easily reprogram the yubikey and disable OTP on slot one and instead enable it on slot 2, then we can still attach the key as a keyboard and use it to login. With the current state, even if I do setup my key to a more desirable state I will still be required to work around the default system behavior. My problem is less that it attaches as a keyboard and more that the default behavior of a touch is to spam OTP's. Again, these are not our problems to solve.