security: UUID-based caveat validator registration (Step 1/3).
The current Caveat scheme uses the package path of the CaveatValidator
implementation to associate a caveat with its validation function.
Relying on such type information is brittle because any renaming breaks
caveat validation.
Instead, we (toddw@, bprosnitz@, ataly@ and ashankar@) decided to use
explicit unique ids to associate caveats with their validation
functions.
This commit implements the registration mechanism for associating caveat
validation functions with caveats.
As a bonus, this scheme also improves caveat validation performance
by a factor of 3x, as the VOM-decoding happens into concrete
types (instead of into an interface). Benchmarks added in this CL
on my laptop show:
BenchmarkValidateCaveat 200000 13337 ns/op
while a comparable benchmark on the older style caveat parsing and
validation showed ~45K ns/op.
This is the first (& biggest) step of a 3 step process to be
completed in the next week:
(1) This change: Introducing a registry that associates
caveats identified by UUIDs with validation functions.
(2) Once all binaries have been rebuilt & restarted with this
change, stop populating the ValidatorVOM field and
rebuild & restart services again
(3) Once all blessings have been refreshed (so that the
ValidatorVOM field is not populated), drop the field
altogether.
MultiPart: 1/2
Change-Id: I590414110d71cb4c70d9069d01161df15b7ebd49
15 files changed
