Re: bin/58212: cgdconfig(8): Add zfs verification method

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/58212; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: Malte Dehling <mdehling%gmail.com@localhost>, gnats-bugs%NetBSD.org@localhost,
        netbsd-bugs%NetBSD.org@localhost
Subject: Re: bin/58212: cgdconfig(8): Add zfs verification method
Date: Mon, 29 Apr 2024 05:19:05 +0700

     Date:        Sun, 28 Apr 2024 20:38:55 +0000
     From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
     Message-ID:  <20240428203857.A5B9C84D67%mail.netbsd.org@localhost>
 
   | A comment in fstyp(8) suggests there's a checksum (which it doesn't
   | verify); maybe we can use that?
 
 As long as the checksum is guaranteed to be there (if it is currently
 unused, someone might decide not to bother calculating it, one day)
 and it is clear over which bytes the checksum is calculated (and
 which algorithm to use), that would be fine.
 
   | Would also be nice if we could quantify the false acceptance probability
 
 It doesn't really matter, this has nothing whatever to do with the
 security of the cgd, these validity checks are used merely to allow
 detection of incorrect passwords (etc) - they (even when they appear
 to be validating some data struct) have nothing whatever to do with
 use of any of the data.
 
 That is, if the validation method should give a false positive, the
 only effect is that when the cgd data is later used, it will effectively
 contain rubbish (just as would, say, an uninitialised partition of
 a drive) - if the (software) user of the data cannot detect that
 the daya is invalid, then it has problems, but they aren't caused
 by cgd, it would have the same problems in other uses.
 
 This interpretation is reinforced by the fact that it is possible to
 simply disable the verification (command line option), not bother doing
 it at all, and everything still works, and is just as secure.
 
 It is nice for the (human) user to be told what the issue is, as
 soon as possible (eg: to be told the wrong password has been given)
 rather than have some later step complain, but it isn't important.
 
 The 1/2^16 probability that the MBR gives (assuming you're correct
 about that, which I don't doubt) is really good enough - the much
 higher probabilities against false positivies of the other methods
 are nice, I guess, but aren't there because of cgd, they're what
 happened to exist anyway.
 
 kre