profile
viewpoint

domenic/promises-unwrapping 990

The ES6 promises spec, as per September 2013 TC39 meeting

erights/quasiParserGenerator 54

A template string tag for generating template string tags.

erights/Orthogonal-Classes 24

Proposed EcmaScript Class Syntax clarifying orthogonal concerns

erights/wasm-linkage 8

Branch of wasm-gc for exploring wasm-linkage subset

cocoonfx/causeway 7

Causeway distributed debugger.

claudepache/es-legacy-function-reflection 3

JavaScript: Legacy reflection features on functions needed for web compatibility

erights/PNLSOWNSF 3

PrivateName-like special object with name-side faulting

erights/proposal-System-object 2

a vettable System object for standard power-granters

PR opened Agoric/SES-shim

fix: remove deprecated noTame options

Fixes #326

Removes support for old noTame options, which we can't merge until after https://github.com/Agoric/agoric-sdk/pull/1128 is merged.

As described in #326, subsequent calls to lockdown don't need to agree exactly. Only the options provided need to agree exactly. Absence implies agreement with the status quo, whatever that is.

+24 -34

0 comment

1 changed file

pr created time in 12 hours

create barnchAgoric/SES-shim

branch : remove-deprecated-noTame-options

created branch time in 12 hours

issue commentAgoric/SES-shim

lockdown noTame options reform

However, we still require defaults to be safe, and thus tame, and we prefer booleans to default to falsy. Suggest unsafe* rather than noTame*, especially because it reminds one of the implied risk.

In https://github.com/Agoric/SES-shim/pull/327 we adopt a different solution. For every old noTameFoo defaulting to false, there is now a fooTaming option defaulting to the string 'safe'. The simple opposite setting is 'unsafe' rather than true. These are the only choices as of #327 , but open the door to more choices.

erights

comment created time in 12 hours

pull request commentAgoric/agoric-sdk

fix: update to new style taming options

I just changed from Draft to Ready to Review. But it won't pass or be a candidate for merging until agoric-sdk upgrades its ses dependency to 0.8.0

erights

comment created time in 13 hours

push eventAgoric/agoric-sdk

Mark S. Miller

commit sha 201768f28597a706907f6108ca749f94e0eb5d19

