On Fri, Aug 22, 2025, at 11:03 AM, Theo de Raadt wrote:
> Brandon Mercer <bmercer@eutonian.com> wrote:
> 
> > On Fri, Aug 22, 2025, at 10:42 AM, Theo de Raadt wrote:
> > 
> >  Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > 
> >  > > From: "Theo de Raadt" <deraadt@openbsd.org>
> >  > > 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.