feat(compartment-mapper): Validate compartment maps #1085
Conversation
kriskowal
added
endo
enhancement
kriskowal
force-pushed
the
agoric-3859-hash-bundle-compartment-map-validation
branch
2 times, most recently
from
dd5588f
to
a7702d8
Compare
| @@ -164,12 +165,11 @@ export const parseArchive = async ( | |||
| } | |||
|
|
|||
| const compartmentMapText = textDecoder.decode(compartmentMapBytes); | |||
| const compartmentMap = /** @type {CompartmentMapDescriptor} */ (parseLocatedJson( | |||
| const compartmentMap = parseLocatedJson( | |||
There was a problem hiding this comment.
I might have asked this before, but do our specs say anything about repeated keys in JSON? That would be a way for two different readers to interpret the same compartment map in divergent ways. If TC39 doesn't have a stance, we might want to add a note to the docs around this hashing/security stuff, that correctness depends upon consistent behavior of everybody's JSON.parse.
There was a problem hiding this comment.
JSON (ECMA 404) has no position on repeated keys, but JS (ECMA 262) takes the position that JSON gets evaluated as a JS expression if it parses according to 404, such that the last property defined with the one key wins. So, as long as everyone uses JS, they’ll arrive at the same interpretation.
|
|
||
| const { compartment, ...extra } = scope; | ||
| assert( | ||
| Object.keys(extra).length === 0, |
There was a problem hiding this comment.
I'm tempted to suggest this assertNoExtra(extra, explanation) pattern be factored out so the calls fit on a single line, but I think I'm just feeling grumpy towards prettier's verbosity today. The work this file is doing is completely straightforward.
kriskowal
force-pushed
the
agoric-3859-hash-bundle-compartment-map-validation
branch
from
a7702d8
to
a46fb2c
Compare
kriskowal
force-pushed
the
agoric-3859-hash-bundle-compartment-map-validation
branch
from
a46fb2c
to
4204058
Compare
kriskowal
deleted the
agoric-3859-hash-bundle-compartment-map-validation
branch
Fixes: #601
Refs: Agoric/agoric-sdk#3859
This change adds validation for compartment map input from archives.
This design sacrifices schema evolution for a tight correspondence between the content of a compartment map and its consistent hash. The validator allows for nothing extra. This may become a hindrance, in which case we would need to relax the extra property assertions and closed ranges for some types. For now, this is conservative in order to provide the maximum assurance to the authors.