fix: spawner leak, delete dead code (#1132)

view details

Michael FIG

commit sha b156251dc79afee566ebcde5701e259a98b93e5b

fix: add CSS to make REPL wrap correctly Credit to @dtribble for finding this incantation.

view details

Michael FIG

commit sha 6cca46640c0790cc25ee00bba717e1de0e5b2e0c

Merge pull request #1136 from Agoric/mfig/repl-wrapping Add CSS to make REPL wrap correctly

view details

Michael FIG

commit sha a7ecd9d9a60ba2769b6865fb6c195b569245a260

feat: inbound network connection metadata negotiation

view details

Michael FIG

commit sha 5dd2e63b8c1fac9543bbb9f9e2f5d8e932efc34a

feat: outbound connection metadata negotiation

view details

Michael FIG

commit sha d3ee75442d68daa019af184356ec81ed7804f78b

fix: much clearer IBC implementation

view details

Michael FIG

commit sha 2297a089a0fc576a4d958427292b2f174215ad3f

feat: pass local and remote address to onOpen callback

view details

Michael FIG

commit sha 79bd3160a3af232b183bcefb8b229fdbf6192c49

feat: pass blockHeight and blockTime from all IBC events

view details

Michael FIG

commit sha 3f92256dbd8a505f05ae262391a64dd76005580a

fix: don't simulate transactions since we don't use gas

view details

Mark S. Miller

commit sha 15623f333928dc57fc07085f246a419f916ef4c0

fix: ensure keywords do not collide with numbers (#1133)

view details

Michael FIG

commit sha 904b3a0423222a1b32893453e44bbde598473960

Merge pull request #1135 from Agoric/mfig/version-negotiation IBC version negotiation

view details

Mark S. Miller

commit sha 8a9ee0e3efc723ce0968f766b4e9acee483f0f07

fix: update to new style taming options

view details

push time in 13 hours

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

I gotta say, if the only cost on the arithmetic side is on the sign of infinities, I'm leaning ever farther towards normalizing -0 to 0 in records and tuples.

How important are the signs of infinities to actual useful numeric algorithms in practice?

bakkot

comment created time in 14 hours

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

@devsnek do you agree with @Zarel 's assessment that it can only make an arithmetic difference if things explode to infinity? That, infinities aside, there cannot be any arithmetic difference? If not, could you show an arithmetic example not involving infinities?

bakkot

comment created time in 14 hours

issue commenttc39/proposal-function-implementation-hiding

Requesting more details on the motiviation for two directives

See https://github.com/tc39/ecma262/pull/1739#issuecomment-634380712

codehag

comment created time in 15 hours

pull request commenttc39/ecma262

Normative: function implementation hiding

I see at https://github.com/tc39/ecma262/pull/1739/files#r351043373 that @allenwb also prefers orthogonal "hide source" and "hide stack" directives. The resulting thread asks for a use case.

Here's one: When computing across a membrane, the stack frames of the membrane mechanism itself are often a distraction to the debugging experience. Debugger often do have better ways of handling the suppression of such unwanted detail. But for so-called printf debugging, looking at stacks dumped to logs, this could reduce the verbosity a lot. The Error stacks proposal will give better knobs for this as well.

My point is that I can imagine wanting to suppress stack traces for reasons that would not imply that I also want to suppress source.

Altogether, I am happy to see this go forward with only "hide source";. We should revisit the hiding of stack frames as part of the error stacks proposal.

michaelficarra

comment created time in 15 hours

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

What within-IEEE-arithmetic examples are there of useful calculations without infinities that go awry if a -0 were normalized to a 0?

I mean any -0. The example need not have anything to do with records and tuples. I am trying to understand what is it about numeric computations that motivates the two zeros, and what is lost if the distinction were collapsed.

Again, obviously, we are not going to fix IEEE. But I don't understand this and would like to before continuing the records and tuples debate.

bakkot

comment created time in 15 hours

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

At https://github.com/tc39/proposal-record-tuple/issues/65#issuecomment-633751364 @Zarel offer the example:

const coord = #{x: 1, y: -3};
const coord2 = #{x: coord.x / 1e350, y: coord.y / 1e350};

const isBelowOrigin = coord2.y < 0 || Object.is(coord2.y, -0);

I don't understand what this is supposed to be an example of. It resorts to Object.is to reveal whether coord2.y is -0. But Object.is is not an arithmetic operator. It does not exist, for example, in IEEE. Is there an arithmetic, numerical example of the utility of -0? I'm sure there must be. But the only within-IEEE observable consequence I know of the difference is that, for example, 1/0 === Infinity and 1/-0 === -Infinity. If you've already fallen off the precision limits so far as to reach an infinity, especially if it is because you divided by some zero, you've probably already lost anyway and need to rewrite your algorithm.

What within-IEEE-arithmetic examples are there of useful calculations without infinities that go awry if a -0 were normalized to a 0?

bakkot

comment created time in 15 hours

issue commentw3c-ccg/zcap-ld

Chain shortening

Did you rotate the roles of Alice Bob and Carol? If so, could you rotate them back? Thanks.

cwebber

comment created time in 15 hours

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

it is against IEEE 754 to do so, and some people will argue that preventing that equality can halt forward progress as NaN intends

If NaN === NaN produced a NaB (not a boolean) or threw an error, or even went into an infinite loop, that would prevent progress. Instead it returns false. If NaN conceptually means "we don't/can't know what number this is supposed to be" then returning false is just as bad as returning true. In fact it is still worse because even for such an unknown, we'd know the reflexive case x === x would be true even if we don't/can't know what x is.

Obviously we're not going to fix IEEE. But I do not accept that breaking reflexive equality was a good idea, even just within the domain of arithmetic.

bakkot

comment created time in 15 hours

push eventAgoric/agoric-sdk

Mark S. Miller

commit sha 15623f333928dc57fc07085f246a419f916ef4c0

fix: ensure keywords do not collide with numbers (#1133)

view details

push time in 17 hours

delete branch Agoric/agoric-sdk

delete branch : no-number-named-keywords

delete time in 17 hours

pull request commenttc39/ecma262

Normative: function implementation hiding

I have just reviewed with this split in mind. The portions of this relating just to hiding source text, as well as the resulting suppression of position and source location within a stack frame but no more, LGTM.

This is still a Draft so this comment is adequate, yes?

michaelficarra

comment created time in 19 hours

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

Yes, I understand we disagree on -0 normalization.

I appreciated your concrete example. If you could illustrate your other points with concrete examples that seem representative of real issues, that would be awesome. Thanks.

bakkot

comment created time in 2 days

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

An example was posted above, twice in fact.

The example at https://github.com/tc39/proposal-record-tuple/issues/65#issuecomment-633106519

const coord = #{x: 0, y: 3};

const coord2 = #{x: coord.x * -4, y: coord.y - 3};
const isAtOrigin = coord2 === #{x: 0, y: 0};

works fine if we always normalize -0 to 0 and then use Object.is semantics. Is this the concrete example you have in mind?

bakkot

comment created time in 2 days

issue commentrickbutton/proposal-deep-path-properties-for-record

Should deep path properties work in Objects too?

Since I'm suggesting brainstorming on notation, I'll make a suggest I do not like:

const state2 = #{
    .....state1,
    counters[0].value: 2,
    counters[1].value: 1,
    metadata.lastUpdate: 1584383011300,
};

where each additional . beyond the first three would always spread and reconstruct the object one more level deep.

littledan

comment created time in 2 days

issue commentrickbutton/proposal-deep-path-properties-for-record

Should deep path properties work in Objects too?

At first I did ask that deep-path notation work for objects with no extra notation. @littledan explained why it was too surprising. Once I got it, I agreed (and agree) that without extra notation it would indeed be too surprising. I suggested notation that does not work, but it is still an example of the kind of notation I would look for. So, to start the brainstorming, my invalid suggestion was:

const state2 = #{
    ...{...{...state1}},
    counters[0].value: 2,
    counters[1].value: 1,
    metadata.lastUpdate: 1584383011300,
};

Because the deepest path is three deep, the notation at the ... location should indicate that state1's contents are being spread into state2 three deep, whereas the normal ...state1 notation only spreads state1 one deep. If the spread notation does not imply a depth at least as great as the deepest path, the expression would be statically rejected.

Until we discover such a notation, I agree with the status quo position: that deep path notation is suitable for records and tuples with no hazard, but is too hazardous to apply directly to objects.

littledan

comment created time in 2 days

push eventAgoric/agoric-sdk

Mark S. Miller

commit sha 201768f28597a706907f6108ca749f94e0eb5d19

fix: spawner leak, delete dead code (#1132)

view details

push time in 2 days

delete branch Agoric/agoric-sdk

delete branch : weaken-store

delete time in 2 days

PR merged Agoric/agoric-sdk

fix: spawner leak, delete dead code performance

Happened to come across two problems in the spawner:

All the stores were indexed on seatIdentity and should have been weak.

EMap and ESet are completely unused and unneeded (my vestigial code)

+3 -389

0 comment

4 changed files

erights

pr closed time in 2 days

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

Good, thanks.

I am in favor of always normalizing -0 to 0 in records and tuples. Such immutable containers would never contain a -0. We'd then compare using Object.is semantics. This has most of the benefits of both SameValueZero and of Object.is.

bakkot

comment created time in 3 days

push eventAgoric/agoric-sdk

Mark S. Miller

commit sha ffd671f6fa3ce2cc552e3e3e6a0d00894cd1b76c

fix: replace openDetail with quoting q

view details

push time in 3 days

pull request commentAgoric/agoric-sdk

fix: replace openDetail with quoting q

I just changed my mind and revised it to JSON.stringify without first doing toString. But question still open. Still looking for feedback.

erights

comment created time in 3 days

push eventAgoric/agoric-sdk

Mark S. Miller

commit sha a8ad873d2de78752e9edcccff35be4eb61b7b226

fix: replace openDetail with quoting q

view details

push time in 3 days

PR opened Agoric/agoric-sdk

Reviewers
fix: replace openDetail with quoting q

This combines the declassification of openDetail with the quoting of the q from @kriskowal's assertion style. It makes sense that if you're putting the quoted form of the stringified payload into the message, then you must declassify it anyway, so it is unsurprising.

Open question: @kriskowal just did a JSON.stringify directly, without doing a toString stringification first. This has pros and const. Looking for feedback.

+34 -45

0 comment

9 changed files

pr created time in 3 days

create barnchAgoric/agoric-sdk

branch : openDetail-becomes-q

created branch time in 3 days

PR opened Agoric/agoric-sdk

Reviewers
fix: ensure keywords do not collide with numbers
+23 -8

0 comment

3 changed files

pr created time in 3 days

create barnchAgoric/agoric-sdk

branch : no-number-named-keywords

created branch time in 3 days

issue commenttc39/proposal-realms

fetchSourceText hook

hi, would you like to move those issues to the related proposals?

Huh. I am surprised to find I cannot move it to proposal-compartments

Attn @bmeck permissions issue?

Jack-Works

comment created time in 3 days

issue commenttc39/proposal-promise-any

Should errors be a prototype accessor that returns the value of an internal slot?

For that goal, I am currently in the vicinity of working on the error stack shim, with expectation of getting back to our error stack proposal. That does add a new internal slot to all error objects, which would enable one to reliably distinguish errors from everything else, but not distinguish between types of errors. I remember this was one of your motivations for co-championing it.

As always, I am reluctant to introduce a new internal slot, but I am in favor of this one. This slot does have the same problems that the existing exotic internal slots do. So what's different? Like the internal slot on Date and every other exotic internal slot, this one reveals only data. It cannot be used to hide and convey an object reference. That's why I am more relaxed about it than the one we just avoided (whew!) on AggregateError. Thank you!

ljharb

comment created time in 3 days

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

SameValueZero is also surprising, but less so:

['a', -0].includes(0); // true
['a', -0, 0].indexOf(0); // 1
(_ => {
  switch(-0) { 
    case 0: return 'x';
    case -0: return 'z';
    default: return 'y'; 
  }
})(); // x
bakkot

comment created time in 3 days

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

If the memo is built naively on Sets and Maps, it will work correctly on NaN but memoize incorrectly on -0.

Some other unfortunate anomalies:

['a', NaN].includes(NaN); // true, good
['a', NaN].indexOf(NaN); // -1, crazy
(_ => {
  switch(NaN) { 
    case NaN: return 'x'; 
    default: return 'y'; 
  }
})(); // y, insane. Would anyone expect that?
bakkot

comment created time in 3 days

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

The whole NaN !== NaN thing to me is a category error between thinking within the system of arithmetic that these values are about, vs thinking about the role these values play, simply as distinguishable first class values in the programming language. In E there is a distinct arithmetic equality comparison operator that is a peer to <, <=, >=, and >. We call this "same magnitude as". NaN indeed is not same magnitude as NaN and -0 is same magnitude as 0. Note that the notion of magnitude that all these operators compare is about the role of these values as representative of arithmetic numbers. In JavaScript, we're stuck with == and === as the way you say "same magnitude as".

Object.is is about observable equivalence. It is about the role of these values in producing computation, and whether a difference produces observably different computation. Think about writing a functional memo function. Given a pure function or pure inputs, the memoization of that function should be observably identical to the original. This memoization has to compare current arguments against previous arguments. A pure function cannot give different results for a NaN now vs previously. A pure function can give different results for 0 and -0. The memo had better compare inputs on that basis.

bakkot

comment created time in 3 days

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

Btw, the Agoric distributed object system used to carefully preserve the difference between 0 and -0 in its serialization format. We defined our distributed equality semantics for passable values to bottom out in Object.is.

We changed this to let JSON always normalize -0 to 0. Our distributed equality semantics now bottom out in SameValueZero, which works well with that normalization.

bakkot

comment created time in 3 days

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

new Set([+0])).has(-0) is true

I tested and this is correct. But I find it extremely surprising. But good! Where in the spec is this normalized?

Given this strange, surprising, and pleasant fact, I am leaning towards normalizing -0 to 0 with records and tuple and then adopting Object.is semantics on the result. Has most of the virtues of both Object.is and SameValueZero while avoid most of their problems.

But first I want to understand how the spec already normalizes these for Sets and Maps. Thanks.

bakkot

comment created time in 3 days

push eventAgoric/agoric-sdk

Mark S. Miller

commit sha 136ef75bcafbba56bf0201e5857cc00a7259694f

fix: spawner leak, delete dead code

view details

push time in 3 days

PR opened Agoric/agoric-sdk

Reviewers
fix: spawner leak, delete dead code

Happened to come across two problems in the spawner:

All the stores were indexed on seatIdentity and should have been weak.

EMap and ESet are completely unused and unneeded (my vestigial code)

+1 -387

0 comment

3 changed files

pr created time in 3 days

create barnchAgoric/agoric-sdk

branch : weaken-store

created branch time in 3 days

issue commenttc39/proposal-realms

The missing ability in the new spec (1): Pre-evaluation rewrite hook

To be clear, that later proposal will still propose that these hooks be added to the Compartment API. The split between proposals means one may succeed and one may fail. But it isn't a split of the API. If both succeed, the Compartment API will heal.

Jack-Works

comment created time in 3 days

issue commenttc39/proposal-realms

The missing ability in the new spec (1): Pre-evaluation rewrite hook

See https://github.com/tc39/proposal-realms/issues/244#issuecomment-633180485

This hook should indeed be on the Compartment API. But it is likely to move to a later proposal, so expect the Compartment proposal to proceed without it. We need to divide things up this way so that needed features can gain acceptance.

Jack-Works

comment created time in 3 days

issue commenttc39/proposal-realms

HostFinalizeImportMeta hook

See https://github.com/tc39/proposal-realms/issues/244#issuecomment-633180485

The Compartment proposal has an importMetaHook. This hook is expected to stay in the Compartment proposal, as it relates (loosely) to importing.

Jack-Works

comment created time in 3 days

issue commenttc39/proposal-realms

fetchSourceText hook

See https://github.com/tc39/proposal-realms/issues/244#issuecomment-633180485

However, the Compartments proposal lacks any hook for retrieving the source text, so this issue is likely relevant as is for Compartments.

Jack-Works

comment created time in 3 days

issue commenttc39/proposal-realms

ExportRecord hook

See https://github.com/tc39/proposal-realms/issues/244#issuecomment-633180485

Jack-Works

comment created time in 3 days

issue commenttc39/proposal-realms

HostResolveModuleSpecifier hook

See https://github.com/tc39/proposal-realms/issues/244#issuecomment-633180485

Jack-Works

comment created time in 3 days

issue commenttc39/proposal-realms

The missing ability in the new spec (2): ES Module hook

Hi @Jack-Works,

Awhile back we had a Realms proposal that was doing too much with a single abstraction. We have since split this into separate proposals for Realms (this one), Compartments https://github.com/tc39/proposal-compartments , and SES https://github.com/tc39/proposal-ses .

https://www.youtube.com/watch?v=pMyGLmfgU5A&list=PLzDw4TTug5O3vIAd4IR1Gp5t_46co_dv9 is a good explanation of Compartments after it was separated from Realms but before it was separated from SES. However, almost all of this explanation remains valid.

The Realms proposal now is only about creating a new set of primordial intrinsics. The Compartments proposal is about customizing execution / evaluation within a Realm. This involves controlling three "namespaces" that provide the context for evaluation -- globals, imports, host hooks. Please re-file these issues there, as is relevant to the state of the Compartments proposal.

Note that many of the host hook issues may be delayed to yet another follow-on proposal. But all the hooks needed for manipulating module importing behavior will remain in the Compartments proposal.

Jack-Works

comment created time in 3 days

issue commenttc39/proposal-promise-any

Should errors be a prototype accessor that returns the value of an internal slot?

Would the same behavior be described by saying that the accessor's getter function encapsulates the object, so the same getter always returns the same object regardless of how it is called? The primordial heap has none of these getters, since it has no error instances?

If both are true, it is likely safe. But I'm glad you're not advocating this position ;)

