Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
>> Date: Sat, 6 Aug 2022 18:47:47 -0400
>> From: Gabriel Rosenkoetter <gr%eclipsed.net@localhost>
[comments reordered]
>> I guess my follow-up Devil's advocacy question would be: why does this
>> need to be in base, rather than provided via ports?
>
> cgdconfig runs early at boot before most file systems are mounted --
> often before the file systems on which any packages are installed are
> mounted. The cgdroot ramdisk, for instance, has a very minimal NetBSD
> userland in a ramdisk just to configure cgd(4) volumes before mounting
> the `real' root from them and chrooting into it. fidocrypt could be
> baked into this ramdisk.
First, I think this is totally fine to add to the base set, given the
justification of using it to store keys for cgd that would be used for
beyond / and /usr, and it being small.
That raises two semi-separable questions:
1) should it be in /, so that if / is not on cgd but /usr is, things
work?
2) what is the path to getting it into the cgdroot filesystem for
root-on-cgd? Does the / and /usr boundary matter? I have never
tried this, but it seems that it's just selecting a bunch of paths for
the ramdisk and which of / and /usr they are on is not important in
this process. Being small still is important.
I'm not sure if 1 matters that much or not, but it's plausible that
people want that; leaving a separate / not encrypted and encrypting all
the rest seems reasonable, but OTOH if cgdroot is easy enough that seems
better.
>> [...], whereas I think what you're proposing to add to base is an
>> interface to a standards-compliant (and somewhat-open) device
>> specification. Right?
>
> The _file format_ used by fidocrypt(1) is bespoke, based on sqlite3.
I can see why you did this, but I am not sure we want to put sqlite3 in
/. I realize there are people who either have the one-big-filesystem
approach, and people with a merged / and /usr, compared to the
traditional Unix layout. On most systems, I tend to have / and /usr
separate. I believe NetBSD still supports the traditional layout and
considers it the standard approach.
Therefore I wonder if a sqlite3-based format is necessary, because while
I haven't read the code, I would expect this is just an encrypted key
plus one table with a row for {each device that stores a KEK}, which
seems easy enough for lines with printed hex and spaces, or a bunch of
structs, and whole-file-rewriting/rename to modify. Or using proplib
which seems to fit.
But maybe that is a lot of work for no point and we shouldn't try to
avoid sqlite3 in /. Maybe we're going to rewrite proplib to use
sqlite3; I dimly remember someone saying that but I am not sure if it
was a joke.
After looking at /lib and what is already there:
I'm a bit horrified.
sqlite3 doesn't seem as big as I thought, relatively speaking; it's
0.9 MB more on 9.3 MB -- but it's still 10% growth.
So I guess it's somewhat 10% growth, and somewhat the disruption of
moving it, but if unpacking the sets and running postinstall fix is
fully satisfactory, that's not really disruption.
I would say that if you propose to move sqlite3 to /, that deserves a
thread with that as the title. I don't personally object (I have pruned
off retrocomputing as a hobby), but I think it's a bigger deal than
adding fidocrypt.
Attachment:
signature.asc
Description: PGP signature