-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
expose captureFromMap() #2308
expose captureFromMap() #2308
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good enough. Some optional copy edits recommended.
I did not hold previous refactors to this bar, so please feel free to punt: would be nice to have a test that shows the freshly exposed functionality. For the parsers refactor, I’m relying on bundleSource to exercise the new interfaces.
@@ -0,0 +1,322 @@ | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/** | |
/* |
makeImportHookMaker, | ||
} from './import-hook.js'; | ||
import { link } from './link.js'; | ||
import { resolve } from './node-module-specifier.js'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside: I wonder whether someday we come to rue this degree of coupling to Node.js module specifier math. I think when that day came, we’d want to have a resolverHook
or something. Making a -lite-lite.js
will be untenable.
But this module is not big. It might not be worth worrying about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree. but this is one of those blessed things we can decide to not decide, since we do not yet have to.
Co-authored-by: Kris Kowal <kris@agoric.com>
Co-authored-by: Kris Kowal <kris@agoric.com>
@kriskowal I've added some tests: https://github.com/endojs/endo/pull/2308/files#diff-83a914c4839dc5f99eee550a04270efaa250a614f292da572b717e3cde1db18f Noting that a snapshot would be inappropriate for |
Description
This exposes
captureFromMap()
incapture-lite.js
.This function is similar to e.g.,
makeArchiveFromMap()
inarchive-lite.js
; but rather than creating a.zip
archive, it simply returns the fully-completedCompartmentMapDescriptor
,Sources
, and a mapping of filename to compartment map name.This information is needed for next-gen-lavamoat-node ("endomoat")'s automatic policy generation.
Another commit disables the hardcoded check for parsers in the compartment map validation functions (which are no longer necessary after #2304).
Questions
archive-lite.js
intocapture-lite.js
. Should these be extracted into a shared module?Security Considerations
None that I'm aware of.
Scaling Considerations
If anything, it may shave a few nanoseconds off of compartment map validation.
Documentation Considerations
Probably should be added to
NEWS.md
.Testing Considerations
captureFromMap()
needs some sort of basic round-trip test. I think a snapshot of the return value may suffice?Compatibility Considerations
None
Upgrade Considerations
None