ljharb

comment created time in 4 days

Pull request review commentAgoric/SES-shim

start to add some (manual) compatibility tests

++// alas '-r esm' vs (native) ESM means we can't import real modules if we+// start with '-r esm', so import the built distfile. Don't forget to rebuild+// this file (cd packages/ses && yarn build) after any changes to the SES+// source files.+//import { lockdown } from '../packages/ses/src/main.js';+import { lockdown } from '../packages/ses/dist/ses.cjs';++lockdown();+// We are now in the "Start Compartment". Our global has all the same+// powerful things it had before, but the primordials have changed to make+// them safe to use in the arguments of API calls we make into more limited+// compartments. 'Compartment' and 'harden' are now present in our global+// scope.

Stale comment. Compartment and harden will now already be present.

warner

comment created time in 4 days

pull request commentAgoric/Jessie

Monorepo

Given that Jessie is a separate monorepo and local-Jessie is a subset of SES, it makes sense that anything common to both local-Jessie and SES, like harden, be in Jessie and depended upon by SES. I think this would be a good move.

michaelfig

comment created time in 5 days

issue commenttc39/proposal-promise-any

Should errors be a prototype accessor that returns the value of an internal slot?

I remain opposed to an exotic internal slot holding objects. There is no precedent and it is dangerous.

