From nobody Mon Jan 8 18:36:37 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T82pV3tmbz56NXQ for ; Mon, 8 Jan 2024 18:36:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T82pT5fxwz47GZ for ; Mon, 8 Jan 2024 18:36:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-557a318123bso1612026a12.2 for ; Mon, 08 Jan 2024 10:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704739008; x=1705343808; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nzZIvQ3h1Ic7FTd4fFRlgVe1HVyk7fuDmKnUJjY9Y9U=; b=I/YbJ6PzIjlQmjAHuKGErsDiXkl7RCq72FP+5Q8QF9et8oTtNfF6TwwsSLnkzWJ0NS tlTaFq80UBjl5UXMSLE2aeRVjogl2VykBzeyI/NVC5ymQw2OOlcpk9pl+QHFj9R1HT4l HlQuyCxg3jivsvkuSNuyaAhlzBLxLdgruZ+P2r+FEnvKhTcMsyfFcz3kU+nTKQ6BrSGg 0RdGBHClFiUGxuYR6OIRbTQs3Ll1uo+vyhDOVW+nP+9GZ83YqhUwOBiYEf8crCUMv43y HTeNnNprufaY7KhrksJ6WE48y9TkoRfqD0kEKTIkBDS4opiM5jIrilBNlASD+y6WE7Q2 q1IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704739008; x=1705343808; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nzZIvQ3h1Ic7FTd4fFRlgVe1HVyk7fuDmKnUJjY9Y9U=; b=GK3TsyT/s8Uvw+cmjisw8RKHUD06rlGyUbD/IROV/s/jvLt+uGCnIg0VgDzZB4xpbw 1HnF9gAgzR2Vbej6MbYHjit8nViMsEY5aFLfLTK2cex1bqIwrrKZRM4WpG6P4L6NQjyx V5oGPiZn/Ok43eOMox2iM3cGZ+RVhycWVX0k2QOXHsewCLK+Fs7kuloOe5a8X29hFL37 inHJi2GHoTwscybkbJ6/mMkVYoWRtyd6LjZyEWzj8RdCFhC+gMpBbYilcowYvdz9YsEr HsydmVqpp3F+h64R9VXANV+612/kJ6qwn86cmomYwybyXJ0TDRUKlrbb9z/9ScH2xfHo +MoA== X-Gm-Message-State: AOJu0Yy/IicBCWR8il+xP94TlwKVMCfk9ERZt2NAytjpsmdW0rdFF+Pa siIYpQKqu4R+TtqFh1GufhFop7f8Wi0G3GQOQp42qM+X328mEw== X-Google-Smtp-Source: AGHT+IFFJznc/OySdSX4lokt4EQwdpw7XG/wuhgpP+n6tkAbO6xZqRJnJcw7T8tPbkJloMMK2WVup1T0MTFQFdOohqw= X-Received: by 2002:a17:906:f584:b0:a27:8833:2411 with SMTP id cm4-20020a170906f58400b00a2788332411mr978192ejd.60.1704739007742; Mon, 08 Jan 2024 10:36:47 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> In-Reply-To: From: Warner Losh Date: Mon, 8 Jan 2024 11:36:37 -0700 Message-ID: Subject: Re: Move u2f-devd into base? To: Kyle Evans Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fdd7a0060e737a5d" X-Rspamd-Queue-Id: 4T82pT5fxwz47GZ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000fdd7a0060e737a5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024 at 9:35=E2=80=AFAM Kyle Evans wrot= e: > On 1/8/24 10:30, Tomoaki AOKI wrote: > > On Mon, 8 Jan 2024 08:18:38 -0700 > > Warner Losh wrote: > > > >> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber > >> wrote: > >> > >>> We have FIDO/U2F support for SSH in base. > >>> > >>> We also have a group "u2f", 116, in the default /etc/group file. > >>> > >>> Why do we keep the devd configuration (to chgrp the device nodes) > >>> in a port, security/u2f-devd? Can't we just add this to base, too? > >>> It's just another devd configuration file. > >>> > >> > >> This properly belongs to devfs.conf no? Otherwise it's a race... > >> > >> Warner > >> > >> -- > >>> Christian "naddy" Weisgerber > naddy@mips.inka.de > > > > It's devd.conf materials. It actually is security/usf-devd/files > > u2f.conf and its contents is sets of notify 100 { match "vendor" ... > > match "product" ... action "chgrpy u2f ..." };. > > Some hase more items in it, though. > > > > So it should be in ports to adapt for latest products more quickly than > > in base, I think. > > > > I don't see any obvious reason that we can't compromise and have a > baseline of products in base and just use the port for new products not > yet known to base. These vendors presumably aren't going to quickly > repurpose some PID for a non-u2f thing, much less in a way that we care > about. > Yea, I just wonder why it has to be devd.conf, and not devfs.conf. What are we missing from that to make this doable generically? If we want it safe, w= e may need some additional work around the whole ugen thing it uses. Warner --000000000000fdd7a0060e737a5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 8, 2024 at 9:35=E2=80=AFA= M Kyle Evans <kevans@freebsd.org> wrote:
On= 1/8/24 10:30, Tomoaki AOKI wrote:
> On Mon, 8 Jan 2024 08:18:38 -0700
> Warner Losh <im= p@bsdimp.com> wrote:
>
>> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber <naddy@mips.inka.de&= gt;
>> wrote:
>>
>>> We have FIDO/U2F support for SSH in base.
>>>
>>> We also have a group "u2f", 116, in the default /etc= /group file.
>>>
>>> Why do we keep the devd configuration (to chgrp the device nod= es)
>>> in a port, security/u2f-devd?=C2=A0 Can't we just add this= to base, too?
>>> It's just another devd configuration file.
>>>
>>
>> This properly belongs to devfs.conf no? Otherwise it's a race.= ..
>>
>> Warner
>>
>> --
>>> Christian "naddy" Weisgerber=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 naddy@mips.inka.de
>
> It's devd.conf materials. It actually is security/usf-devd/files > u2f.conf and its contents is sets of notify 100 { match "vendor&q= uot; ...
> match "product" ... action "chgrpy u2f ..." };. > Some hase more items in it, though.
>
> So it should be in ports to adapt for latest products more quickly tha= n
> in base, I think.
>

I don't see any obvious reason that we can't compromise and have a =
baseline of products in base and just use the port for new products not yet known to base.=C2=A0 These vendors presumably aren't going to quick= ly
repurpose some PID for a non-u2f thing, much less in a way that we care about.

Yea, I just wonder why it has to= be devd.conf, and not devfs.conf. What are
we missing from that = to make this doable generically? If we want it safe, we
may need = some additional work around the whole ugen thing it uses.

Warner=C2=A0
--000000000000fdd7a0060e737a5d--