Sad, we can't even test if the intrinsics are frozen with unsafe harden.

I'm pretty sure this matches behavior of the import '@endo/init/unsafe-fast.js's it is replacing:

https://github.com/endojs/endo/blob/master/packages/init/unsafe-fast.js

• import { lockdown } from '@endo/lockdown';
  • "main": "pre.js"
    • import 'ses';
      • import './src/lockdown-shim.js';
        • globalThis.lockdown = options => {…};
    • globalThis.lockdown = lockdown;
• import './pre-remoting.js';
  • export * from '@endo/init/pre.js';
    • import '@endo/lockdown';
  • export * from '@endo/eventual-send/shim.js';
• const options = { __hardenTaming__: 'unsafe', }; lockdown(options);

We might be able to change it; I just needed to avoid double-lockdown errors.

The part that you're missing is that '@endo/init/pre.js' is mapped to init/src/pre-node.js on node through the package.json exports, which imports both './node-async_hooks-patch.js' and '../pre.js'.

Should the file's name capture this is doing an unsafe lockdown ?

Also the original @endo/init also tames async_hooks which this doesn't do. See endojs/endo#2711

I'm fine with this as-is, but will accept suggestions.

I would prefer renaming this file to maybe-unsafe-lockdown.js to avoid hiding the unsafe harden taming.

I would prefer renaming this file to maybe-unsafe-lockdown.js to avoid hiding the unsafe harden taming.

I'm pretty sure that stateDBDir is unused if slogSender and swingStore are provided.