On Fri, May 22, 2020 at 7:01 AM Jason Orendorff notifications@github.com wrote:

@ljharb https://github.com/ljharb wrote:

I vastly prioritize consistency with the rest of the spec here. Own properties are rare (and I think, mostly all legacy), and we should keep them that way.

This came as a bit of a surprise to me and I wonder if the committee at large agrees it's the case.

I'm OK with either outcome here, but Mozilla's reluctant to ship this feature without TC39 approving a direction.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-promise-any/issues/38#issuecomment-632705149, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACC3TCZFEQHKY6LFGCWQXTRS2ATZANCNFSM4I2OBKEQ .

-- Cheers, --MarkM

ljharb

comment created time in 5 days

PR opened Agoric/agoric-sdk

Reviewers
fix: update to new style taming options
+4 -7

0 comment

3 changed files

pr created time in 6 days

create barnchAgoric/agoric-sdk

branch : transition-to-new-lockdown-options

created branch time in 6 days

push eventAgoric/SES-shim

Mark S. Miller

commit sha 67eb6e8704386e022fbb1ff8f01beb40424d6dff

fix(326): accept old and new taming options during transition (#327)

view details

push time in 6 days

PR merged Agoric/SES-shim

Reviewers
fix(326): accept old and new taming options during transition

First step towards fixing #326 , suitable for a transitional release where we accept both old and new style taming options.

For each old noTameFoo option, replace with a fooTaming option. Where the old style was boolean defaulting to false, the new style starts with 'safe' and 'unsafe' choices, defaulting to 'safe'. This allows some options to grow further choices in the future.

+91 -69

0 comment

18 changed files

erights

pr closed time in 6 days

push eventAgoric/SES-shim

Mark S. Miller

commit sha 8cde94264bd27327e4734bfbad4f82b916364baa

fix(326): accept old and new taming options during transition

view details

push time in 6 days

push eventAgoric/SES-shim

Mark S. Miller

commit sha 8145758646f029b73330df19779e75abaf97a664

chore: add NEWS

view details

push time in 6 days

PR opened Agoric/SES-shim

fix(326): accept old and new taming options during transition

First step towards fixing #326 , suitable for a transitional release where we accept both old and new style taming options.

For each old noTameFoo option, replace with a fooTaming option. Where the old style was boolean defaulting to false, the new style starts with 'safe' and 'unsafe' choices, defaulting to 'safe'. This allows some options to grow further choices in the future.

+83 -68

0 comment

17 changed files

pr created time in 6 days

create barnchAgoric/SES-shim

branch : 326-lockdown-options-reform

created branch time in 6 days

issue openedAgoric/SES-shim

lockdown noTame options reform

Currently lockdown takes boolean options with names like noTameError, which are interpreted only as being truthy or falsy, defaulting to false.

Several problems:

Double negatives are hard to read. High cognitive load. "noTame: false" for taming. However, we still require defaults to be safe, and thus tame, and we prefer booleans to default to falsy. Suggest unsafe* rather than noTame*, especially because it reminds one of the implied risk.

On further calls to lockdown, we check that the options exactly match. This is too strict. Absent options should be taken to default to the status quo. Only present options should be required to match exactly.

Finally, the motivating case for going in and refactoring this: two choices, truthy and falsy, and sometimes not enough. In particular, to deal with various compat problems safely and unsafely, we need more options to determine how Error gets tamed.

created time in 6 days

Pull request review commentAgoric/SES-shim

fix(ses)!: Simplify transforms

 export function rejectImportExpressions(src) {  const someDirectEvalPattern = new RegExp('\\beval\\s*(?:\\(|/[/*])'); +// Exported for unit tests.

Thanks for noting that.

For all these, what is needed so that the error here could carry more context that just the line number? (not suggesting any such change for this PR though.)

kriskowal

comment created time in 6 days

pull request commentAgoric/SES-shim

ses/test - add test for prepareStackTrace override

That v8 bug will be irritating to work around, but is not a show stopper.

kumavis

comment created time in 7 days

pull request commentAgoric/SES-shim

ses/test - add test for prepareStackTrace override

Hi @kumavis I'm working on a PR that should subsume this PR and fix the incompatibility. I'll add you as a reviewer when it is ready.

On the way to fixing it, I discovered a v8 bug I just reported at https://bugs.chromium.org/p/v8/issues/detail?id=10551

kumavis

comment created time in 7 days

Pull request review commentAgoric/SES-shim

start to add some (manual) compatibility tests

++// alas '-r esm' vs (native) ESM means we can't import real modules if we+// start with '-r esm', so import the built distfile. Don't forget to rebuild+// this file (cd packages/ses && yarn build) after any changes to the SES+// source files.+//import { lockdown } from '../packages/ses/src/main.js';+import { lockdown } from '../packages/ses/dist/ses.cjs';

@warner It landed

warner

comment created time in 7 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ### Lockdown -SES introduces the `lockdown` function.-Alters the surrounding execution environment such that no object intrinsically-accessible, like the array or function prototypes (`[].prototype` or `(() =>-0).prototype`, can be replaced or subverted to attack other code in the same-execution environment; and tames other intrinsically accessible utilities like-regular expressions, random numbers, and clocks, to minimize opportunities for-malicious programs to covertly infer the behavior of other programs running in-the same execution environment.+SES introduces the `lockdown()` function.+Calling `lockdown()` alters the surrounding execution enviornment, or+**realm**, such that no two programs running in the same realm can observe or+interfere with each other until they have been introduced.++To this end, `lockdown()` freezes all objects accessible to any program in the+realm.+The set of accessible objects includes but is not limited to: `globalThis`,+`[].__proto__`, `{}.__proto__`, `(() => {}).__proto__` `(async () =>+{}).__proto__`, the properties of any accessible object, the return values of+any accessible function, and the result of using any accessible constructor.

the return values of any accessible function, and the result of using any accessible constructor.

Either I misunderstand you, or this is wrong. Calling a function or constructor can, and often does, allocate and return a fresh mutable object not locked down by lockdown(). I think just deleting that part of the sentence fixes the problem.

kriskowal

comment created time in 8 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 // See the License for the specific language governing permissions and // limitations under the License. -export { lockdown } from './lockdown-shim.js';-export { Compartment, ModuleStaticRecord } from './compartment-shim.js';+import { lockdown, harden } from './lockdown-shim.js';+import { Compartment, ModuleStaticRecord } from './compartment-shim.js';++Object.assign(globalThis, {+  lockdown,+  harden,+  Compartment,+  ModuleStaticRecord,

ok. But make sure the state as of merging this PR is consistent with itself.

kriskowal

comment created time in 9 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 export function lockdown(options = {}) {   repairLegacyAccessors();    /**-   * 4. HARDEN to share the intrinsics.+   * 3. HARDEN to share the intrinsics.    */    // Circumvent the override mistake.   const detachedProperties = enablePropertyOverrides(intrinsics);    // Finally register and optionally freeze all the intrinsics. This   // must be the operation that modifies the intrinsics.-  harden(intrinsics, registerOnly);-  harden(detachedProperties, registerOnly);+  lockdownHarden(intrinsics, registerOnly);

Yes, please do.

For a small security kernel, I'd prefer to err on the side of removing things we don't know the purpose of. Sometimes, in review, I'll know and clarify.

kriskowal

comment created time in 9 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 export function lockdown(options = {}) {   repairLegacyAccessors();    /**-   * 4. HARDEN to share the intrinsics.+   * 3. HARDEN to share the intrinsics.    */    // Circumvent the override mistake.   const detachedProperties = enablePropertyOverrides(intrinsics);    // Finally register and optionally freeze all the intrinsics. This   // must be the operation that modifies the intrinsics.-  harden(intrinsics, registerOnly);-  harden(detachedProperties, registerOnly);+  lockdownHarden(intrinsics, registerOnly);

What is registerOnly supposed to mean or do? What is it needed for?

kriskowal

comment created time in 9 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 export function lockdown(options = {}) {   repairLegacyAccessors();    /**-   * 4. HARDEN to share the intrinsics.+   * 3. HARDEN to share the intrinsics.    */    // Circumvent the override mistake.   const detachedProperties = enablePropertyOverrides(intrinsics);    // Finally register and optionally freeze all the intrinsics. This   // must be the operation that modifies the intrinsics.-  harden(intrinsics, registerOnly);-  harden(detachedProperties, registerOnly);+  lockdownHarden(intrinsics, registerOnly);

Whose source is at https://github.com/Agoric/SES-shim/blob/0e83a286dc01ee16d20434548bd8bac0faab30bc/packages/make-hardener/src/main.js#L67 which takes only one parameter?

kriskowal

comment created time in 9 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same+execution environment; and tames other intrinsically accessible utilities like+regular expressions, random numbers, and clocks, to minimize opportunities for+malicious programs to covertly infer the behavior of other programs running in+the same execution environment.  ```js-import {lockdown} from "ses";+import 'ses';++import 'my-vetted-shim';++lockdown();

my-vetted-shim is not confined; which is why it, along with any code run before lockdown(), must be vetted. IOW, all code run before lockdown() can do powerful dangerous things, creating unlimited damage to everything run afterward, including lockdown() itself.

Running before import 'ses'; vs between it and lockdown() makes only one difference: whether harden,ModuleStaticRecord,Compartment, and lockdown are available as globals.

I just looked at the shim source and confirmed that import 'ses'; by itself causes no effects other than making these available as properties on the global object and thereby as global variables.

kriskowal

comment created time in 9 days

issue openedAgoric/agoric-sdk

Are we safe from `document.all`?

See https://github.com/Agoric/SES-shim/issues/319

created time in 10 days

issue openedAgoric/SES-shim

Are we safe from `document.all`?

We often write code which assumes that the only value that can seem to be an object but actually be falsy is null, where "seems to be an object" in that case is typeof x === 'object'.

We have generally assumed we don't need to worry about document.all because SES code should never encounter it. But we either need a robust explanation of why not, or reexamine our code to ensure it is robust against encountering this bizarre value.

created time in 10 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same

Thread is at https://github.com/tc39/how-we-work/pull/84

kriskowal

comment created time in 11 days

pull request commentAgoric/SES-shim

Use test plan for compartment tests

But please wait for @Chris-Hibbert 's approval. He knows the testing issues better than I.

kriskowal

comment created time in 11 days

issue commentAgoric/SES-shim

unable to import 'tape' after lockdown

From the code you show, I think you diagnosed the tape 5 problem correctly. Is the following summary correct?

This is not the override mistake. Rather, it is an attempt to directly modify a primordial in a way that is publicly visible, that modifies the primordial API surface in a way that does not serve to shim and proposed standard. Specifically, it will make the following properties visible on the Object.assign method: getPolyfill, implementation, and shim. This is not part of any proposed standard for enhancing Object.assign. It is probably not their intention to make any such proposal. Thus, this is simply a severe bug in tape 5. We should report it to them.

If we are in a hurry to switch to tape 5, we should fork, repair, and then send them a PR citing our bug report. Otherwise we should just wait for them to fix the bug.

warner

comment created time in 11 days

issue commentAgoric/SES-shim

How does a vetted shim extend shared global variables?

It looks like tameGlobalDateObject, as called by lockdown(), will replace the global variable Date with the tamed Date constructor it creates. It looks like the Compartment shim will then correctly populate new global objects with the tame Date. However, the consequences of tameGlobalDateObject should not replace the Date on the global of the start compartment.

Similarly, tameGlobalMathObject should not modify Math in place to tame it. Rather, it should leave the original full powerful one on the global of the start compartment and arrange for all other compartments, by default, to get the tames one.

I'm adding these here because the mechanisms this taming code will use to express this probably should be related to the mechanism by which we add shimmed global to the list of new shared globals.

erights

comment created time in 11 days

issue openedAgoric/SES-shim

How does vetted shim extend shared global variables?

Every time a new compartment is created, its new global object is initialized by default with a standard set of global variable bindings hard coded in the ses whitelists. However, sometimes to purpose of a vetted shim is to add a new "standard" global that is not standard yet, that should be implicitly propagated to new globals just as Array is. It is not clear how a vetted shim should express this. For legacy vetted shims, it is even less clear how or whether we should automatically infer this.

Correlated with this, host independent vetted shims need not run in the dangerous all powerful start compartment. But they still need to run before lockdown(). Perhaps we support a pattern with user-level libraries, where a new default-powerless compartment is made to run the vetted shims in, and the globals those shims leave behind gets added to the implicitly propagated shared globals. If so, these new globals must also be included in what lockdown() locks down.

created time in 11 days

issue commentAgoric/SES-shim

Simplify intrinsic handling

Added the security label not because there is any known security vulnerability here. Rather, these whitelists are security critical, and the lack of a consistency check among them is a real hazard.

erights

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 // See the License for the specific language governing permissions and // limitations under the License. -export { lockdown } from './lockdown-shim.js';-export { Compartment, ModuleStaticRecord } from './compartment-shim.js';+import { lockdown, harden } from './lockdown-shim.js';+import { Compartment, ModuleStaticRecord } from './compartment-shim.js';++Object.assign(globalThis, {+  lockdown,+  harden,+  Compartment,+  ModuleStaticRecord,

Filed TODO as https://github.com/Agoric/SES-shim/issues/317

kriskowal

comment created time in 11 days

issue openedAgoric/SES-shim

Simplify intrinsic handling

The whole intrinsic management system now consists of nine separate files with too much redundancy, e.g., between intrinsic-names.js, intrinsic-globals.js, and whitelist.js. We should simplify, make it easier to maintain, and self-test consistency among what redundancy remains. Also, check-intrinsics.js seems vacuous. Bad edit from a previously meaningful state?

created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same+execution environment; and tames other intrinsically accessible utilities like+regular expressions, random numbers, and clocks, to minimize opportunities for+malicious programs to covertly infer the behavior of other programs running in+the same execution environment.  ```js-import {lockdown} from "ses";+import 'ses';++import 'my-vetted-shim';++lockdown();++console.log(Object.isFrozen([].prototype));+// true+```++### Harden++SES introduces the `harden` function.+*After* calling `lockdown`, the `harden` function ensures that whatever object+you give it is also transitively frozen out to the execution environments+intrinsically available objects.+This allows mutually suspicious programs in the same execution environment to+share these hardened objects knowing that the other party is limited to+interacting with the functions expressly given and cannot mutate their surfaces++```js+import 'ses';  lockdown(); +const capability = harden({+  use() {}+});++console.log(Object.isFrozen(capability));+// true+console.log(Object.isFrozen(capability.use));+// true+```++### Compartment++SES introduces the `Compartment` constructor.+A compartment is an evaluation and execution environment with its own+`globalThis` and wholly independent system of modules, but otherwise shares+the same batch of intrinsics like `Array` with the surrounding compartment.+The concept of a compartment implies the existence of a "start compartment",+the initial execution argument.++```js+import 'ses';+ const c = new Compartment({     print: harden(console.log), });  c.evaluate(`-    print("Hello! Hello?");+    print('Hello! Hello?'); `); ```  The new compartment has a different global object than the start compartment. The global object is initially mutable. Locking down the start compartment hardened many of the intrinsics in global scope.-After lockdown, no compartment can tamper with these intrinsics.+After `lockdown`, no compartment can tamper with these intrinsics. Many of these intrinsics are identical in the new compartment.  ```js

Avoid terms like "the property holds" below when you're not referring to object properties but in a context where you might be.

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same+execution environment; and tames other intrinsically accessible utilities like+regular expressions, random numbers, and clocks, to minimize opportunities for+malicious programs to covertly infer the behavior of other programs running in+the same execution environment.  ```js-import {lockdown} from "ses";+import 'ses';++import 'my-vetted-shim';++lockdown();++console.log(Object.isFrozen([].prototype));+// true+```++### Harden++SES introduces the `harden` function.+*After* calling `lockdown`, the `harden` function ensures that whatever object+you give it is also transitively frozen out to the execution environments+intrinsically available objects.+This allows mutually suspicious programs in the same execution environment to+share these hardened objects knowing that the other party is limited to+interacting with the functions expressly given and cannot mutate their surfaces++```js+import 'ses';  lockdown(); +const capability = harden({+  use() {}+});++console.log(Object.isFrozen(capability));+// true+console.log(Object.isFrozen(capability.use));+// true+```++### Compartment++SES introduces the `Compartment` constructor.+A compartment is an evaluation and execution environment with its own+`globalThis` and wholly independent system of modules, but otherwise shares+the same batch of intrinsics like `Array` with the surrounding compartment.+The concept of a compartment implies the existence of a "start compartment",+the initial execution argument.++```js+import 'ses';+ const c = new Compartment({     print: harden(console.log), });  c.evaluate(`-    print("Hello! Hello?");+    print('Hello! Hello?'); `); ```  The new compartment has a different global object than the start compartment. The global object is initially mutable. Locking down the start compartment hardened many of the intrinsics in global

Avoid the phrase "locking down the start compartment". This invites the confusion the rest of the paragraph corrects. lockdown locks down the realm, and therefore the shared intrinsics, that the start compartment shares with these other compartments.

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same+execution environment; and tames other intrinsically accessible utilities like+regular expressions, random numbers, and clocks, to minimize opportunities for+malicious programs to covertly infer the behavior of other programs running in+the same execution environment.  ```js-import {lockdown} from "ses";+import 'ses';++import 'my-vetted-shim';++lockdown();++console.log(Object.isFrozen([].prototype));+// true+```++### Harden++SES introduces the `harden` function.+*After* calling `lockdown`, the `harden` function ensures that whatever object+you give it is also transitively frozen out to the execution environments+intrinsically available objects.+This allows mutually suspicious programs in the same execution environment to+share these hardened objects knowing that the other party is limited to+interacting with the functions expressly given and cannot mutate their surfaces++```js+import 'ses';  lockdown(); +const capability = harden({+  use() {}+});++console.log(Object.isFrozen(capability));+// true+console.log(Object.isFrozen(capability.use));+// true+```++### Compartment++SES introduces the `Compartment` constructor.+A compartment is an evaluation and execution environment with its own+`globalThis` and wholly independent system of modules, but otherwise shares+the same batch of intrinsics like `Array` with the surrounding compartment.+The concept of a compartment implies the existence of a "start compartment",+the initial execution argument.

I don't think you mean "argument"

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same+execution environment; and tames other intrinsically accessible utilities like+regular expressions, random numbers, and clocks, to minimize opportunities for+malicious programs to covertly infer the behavior of other programs running in+the same execution environment.  ```js-import {lockdown} from "ses";+import 'ses';++import 'my-vetted-shim';++lockdown();++console.log(Object.isFrozen([].prototype));+// true+```++### Harden++SES introduces the `harden` function.+*After* calling `lockdown`, the `harden` function ensures that whatever object+you give it is also transitively frozen out to the execution environments

"transitively frozen" always causes confusion, it that people mistake it as being about immutability. We must always be clear that it is only transitive across own property traversal, in order to hide API surface. You do mention "surface" here but without a bit more context it is not clear what you mean.

Your example below perfectly illustrates what is frozen by harden. Perhaps have use close over a variable it mutates, so you can explain what is not suppressed by harden?

Then link to wherever we have a more complete explanation of harden including its consistency check against of the [[Prototype]] properties.

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same+execution environment; and tames other intrinsically accessible utilities like+regular expressions, random numbers, and clocks, to minimize opportunities for+malicious programs to covertly infer the behavior of other programs running in+the same execution environment.  ```js-import {lockdown} from "ses";+import 'ses';++import 'my-vetted-shim';++lockdown();++console.log(Object.isFrozen([].prototype));+// true+```++### Harden++SES introduces the `harden` function.+*After* calling `lockdown`, the `harden` function ensures that whatever object+you give it is also transitively frozen out to the execution environments

environment's

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same+execution environment; and tames other intrinsically accessible utilities like+regular expressions, random numbers, and clocks, to minimize opportunities for+malicious programs to covertly infer the behavior of other programs running in+the same execution environment.  ```js-import {lockdown} from "ses";+import 'ses';++import 'my-vetted-shim';++lockdown();++console.log(Object.isFrozen([].prototype));

[].__proto__

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same

It is not .prototype. It is .__proto__ or Object.getPrototypeOf or Reflect.getPrototypeOf.

Pedantic note that shouldn't affect this README.md:

In some thread elsewhere @caridy points out that these means of ascending the prototype chain are deniable in theory. But we all agreed they are not practically deniable. @ljharb pointed out that one undeniable, %ThrowTypeError% is obtained only by accessing the getter property of a property descriptor. This again is deniable in theory. So we're left with "reachable by syntax combined with universal reflective operations, like accessing [[Prototype]] or accessing a property getter". Fortunately, this README need not be that precise about undeniability.

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same+execution environment; and tames other intrinsically accessible utilities like+regular expressions, random numbers, and clocks, to minimize opportunities for+malicious programs to covertly infer the behavior of other programs running in+the same execution environment.  ```js-import {lockdown} from "ses";+import 'ses';++import 'my-vetted-shim';++lockdown();

Nice!

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>+0).prototype`, can be replaced or subverted to attack other code in the same+execution environment; and tames other intrinsically accessible utilities like+regular expressions, random numbers, and clocks, to minimize opportunities for+malicious programs to covertly infer the behavior of other programs running in

"infer or interfere"

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 npm install ses  ## Usage -### Module+### Lockdown -This example locks down the current realm, turning it into a starting-compartment.-Within a compartment, there is a `Compartment` constructor that conveys-"endownments" into the new compartment's global scope, and a `harden` method-that that object and any object reachable from its surface.-The compartment can import modules and evaluate programs.+SES introduces the `lockdown` function.+Alters the surrounding execution environment such that no object intrinsically+accessible, like the array or function prototypes (`[].prototype` or `(() =>

We've been using the term "undeniable". "undeniably accessible" isn't great. But "intrinsically accessible" has no clear meaning. Better phrase appreciated.

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 function assert(condition, message) {   }

Why not import this from assert.js? It is currently identical, and it will make it easy to upgrade all occurrences to the new assert system when it is time to do that.

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 // See the License for the specific language governing permissions and // limitations under the License. -export { lockdown } from './lockdown-shim.js';-export { Compartment, ModuleStaticRecord } from './compartment-shim.js';+import { lockdown, harden } from './lockdown-shim.js';+import { Compartment, ModuleStaticRecord } from './compartment-shim.js';++Object.assign(globalThis, {+  lockdown,+  harden,+  Compartment,+  ModuleStaticRecord,

All shimmed pervasively global names must be added to the appropriate whitelists. I don't see lockdown and ModuleStaticRecord (or StaticModuleRecord) in intrinsic-names.js

I do see ModuleStaticRecord in intrinsic-globals.js, but I don't see lockdown there.

lockdown missing from whitelist.js as well.

We should have a test that fails on such omission, because it is an easy mistake to keep making.

TODO(markm): the whole intrinsic management system now consists of nine separate files with too much redundancy, e.g., between intrinsic-names.js, intrinsic-globals.js, and whitelist.js. We should simplify, make it easier to maintain, and self-test consistency among what redundancy remains. Also, check-intrinsics.js seems vacuous. Bad edit from a previously meaningful state?

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 export function lockdown(options = {}) {   repairLegacyAccessors();    /**-   * 4. HARDEN to share the intrinsics.+   * 3. HARDEN to share the intrinsics.    */    // Circumvent the override mistake.   const detachedProperties = enablePropertyOverrides(intrinsics);    // Finally register and optionally freeze all the intrinsics. This   // must be the operation that modifies the intrinsics.-  harden(intrinsics, registerOnly);-  harden(detachedProperties, registerOnly);+  lockdownHarden(intrinsics, registerOnly);

Where is this harden (aka lockdownHarden) function that takes a second parameter? I couldn't find it.

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Surface SES on globalThis

 User-visible changes in SES:  ## Next release +* Adds support for modules to Compartments.+* SES no longer exports anything. `Compartment`, `ModuleStaticRecord`,+  `lockdown`, and `harden` are all introduced as properties of `globalThis`. * Repair `Function.apply` and `TypeError.message` (as well as `.message` on   all the other Error types), to tolerate what the npm `es-abstract` module   does. This allows `tape` (version 4.x) to be loaded in a locked-down SES

Please make the reference to #293 a markdown link to https://github.com/Agoric/SES-shim/issues/293

kriskowal

comment created time in 11 days

Pull request review commentAgoric/SES-shim

Rename compartment.global to globalThis

 export const FunctionInstance = {   // since prototpye properties are instance-specific, we define it there. }; +export const AsyncFunctionInstance = {

Please put in spec citations parallel to FunctionInstance

kriskowal

comment created time in 12 days

Pull request review commentAgoric/SES-shim

Rename compartment.global to globalThis

 export default {   CompartmentPrototype: {     constructor: 'Compartment',     evaluate: fn,-    global: getter,+    globalThis: getter,+    import: asyncFn,

This points out that it is not purely an implementation decision whether to use a function or an async function here. The comment in FunctionInstance above also reminds me that shimmed-standard methods, whether async or not, need to be defined using concise method syntax, or, if not this sensitive, arrow syntax. They should not be defined using function syntax since we don't want a contruct behavior or a prototype property.

Whether this method is observably async or not needs to parallel how we want to spec it. Does the current draft spec take a position?

kriskowal

comment created time in 12 days

pull request commentAgoric/SES-shim

add enablements to fix tape-4.x

Not in this pr. I’ll take this on afterwards

warner

comment created time in 12 days

Pull request review commentAgoric/SES-shim

Support Compartment.import

 export class Compartment {     });

Line 154 talks about x as an option, but it is actually a mandatory positional parameter on like 156.

On line 156, why is it named x?

kriskowal

comment created time in 12 days

more