DEV Community: naugtur

Is this my last meet.js Summit?

naugtur — Mon, 26 Jan 2026 14:07:51 +0000

Betteridge's Law of Headlines
states that any headline ending in a question mark can almost always be answered with "no".

https://summit.meetjs.pl/2026/

But it's how I'm thinking about it here and now. As the last meet.js Summit in that shape and format I'll ever organize. A 1-day conference that in the pre-covid world was so easy to pull off that even the clueless me could do it.
(acknowledgement: it was never just me, it was a team effort, and I was the main organizer of only 3 out of 9 - seems like I take 4 years to recover before I want to organize another one again)

Back when I organized my first two, getting sponsors was a matter of sending 15 emails to get half of them to join.
In 2018 I partnered with a charity for the first time to do the ticket sales. Based on feedback from previous years the main problem with tickets was that they ran out too fast. We had to come up with tricks to prevent selling out in 2h.
Getting a 50% discount on a venue to sit 500 was a matter of asking and mentioning it's for charity.

Coming back after covid I almost cancelled the 2022 one. A month before the event we didn't even sell 200 out of the 500 tickets we had. Turns out that's the new reality.

I think we're witnessing the dawn of the local conference. Not because there's no need for them. People still benefit tremendously from physically getting together with other nerds. It's getting easier for the ones who understand that to go to one of the biggest popular conferences abroad. Meanwhile, the conference budgets at companies are getting cut and the expectations are changing.

So while it's great to band together with some incredible people and organize one last Summit - single track, one day celebration of being together with hundreds of other devs, 15 years into the existence of meet.js - I can already see it changing.

Instead of creating a platform for local speakers to shine, we're trying to create an agenda that will be the most useful for attendees in the new circumstances. (Don't worry, we'll have local speakers and they'll shine)
Instead of announcing it and letting the news spread organically, we're doing social media and marketing (well, not me, I still suck at these)
Instead of doing just talks, we're trying other formats.

This Summit will be special, with the hit of nostalgia and pride in how long it all lasted. I hope to see everyone once again, before we finally wrangle AI or it eats us and our neat programming hobby.

If you've been skipping on events for a while because life or kids or you don't feel like it anymore - this is the one time to break the habit and go. If enough of us do it, it'll be a real reunion.

And that's the biggest expectation that this event is aiming to fulfill. But it's an expectation that's not on the organizers to take care of. So good luck to you I guess.

This post might grow in time. Come back in a few days.

Don't we all look forward to code-review full time?

naugtur — Sat, 17 Jan 2026 21:15:36 +0000

I remember the time when getting your tests to pass and finishing up a pull request was not even half the calendar time it took to ship code because it had to be reviewed. And getting a review was not trivial. Somehow everyone wanted to do other things and convincing them to review a pull request was part of doing the work.

Wait, that was yesterday!

Now with coding agents producing up to an order of magnitude more code it's not a problem though, because we've suddenly fell in love with the process of reviewing code. Right? Right...?

I mean, isn't it dreadful that you not only have to do code review for your peers but also for what you're making now too?

But why is reviewing code not sparking the same joy as writing it?

There's many reasons, but I want to focus on one. The friction in building the mental model.

The process of understanding how code works is really one of building a mental model that represents the logic encoded in the program. Mental models are structures. Building a structure "from the ground up" is much easier than floating bits in space until it's rigid, if we take a physical metaphor. And that's my point - reading the code of a finished changeset is much less convenient for creating a mental model than experiencing various fragments of code going together in a reasonable order.

Which brings me to my point - AI coding agents would be much better if they gave us the experience of a pair programmer instead of an experience of an intern turning in every result as if it was a take-home assignment.

So imagine giving the agent a prompt or a spec and instead of getting a non-stop flow of tokens appear in the project files, being told a relatable story of how the logic flows through the change.

Code appearing in a logical order, with live spoken commentary. You don't have to read 2 places at once. Human modalities (reading and listening) are utilized optimally.

Let's start by creating the function with its arguments and defining input types.

Now we're adding validation same as the function above

Since that's reusable, let's extract it to the utils file

We're now implementing the functionality split into 3 steps.

Step 1 will call out to the implementation over there...

That sort of presentation of the code would not only match the natural process in which the human builds the mental model, it would also eliminate the context switching and distractions creeping in while the agent is working.

It should also scale to orchestrating multiple agents, where the work progresses while the leading agent schedules the work, controls the results and enqueues the walkthrough/explanation for the human in the loop.

And then the obvious next step is to handle instant feedback and discussion, like a peer programmer would.

I hope someone build this :D

The missing link

naugtur — Tue, 23 Sep 2025 16:21:04 +0000

Here's a riddle I posted

Name the environment in which this code doesn't throw


let w = globalThis
if (!('addEventListener' in globalThis)) throw Error()
while (w) {
    if (Object.hasOwn(w, 'addEventListener')) throw Error()
    w = Object.getPrototypeOf(w)
}
alert('where are we?')

What's in the script

The script first ensures that addEventListener is in globalThis. But in means as own property or anywhere on the prototype. So let's find it on the prototype by iterating down. We throw when found.
Somehow, we run out of truthy prototypes before we find one that has an own property named addEventListener.
Last - as a helpful tip, the code uses alert and it works.

What's the environment

Normally, when you run:

let w = globalThis
while (w) {
  if (Object.hasOwn(w, 'addEventListener')) {
    console.log(`${w} has addEventListener`)
  } else {
    console.log(`${w} does NOT have addEventListener`)
  }
  w = Object.getPrototypeOf(w)
}

the output is:

[object Window] does NOT have addEventListener
[object Window] does NOT have addEventListener
[object WindowProperties] does NOT have addEventListener
[object EventTarget] has addEventListener
[object Object] does NOT have addEventListener

But there's one magical place in the browser where that's not necessarily the case.

When you create an extension, you can define a contentscript that exists to let you interact with the document of a website open in the browser. It's supposed to be isolated from the website's realm though, so that you have your own global context.

The browsers took very different approaches to implementing the isolation. The Firefox implementation is changing the prototype chain of the global and limiting it to window and its prototype, with nothing else visible via code, but with field lookup reaching down the prototype chain further.

The same while loop gets us this:

[object Window] does NOT have addEventListener
[object Window] does NOT have addEventListener

But still,

('addEventListener' in window) === true
typeof window.addEventListener === 'function'

I'm not sure why the behavior is like that, but if I replace globalThis with window, I get a different list of prototypes

[object Window] does NOT have addEventListener
[object Window] does NOT have addEventListener
[object EventTarget] does NOT have addEventListener
[object EventTarget] has addEventListener
[object Object] does NOT have addEventListener

And while I can understand cutting of a bit of prototype as a means of isolation, if it stays on window, that's harder to explain.

Somebody tell me what's going on :)

update

So we've established that in Firefox contentscript this is true:

globalThis !== window

When using devtools, if you look into the globalThis reference, it's being called Sandbox.

For my usecase I was tempted to do globalThis = window and move on, but that doesn't work. globalThis.globalThis = window does have the expected result of replacing globalThis tho :D

I didn't do it yet, because I don't know how much I'd break with it.

I will keep updating this

Sometimes the best thing to do is an explicit nothing

naugtur — Wed, 27 Aug 2025 09:07:34 +0000

This is a long story about why I wrote this line:

window.event = window.event

react-dom under LavaMoat

While working on getting a project to work under @lavamoat/webpack I stumbled upon an issue where the whole thing would hang in Firefox (on my colleague's mac it would hang the entire browser)
After a bunch of inspector sorcery I found out that the app is throwing TypeError: can't redefine non-configurable property "event" faster than the browser can put together stacktraces for the errors.

The culprit for that was a line in react-dom

It's worth noting that contrary to what the comment says, Firefox implemented window.event in 2019 so me finding this takes me a step closer to an Archeology major.
Did I mention window.event is deprecated?

But why are we getting an error in Firefox and not in Chrome despite them both implementing window.event ?

The emulation LavaMoat does

This section assumes you already know basics of what LavaMoat does from lavamoat.github.io

When providing a new global for each package with just the specified fields, we need to make sure that they actually work. And in the browser it's fairly common to have fields on window that demand being on window because there's hidden "internal slots" on the objects the functions check.

What?

Let me explain with a code snippet

const a = { fetch }
a.fetch('/')
// TypeError: Failed to execute 'fetch' on 'Window': Illegal invocation

Some functions demand that their this is the window. But the whole point of LavaMoat is to not give the real window with all globals to every package in dependencies.

So we need to give packages functions that wrap around functions and get/set pairs to then internally unwrap to run the actual native implementation with the right this.

So far so good.

But then there's scuttling.

In case a package gets enough references passed to it that it can reach the real window, after LavaMoat makes copies of all globals it's destroying everything on the actual globalThis by replacing it with a non-configurable getter that throws an error.

Cool, huh?

So that leaves us with react-dom running under LavaMoat with a policy that allows it write to window.event while the real window.event is long gone. Why the error tho?

window.event behavior

window.event is implemented with a setter that replaces itself with the value first time it's called. Why? Don't ask me, I didn't come up with it.

Let me repeat that in JavaScript in case you know it better than English ;)

Object.defineProperty(window, 'event', {
    set(value) {
      Object.defineProperty(this, 'event', { value })
    },
    configurable: true,
  })

When we replace the original setter with the scuttling one (that's set to be configurable: false) the original setter (that we still have a copy of) will fail to overwrite the value.

Again, let me repeat that in JavaScript:

const es = Object.getOwnPropertyDescriptor(window, 'event').set
Object.defineProperty(window, 'event', { value:{a:1}, configurable: false })
Reflect.apply(es, window, [{a:2}])

This fails silently in Chrome and loudly in FF

Conclusion

If spec was supposed to cover all details of the standard implementation it would have to go into detail infinitely.

Wait, what?

How is that a conclusion?

Ok, last step you need before you'll understand.

These are the setters in Chrome and Firefox respectively

Can you spot the difference between the two setters?

🎉 The one with arguments and caller is a sloppy mode function, so when it fails a defineProperty, it doesn't throw. 🎉

And this tiny detail in an implementation of an old deprecated property that react-dom keeps alive in its codebase in case someone uses a 20+ years old event handler in react is enough to make an entire project explode in one browser and work in another.

Takes me back to the early 2000s

Conclusion, for real this time

Now if you look at this line again, you should know what happens.

window.event = window.event

a getter is called on event
its return value is passed to the setter
the setter replaces window.event with a value property
LavaMoat sees a value and avoids wrapping/unwrapping it at all
when code in a package does window.event = {} it won't leak to the real global

Update

I defaulted to assign the current value to the window.event to minimize the fragility if it becomes something else in the future. After some conversations under the links to this I posted to socials I think I'll go with window.event = undefined for LavaMoat, because there's a risk that it might capture an actual event object with references I don't want available to some of the packages.

All ways to get a DOM element reference

naugtur — Wed, 21 May 2025 12:07:48 +0000

An attempt to build a complete list of all the ways a DOM node could be created or accessed.

A study in ambient authority

The target audience of this post is mostly my future self. No warranty of any kind, no claims this is complete.

Also, note that Gal Weizman probably has more comprehensive research on the topic but this is intentionally dense and narrow in scope. Also, it's easier for me to dig up my post than message Gal.

Creating DOM nodes

// Standard API
document.createElement('div');

// Namespaced element
document.createElementNS('http://www.w3.org/1999/xhtml', 'div');

// HTML parsing APIs
(new DOMParser()).parseFromString('<div></div>', 'text/html').body.firstChild;

// Range API
document.createRange().createContextualFragment('<div></div>').firstChild;

// Template element
Object.assign(document.createElement('template'), {innerHTML: '<div></div>'}).content.firstChild;

// iframe with srcdoc (creates a new DOM tree)
let iframe = document.createElement('iframe'); iframe.srcdoc = '<div></div>'; // access via iframe.contentDocument.body.firstChild

// XSLTProcessor (rare, but possible)
let xslt = (new DOMParser()).parseFromString(
  `<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
     <xsl:template match="/"><div xmlns="http://www.w3.org/1999/xhtml"/></xsl:template>
   </xsl:stylesheet>`, 'application/xml');
let processor = new XSLTProcessor(); processor.importStylesheet(xslt);
processor.transformToFragment(document.implementation.createDocument('', '', null), document);

// document.implementation.createDocument (XML, but can create elements)
document.implementation.createDocument('http://www.w3.org/1999/xhtml', 'div').documentElement;

// document.implementation.createHTMLDocument
document.implementation.createHTMLDocument().createElement('div');

// Custom Elements (constructor, if not banned)
class MyDiv extends HTMLDivElement {}; customElements.define('my-div', MyDiv, {extends: 'div'}); new MyDiv();

// Using importNode (cloning from another document)
let doc = document.implementation.createHTMLDocument(); let div = doc.createElement('div'); document.importNode(div, true);

// Using cloneNode on a template
document.createElement('template').content.cloneNode(true).appendChild(document.createElement('div'));

Finding existing DOM nodes

// Standard selectors
document.getElementById('myDiv');
document.getElementsByClassName('myClass')[0];
document.getElementsByTagName('div')[0];
document.getElementsByName('myDivName')[0];
document.querySelector('div');
document.querySelectorAll('div')[0];

// Traversal APIs
document.body.firstChild;
document.body.lastChild;
document.body.childNodes[0];
document.body.children[0];
document.body.parentNode;
document.body.nextSibling;
document.body.previousSibling;
document.body.nextElementSibling;
document.body.previousElementSibling;

// TreeWalker
document.createTreeWalker(document.body, NodeFilter.SHOW_ELEMENT).nextNode();

// NodeIterator
document.createNodeIterator(document.body, NodeFilter.SHOW_ELEMENT).nextNode();

// Range API
let range = document.createRange(); range.selectNode(document.body); range.startContainer;

// Event target (from an event handler)
document.body.addEventListener('click', e => { let node = e.target; });

// Shadow DOM
let shadow = document.body.attachShadow({mode: 'open'}); shadow.host;

// Selection API
window.getSelection().anchorNode;

// Active element
document.activeElement;

// OwnerDocument
document.body.ownerDocument;

// ParentNode API
document.body.closest('html');

// Custom Elements (via lifecycle callbacks)
customElements.define('my-div', class extends HTMLElement {
  connectedCallback() { let node = this; }
});

// HTMLCollection/NodeList iteration
for (let node of document.body.children) { /* node is a reference */ }

// iframe content
let iframe = document.querySelector('iframe'); iframe.contentDocument.body;

// window.frameElement
window.frameElement;

// document.currentScript
document.currentScript;

// document.scripts
document.scripts[0];

// document.forms, document.images, document.links, document.anchors
document.forms[0];
document.images[0];
document.links[0];
document.anchors[0];

// document.head, document.body, document.documentElement
document.head;
document.body;
document.documentElement;

// document.defaultView (returns window, but can access DOM via window.document)
document.defaultView.document.body;

// document.adoptNode (returns a reference to the adopted node)
let node = document.createElement('div'); document.adoptNode(node);

// document.importNode (returns a reference to the imported node)
let node2 = document.createElement('div'); document.importNode(node2);

// document.elementFromPoint
document.elementFromPoint(0, 0);

// document.elementsFromPoint
document.elementsFromPoint(0, 0)[0];

// document.scrollingElement
document.scrollingElement;

// document.pointerLockElement
document.pointerLockElement;

// document.fullscreenElement
document.fullscreenElement;

// document.getRootNode
document.body.getRootNode();

// document.getSelection
window.getSelection().focusNode;

// MutationObserver (callback receives references to added/removed nodes)
new MutationObserver((mutations) => { mutations.forEach(m => m.addedNodes[0]); }).observe(document.body, {childList: true});

// CSSStyleSheet.ownerNode
document.styleSheets[0].ownerNode;

// HTMLTableElement.rows/cells
document.querySelector('table').rows[0].cells[0];

// HTMLFormElement.elements
document.querySelector('form').elements[0];

// HTMLSelectElement.options
document.querySelector('select').options[0];

// HTMLMapElement.areas
document.querySelector('map').areas[0];

// HTMLMediaElement.textTracks/cues
document.querySelector('video').textTracks[0].cues[0];

// SVG-specific: getElementById, getElementsByTagName, etc. on SVGSVGElement
document.querySelector('svg').getElementById('svgDiv');

// XPath
document.evaluate('//div', document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue;

Globally Available DOM API Types

Core Node Types

Node
Element
Document
DocumentFragment
Text
Comment
CDATASection // XML documents only
ProcessingInstruction
DocumentType
Attr

Element Subclasses

HTML Elements (all inherit from `HTMLElement`)

HTMLElement
HTMLAnchorElement
HTMLAreaElement
HTMLAudioElement
HTMLBaseElement
HTMLBodyElement
HTMLBRElement
HTMLButtonElement
HTMLCanvasElement
HTMLDataElement
HTMLDataListElement
HTMLDetailsElement
HTMLDialogElement
HTMLDivElement
HTMLDListElement
HTMLEmbedElement
HTMLFieldSetElement
HTMLFormElement
HTMLHeadingElement
HTMLHeadElement
HTMLHRElement
HTMLHtmlElement
HTMLIFrameElement
HTMLImageElement
HTMLInputElement
HTMLLabelElement
HTMLLegendElement
HTMLLIElement
HTMLLinkElement
HTMLMapElement
HTMLMetaElement
HTMLMeterElement
HTMLModElement
HTMLOListElement
HTMLObjectElement
HTMLOptGroupElement
HTMLOptionElement
HTMLOutputElement
HTMLParagraphElement
HTMLParamElement
HTMLPictureElement
HTMLPreElement
HTMLProgressElement
HTMLQuoteElement
HTMLScriptElement
HTMLSelectElement
HTMLSlotElement
HTMLSourceElement
HTMLSpanElement
HTMLStyleElement
HTMLTableCaptionElement
HTMLTableCellElement
HTMLTableColElement
HTMLTableElement
HTMLTimeElement
HTMLTitleElement
HTMLTableRowElement
HTMLTableSectionElement
HTMLTemplateElement
HTMLTextAreaElement
HTMLTrackElement
HTMLUListElement
HTMLUnknownElement
HTMLVideoElement

SVG Elements (all inherit from `SVGElement`)

SVGElement
SVGSVGElement
SVGCircleElement
SVGClipPathElement
SVGDefsElement
SVGEllipseElement
SVGFEBlendElement
SVGFEColorMatrixElement
SVGFEComponentTransferElement
SVGFECompositeElement
SVGFEConvolveMatrixElement
SVGFEDiffuseLightingElement
SVGFEDisplacementMapElement
SVGFEDistantLightElement
SVGFEDropShadowElement
SVGFEFloodElement
SVGFEFuncAElement
SVGFEFuncBElement
SVGFEFuncGElement
SVGFEFuncRElement
SVGFEGaussianBlurElement
SVGFEImageElement
SVGFEMergeElement
SVGFEMergeNodeElement
SVGFEMorphologyElement
SVGFEOffsetElement
SVGFEPointLightElement
SVGFESpecularLightingElement
SVGFESpotLightElement
SVGFETileElement
SVGFETurbulenceElement
SVGFilterElement
SVGForeignObjectElement
SVGGElement
SVGImageElement
SVGLineElement
SVGLinearGradientElement
SVGMarkerElement
SVGMaskElement
SVGPathElement
SVGPatternElement
SVGPolygonElement
SVGPolylineElement
SVGRadialGradientElement
SVGRectElement
SVGStopElement
SVGSwitchElement
SVGSymbolElement
SVGTSpanElement
SVGTextElement
SVGTextPathElement
SVGTitleElement
SVGUseElement
SVGViewElement

MathML Elements

MathMLElement

Document Types

HTMLDocument
XMLDocument
SVGDocument

Other DOM-Related Classes

CharacterData
Range
Selection
MutationObserver
MutationRecord
TreeWalker
NodeIterator
NamedNodeMap
DOMTokenList
DOMStringMap
DOMRect
DOMRectList
DOMPoint
DOMPointReadOnly
DOMMatrix
DOMMatrixReadOnly
DOMParser
XMLSerializer
XPathEvaluator
XPathResult
XPathExpression

NodeList/Collections

NodeList
HTMLCollection
HTMLAllCollection
HTMLFormControlsCollection
HTMLOptionsCollection
SVGLengthList
SVGNumberList
SVGPointList
SVGStringList
SVGTransformList

Attribute/Style/Other

Attr
NamedNodeMap
CSSStyleDeclaration
StyleSheet
CSSStyleSheet
CSSRuleList
CSSRule

Miscellaneous

Comment
Text
ProcessingInstruction
CDATASection
DocumentType
ShadowRoot
DocumentFragment

Event Classes

(tend to have references to DOM)

Event
CustomEvent
UIEvent
MouseEvent
KeyboardEvent
FocusEvent
InputEvent
TouchEvent
PointerEvent
WheelEvent
CompositionEvent
DragEvent
ClipboardEvent
AnimationEvent
TransitionEvent
PopStateEvent
HashChangeEvent
PageTransitionEvent
ProgressEvent
StorageEvent
MessageEvent
ErrorEvent
PromiseRejectionEvent

Same but with inheritance depicted

graph TD

  %% Inheritance
  EventTarget -->|inherits| Node
  EventTarget -->|inherits| Window
  EventTarget -->|inherits| XMLHttpRequest
  EventTarget -->|inherits| EventSource
  EventTarget -->|inherits| WebSocket
  EventTarget -->|inherits| Worker
  EventTarget -->|inherits| MessagePort
  EventTarget -->|inherits| BroadcastChannel
  EventTarget -->|inherits| FileReader
  EventTarget -->|inherits| MediaStream
  EventTarget -->|inherits| MediaRecorder
  EventTarget -->|inherits| RTCPeerConnection
  EventTarget -->|inherits| Event

  Node -->|inherits| Document
  Node -->|inherits| DocumentFragment
  Node -->|inherits| Element
  Node -->|inherits| Text
  Node -->|inherits| Comment
  Node -->|inherits| CDATASection
  Node -->|inherits| ProcessingInstruction
  Node -->|inherits| DocumentType
  Node -->|inherits| Attr

  CharacterData -->|inherits| Text
  CharacterData -->|inherits| Comment
  CharacterData -->|inherits| CDATASection

  Document -->|inherits| XMLDocument
  Document -->|inherits| HTMLDocument
  Document -->|inherits| SVGDocument

  Element -->|inherits| SVGElement
  Element -->|inherits| MathMLElement
  Element -->|inherits| HTMLElement

  DocumentFragment -->|inherits| ShadowRoot

  %% Aggregation/Fields

  NodeList -- "item[]" --> Node
  HTMLCollection -- "item[]" --> Element
  NamedNodeMap -- "item[]" --> Attr
  DOMTokenList -- "item[]" --> string
  DOMStringMap -- "item[]" --> string

  Range -- "startContainer" --> Node
  Range -- "endContainer" --> Node

  Selection -- "anchorNode" --> Node
  Selection -- "focusNode" --> Node

  MutationRecord -- "target" --> Node
  MutationRecord -- "addedNodes" --> NodeList
  MutationRecord -- "removedNodes" --> NodeList

  TreeWalker -- "root" --> Node
  TreeWalker -- "currentNode" --> Node

  NodeIterator -- "root" --> Node
  NodeIterator -- "referenceNode" --> Node

  ShadowRoot -- "host" --> Element

  Attr -- "ownerElement" --> Element

  Document -- "documentElement" --> Element
  Document -- "body" --> Element
  Document -- "head" --> Element

  Element -- "attributes" --> NamedNodeMap
  Element -- "children" --> HTMLCollection
  Element -- "classList" --> DOMTokenList
  Element -- "dataset" --> DOMStringMap

  DocumentFragment -- "childNodes" --> NodeList

  %% Miscellaneous
  DOMRectList -- "item[]" --> DOMRect
  CSSRuleList -- "item[]" --> CSSRule
  StyleSheet -- "ownerNode" --> Node
  CSSStyleSheet -- "ownerNode" --> Node

  %% Standalone classes (not directly connected)
  DOMRect
  DOMPoint
  DOMPointReadOnly
  DOMMatrix
  DOMMatrixReadOnly
  DOMParser
  XMLSerializer
  XPathEvaluator
  XPathResult
  XPathExpression

A Phish on a Fork, no Chips

naugtur — Wed, 29 Jan 2025 19:30:55 +0000

So you were told that this is the safest way to install a package from github with npm:

"test262": "git+https://github.com/tc39/test262.git#f1ffb1e95fad3468a771a6753595db4e6f55f6bb",

and this is the safest way to install an action:

uses: actions/checkout@47176dbabcf093ccbef4a6689f7c80eb4c7693d6 # v4

That's a very good recommendation.

Because commit hashes are practically globally unique, the maintainer can't make any changes to what you'll get (like they would if you used #branch or #tag)

There's one thing you need to look out for as you update the commit hashes though.

𐂐 The fork

Both examples above will happily install and work even though the commit hashes you see actually exist in forks I made, not the original repositories.

🐟 The phish

find a popular repository that gets installed as a package by package managers or as a GitHub Action.
fork it and introduce ~~malware~~ opinionated improvements
add another commit that looks like a proper version update
find the security-minded users who have been told that it's best to pin the version to the specific commit hash
offer an update to latest, but put your own commit hash in the PR
🍿

It's a phish on a fork, see?

The rest of this piece explains the problem and offers tools to avoid the risks. Scroll to the bottom to learn what to use.

The full story

Remember how git commits are now hashed with sha256 because sha1 had collisions you could generate if you could get your hands on a bunch of compute?

In case you're into tech history rabbit holes:

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

http://web.archive.org/web/20120701221418/http://kerneltrap.org/mailarchive/git/2006/8/28/211065

https://github.blog/news-insights/company-news/sha-1-collision-detection-on-github-com/

Anyway..

sha256 has 2^256 possible hashes. That is about 10^78. There's about 10^80 atoms in the Observable Universe. Git commit hashes are practically globally unique.

And that's great for a lot of reasons.

I'd like to explore one of these.

GitHub is storing an unbelievable number of git repositories. The more popular ones get forked tens of thousands of times. Imagine copying the entire history and structure of the repository for every fork!

Thanks to the uniqueness of commit IDs, you only ever need to store each one once. Regardless of whether it's in the original or a forked repo, the content of the commit with that specific ID will always be the same.

What a great optimization! Without it, the fork and PR workflow would not have been possible!

That also means if you try to load a commit hash from a repo, GitHub will not differentiate between your repo and a fork when fetching it from the database.

This has caused issues before, like when youtube-dl folks confused everyone into thinking GitHub source code was published to the DMCA repo

🍟 The chip

As a remediation, GitHub has introduced a warning chip in the UI so that if you go to a repository and put commit ID from a fork in the URL you get a hint something's not right.

e.g. This is what UI shows for my fork of the checkout action

https://github.com/actions/checkout/commit/47176dbabcf093ccbef4a6689f7c80eb4c7693d6

I know calling it a chip is a bit of a stretch but it makes for a nice pun in the article title and hardcore designers are not my target audience.

I don't have to tell you that package installation doesn't have much UI space to work with, which results in no warning there, so you don't get the chip.

Would you like to see a warning? Keep reading.

Avoiding the phish on a fork

You could take every commit ID and put it in the URL for the repository you expected to install from and check whether the warning chip shows. But I've been involved in software security long enough to know you won't.

People often lack the patience to review security risk warnings even if they're provided to them inline, in the PR they're working on approving. I doubt they'd be willing to get out of their way to put together the URL they need to look up.

🍣 A solution that, ehm, scales 🫣

Cringe all you want, I'll squeeze the last drop out of this pun.

So I found out how GitHub decides whether to show the chip, added all other ~~hatered~~ best practices I have for using git dependencies and created this tool

Credit for the git-safe name goes to Leo

Curious to know what it can do? Are you hooked?

Ok, ok. I'll stop now.

The `@lavamoat/git-safe-dependencies` validator

What does it do? (as of Jan 2025)

Current version supports processing your package.json and lockfile as one command and a separate one for scanning workflow yaml files.

validates you only directly depend on git repos and actions pinned to commit id (GH workflows, package.json direct dependencies)
validates that commit id belongs to the repository you intended to install from for both direct and transitive dependencies (lockfile, workflows)
makes sure resolved URL in lockfile matches pakcage.json (prevents tampering with lockfile)
complains if the git URL is not pointing to GitHub (lockfile)

What do I want to add?

warning if the package name matches a package that exists on npm
warning if the git dependency is trying to run scripts on install

It's all free and opensource. Like all other protections that we build at LavaMoat.

Git safe friends! 🫡

How private are your class #private fields?

naugtur — Fri, 02 Aug 2024 09:38:09 +0000

The word "private" is defined as:

belonging to or for the use of one particular person or group of people only.

Let's figure out who those people are.

EcmaScript Class

class MyClass {
  #privateField;

  constructor(value) {
    this.#privateField = value;
  }

  getPrivate(otherInstance) {
    return otherInstance.#privateField;
  }
}

const a = new MyClass("AA");
const b = new MyClass("BB");

console.log(a.getPrivate(b)); // BB

In native classes the private reference belongs to the class and every instance of that class can access other instances' private field values.

Ok, so this is fine. All I need to do to avoid giving away my private fields is to not have a method that uses them from a reference given to me in input.

Well, yes, but this reference is also input to functions in JavaScript

class MyClass {
  #privateField;

  constructor(value) {
    this.#privateField = value;
  }

  getMyPrivate() {
    return this.#privateField;
  }
}

const a = new MyClass("AA");
const b = new MyClass("BB");

console.log(a.getMyPrivate()); // AA
console.log(b.getMyPrivate.bind(a)()); // AA

Would type-checking help?

Let's take a look at a similar example in TypeScript.

Our adversary is trying to read private fields from our classes at runtime. All type safety is resolved at compile time though.
Let me remind you what a wise man once said:

TypeScript is a seatbelt you wear while the car is stopped and unbuckle when you start the engine.

Let's look at this typescript class:

class TsClass {
  #privateField;

  constructor(value) {
    this.#privateField = value;
  }

  getPrivate() {
    return this.#privateField;
  }
}

const a = new TsClass('AA');
const b = new TsClass('BB');

console.log(a.getPrivate()); // AA
console.log(eval('_TsClass_privateField.get(b)')) // BB

It doesn't fail to compile because the adversarial code is in a string, but this just emulates an XSS or supply chain attack.

Why does it work? Well, this is the result of running the sample through tsc

var __classPrivateFieldSet = (this && this.__classPrivateFieldSet) || function (receiver, state, value, kind, f) {
    if (kind === "m") throw new TypeError("Private method is not writable");
    if (kind === "a" && !f) throw new TypeError("Private accessor was defined without a setter");
    if (typeof state === "function" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError("Cannot write private member to an object whose class did not declare it");
    return (kind === "a" ? f.call(receiver, value) : f ? f.value = value : state.set(receiver, value)), value;
};
var __classPrivateFieldGet = (this && this.__classPrivateFieldGet) || function (receiver, state, kind, f) {
    if (kind === "a" && !f) throw new TypeError("Private accessor was defined without a getter");
    if (typeof state === "function" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError("Cannot read private member from an object whose class did not declare it");
    return kind === "m" ? f : kind === "a" ? f.call(receiver) : f ? f.value : state.get(receiver);
};
var _TsClass_privateField;
class TsClass {
    constructor(value) {
        // Private field
        _TsClass_privateField.set(this, void 0);
        __classPrivateFieldSet(this, _TsClass_privateField, value, "f");
    }
    getPrivate() {
        return __classPrivateFieldGet(this, _TsClass_privateField, "f");
    }
}
_TsClass_privateField = new WeakMap();
const a = new TsClass('AA');
const b = new TsClass('BB');
console.log(a.getPrivate());
console.log(eval('_TsClass_privateField.get(b)'));

It's all represented with a conventionally named WeakMap.

You can target es2022 or above to get TypeScript to generate the same code as in the EcmaScript example.

Is anything private?

Yes. It's the good old closures. Functional scope is the real private thing in JavaScript.

function NotAClass(value1, value2) {
  const actuallyPrivate = [value1, value2];
  return {
    doSomethingWithPrivate: () => actuallyPrivate.join('-'),
  };
}

const c = NotAClass("CC", "DD");
console.log(c.doSomethingWithPrivate()); // CC-DD

It's really private.

Until you consider the possibility of prototype poisoning


Array.prototype.join = function () {
    console.log('join',this);
}
c.doSomethingWithPrivate() 
// logs: join [ 'CC', 'DD' ]

But that's a whole different story...

If you're interested, check out my defensive-coding training or look into tools that can prevent prototype poisoning and much more:

GPT teaches me how to make my logic sync and async at the same time with trampolines

naugtur — Thu, 11 Apr 2024 22:03:48 +0000

How can I have one implementation of some complex logic that can call out to sync or async hooks where the async one needs to be properly awaited each time?

I told ChatGPT to teach me that. Below is our (heavily/extensively/drastically/substantially/profoundly redacted and fixed) chat log.

in javascript, I have a function that's accepting a hook as input, runs a few synchronous operations, calls the hook and runs a few synchronous operations on the results. You can represent the operations as simple mathematical operations for the examples. I need an implementation that shares only one implementation of the operations but has two versions of the function - one that's asynchronous and accepts an async hook and awaits it, the other fully synchronous and accepting a synchronous hook.
I was told to use generators and to build a trampoline. I need an example of what that could look like with an explanation of the trampoline.

//the prompt was longer and contained snippets from tips I got from humans

To implement the solution you're looking for, we'll start by creating a generic function that can perform operations both synchronously and asynchronously, depending on the hook it receives. This function will be a generator, allowing us to use yield to handle both synchronous and asynchronous operations in a unified way.

The key concept here is the use of a "trampoline" function. A trampoline in this context is a mechanism that iteratively executes generator functions without growing the call stack. This is crucial for handling potentially deep or infinite recursion without causing a stack overflow. For asynchronous operations, the trampoline will use promises to handle the asynchronous yields.

Let's start with an example of the operations and the generator function:

// Generator function accepting a hook
function* operationsWithHook(hook, input) {
  let result = input * 2; // First operation
  result = yield hook(result); // Call the hook, which can be sync or async
  result = result * 2; // Operation on the hook's result
  return result;
}

Now, let's implement two trampoline functions, one for synchronous execution and another for asynchronous execution:

// Synchronous trampoline
function syncTrampoline(generatorFunc, ...args) {
  let iterator = generatorFunc(...args);
  let result = iterator.next();
  while (!result.done) {
    result = iterator.next(result.value);
  }
  return result.value;
}


// Asynchronous trampoline
async function asyncTrampoline(generatorFunc, ...args) {
  let iterator = generatorFunc(...args);
  let result = iterator.next();
  while (!result.done) {
    const val = await result.value
    result = iterator.next(val);
  }
  return result.value;
}

Editor note: I fixed the implementation here, async trampoline was wrong and didn't work.

With these trampolines, you can now execute your generator function either synchronously or asynchronously, depending on the nature of the hook you're passing. Here's how you would use them:

// Synchronous hook
function syncHook(x) {
  return x + 10;
}

// Asynchronous hook
async function asyncHook(x) {
  await new Promise(resolve => setTimeout(resolve, 101));
  return x + 10;
}


// Execute synchronously
const syncResult = syncTrampoline(operationsWithHook, syncHook, 5);
console.log('done:',syncResult); // Output will depend on operations and hook

// Execute asynchronously
asyncTrampoline(operationsWithHook, asyncHook, 5).then((result) => {
  console.log('done:',result); // Output will depend on operations and hook
});

This approach allows you to maintain a single implementation of your operations and seamlessly switch between synchronous and asynchronous execution by choosing the appropriate trampoline function. The generator function acts as a bridge, using yield to pause execution at the hook call, which can then be handled either synchronously or asynchronously by the trampoline.

One more complication. operationsWithHook calls itself recursively if the current result is below N. How would I wire that up?

To handle recursion within your operationsWithHook generator function, especially when deciding whether to recurse based on the result of calling the hook, you can use yield* to delegate to another generator function. This allows the current generator to yield values from another generator, effectively creating a recursive loop.

Let's modify the operationsWithHook function to include a condition for recursion if the result of calling the hook and multiplying it remains below constant N.

// Modified generator function with recursion
N=1000
function* operationsWithHook(hook, input) {
  let result = input * 2; // First operation
  result = yield hook(result); // Call the hook, which can be sync or async
  result = result * 2; // Operation on the hook's result
  // Check if the result is divisible by N, and if so, recurse
  if (result < N) {
    result = yield* operationsWithHook(hook, result); // Recurse with yield*
  }
  return result;
}

The yield* expression is used for delegating to another generator function, in this case, operationsWithHook itself, which allows for recursion. This works seamlessly with both synchronous and asynchronous hooks because the trampoline functions are designed to handle the iteration over generator functions, including when they delegate to other generators or themselves.

The trampoline functions (syncTrampoline and asyncTrampoline) do not need to be modified to support this recursion. They will continue to work as before, driving the generator to completion, whether it involves recursion or not.

The same execution code as before can be used to execute the generator function either synchronously or asynchronously, depending on the nature of the hook you're passing.

This approach allows the operationsWithHook function to call itself recursively under certain conditions, with the trampoline functions handling the execution flow, whether synchronous or asynchronous.

Complete example file

I put it together and added logging so you can see the output and understand the flow.



N=1000
function* operationsWithHook(hook, input) {
  let result = input * 2; // First operation
  result = yield hook(result); // Call the hook, which can be sync or async
  result = result * 2; // Operation on the hook's result
  console.log(Date.now(), [input, result])
  // Check if the result is divisible by N, and if so, recurse
  if (result < N) {
    result = yield* operationsWithHook(hook, result); // Recurse with yield*
  }
  return result;
}

// Synchronous trampoline
function syncTrampoline(generatorFunc, ...args) {
  let iterator = generatorFunc(...args);
  let result = iterator.next();
  while (!result.done) {
    result = iterator.next(result.value);
  }
  return result.value;
}

// Asynchronous trampoline
async function asyncTrampoline(generatorFunc, ...args) {
  let iterator = generatorFunc(...args);
  let result = iterator.next();
  while (!result.done) {
    console.log(Date.now(),result.value)
    const val = await result.value
    console.log(Date.now(), ' ->',result.value)
    result = iterator.next(val);
  }
  return result.value;
}
// Synchronous hook
function syncHook(x) {
  return x + 10;
}

// Asynchronous hook
async function asyncHook(x) {
  await new Promise(resolve => setTimeout(resolve, 101));
  return x + 10;
}

// Execute synchronously
const syncResult = syncTrampoline(operationsWithHook, syncHook, 5);
console.log(syncResult); // Output will depend on operations and hook

// Execute asynchronously
asyncTrampoline(operationsWithHook, asyncHook, 5).then((result) => {
  console.log(result); // Output will depend on operations and hook
});

Disclaimer and license

Note: I have modified the response from our benevolent AI overlord to my liking in sufficiently many places, so now it's copyrightable, which allows me to release it under CC BY-NC-SA

I mean, I had to modify it because asyncTrampoline was broken, it's not just for copyright :D

Supply chain security - prevent, not avoid

naugtur — Wed, 03 Aug 2022 16:12:00 +0000

Semver range specifiers ~^ are not only used in a top-level package.json. They're also used by dependencies. It's not feasible to get everyone to stop using them and it wouldn't be good for the ecosystem and even security. If a dependency 5 levels deep gets a security fix, how do you update all along the way? It's a problem already, even though ^ is fairly popular.

Lockfiles solve the issue of a nested dependency getting updated accidentally. package-lock.json or yarn.lock, if used right, eliminate the probability of unexpected nested package updates in CI etc.

"Vendoring" - pushing node_modules into the repository - is not practical and doesn't offer benefits compared to fully leveraging lockfiles.

Even if "vendored", updating is a must and at any significant size of the dependency tree reviewing every single package coming down is not humanely possible.

Now finding a package and taking it over is one threat, but what about a maintainer of a useful package who intentionally publishes a malicious version to get rich quicker than otherwise just making opensource?
What about a prototype pollution in one package leading to a compromise of another package? What about the most popular way of delivering attacks - a postinstall script? The script would run before you get the chance to review the contents of the package. (That can be mitigated by socket.dev decently)

That's why instead of attempting the impossibility of reviewing all packages in your dependency tree I'd suggest preventing the outcomes of a malicious package eventually reaching your dependencies.

Enter: LavaMoat.
https://github.com/LavaMoat/LavaMoat

LavaMoat has tools for preventing unexpected postinstall scripts from running. (allow-scripts)

LavaMoat has tools to put each package in its own compartment and only allow it to access globals, builtins and other packages based on a policy. At runtime!

If a package attempts to require('fs') or call fetch() in a new version, it's not going to work if it wasn't there previously.

Enough reading?

Here's a conversation about supply chain and install scripts
https://www.youtube.com/watch?v=STC_ubJNiMs

Here's an intro to lavamoat
https://www.youtube.com/watch?v=iaqe6F4S2tA

Additive changes to your cjs exports are now breaking changes.

naugtur — Thu, 03 Mar 2022 21:27:43 +0000

The title is a bit of a clickbait, but it's not false! :D

So you're providing a module with a very useful utility function in even.cjs version 1.0.1 (improved performance since 1.0.0!)

module.exports = {
  even: n => n % 2 === 0
};

A faithful consumer comes in and uses it in their app.mjs

import * as utils from './even.cjs'; 
utils.even(13) // false

Looks good. Time for feature creep.

A contributor comes and makes a pull request to add a very helpful field allowing them to look up the version at runtime. (jQuery has it, it must be good.)

module.exports = {
  version: '1.1.0',
  even: n => n % 2 === 0
};

Lovely, thanks for the contribution! Published as v1.1.0!

1 hour later:

Issue: You broke my app! TypeError: utils.even is not a function

Wait, what?

Yeah, the named export is gone.

If we switch to named imports, the error message is more helpful:

import { even } from './even.cjs';
         ^^^^
SyntaxError: Named export 'even' not found. The requested module './even.cjs' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from './even.cjs';
const { even } = pkg;

Here's the before and after for all 3 cases.

// import * as utils from './even.cjs';
    [Module: null prototype] {
      default: { even: [Function: even] },
      even: [Function: even]
    }
// import { even } from './even.cjs';
    [Function: even]
// import utils from './even.cjs';
    { even: [Function: even] }

// import * as utils from './even.cjs';
    [Module: null prototype] {
      default: { version: '1.1.0', even: [Function: even] }
    }
// import { even } from './even.cjs';
    ERROR
// import utils from './even.cjs';
    { version: '1.1.0', even: [Function: even] }

But why??

When you import modules, you're supposed to get the exports without actually running the code. For ESM modules the limitation to how export keyword can be used it's fairly easy and quick to provide a complete and correct list without fully parsing and tracing the execution of the entire file. It's not possible for CommonJS.

BTW, that's why it took so long to provide ESM in Node too - figuring out ESM<->CJS crossover was difficult.

So to get importing CommonJS to work at all, a good-enough pass through the cjs file is made to try and detect exports without running the code.

It ships with Node.js: https://github.com/nodejs/node/tree/fdf625bae8f8b29a25cbd7c8a5d8220af6292cea/deps/cjs-module-lexer

The readme there offers a few cases where the lexer bails out of listing exports, but I think the tests are better at documenting it precisely.

This is the exact test explaining what we're seeing here:
https://github.com/nodejs/cjs-module-lexer/blob/main/test/_unit.js#L532

Why do I know all this? Well, I'm trying to provide a consistent cjs import implementation in a different engine's import implementation. And now I have to fake the differences even though I could provide more reliable exports listings.

Oh, and guess what - this differs between Node, webpack, parcel etc.

What should a package maintainer do?

Be aware of this :)
Look into exports field in package.json - it might help
- https://webpack.js.org/guides/package-exports/
- https://nodejs.org/api/packages.html#exports
Consider wrapping your package in a .mjs that just reexports things under the right names if you could be affected.

Get safe and remain productive with can-i-ignore-scripts

naugtur — Tue, 24 Aug 2021 09:10:39 +0000

So you've heard about supply chain security? You should no longer want to run npm ci without the --ignore-scripts flag. If you still need more convincing - I made a package that makes typescript compiler inject malicious code to your application. See this video for more

Now with the good advice to always run npm ci --ignore-scripts all that's left is to start using it. But wait! My app no longer works! Some of these scripts were necessary after all...

All you need to do is npm rebuild packagename. If you know which package needs its scripts to run.

That's the problem with security best practices - there's always convenience that you need to give away. But that's where I come in! I enjoy making security best practices easier to deploy in your team. (That's why I wrote npm-audit-resolver but that's a different story)

`--ignore-scripts` and no regrets

Figuring out which of your packages actually need their postinstall scripts is not a candidate to make the list of "top 5 moments at work". I bet you'll be happy to hear there's a tool to do it for you.

can-i-ignore-scripts is a commandline utility that scans your node_modules folder and lists all packages with scripts that run on installation. It then checks against a collection of known packages whose scripts were already evaluated before and lists suggestions.

You can use the suggestions to quickly choose which scripts to run after the installations have finished.

There's nothing wrong with accepting some scripts you're not sure about. The goal of having an allowlist is to avoid running a script that was maliciously added where it wasn't before. The sooner you introduce --ignore-scripts to your app the better. Even if that means adding exceptions for ALL existing packages.

Quick roll out in your project? Here you go:

npm ci --ignore-scripts
npx can-i-ignore-scripts


█▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀█
  ▄▄·  ▄▄▄·  ▐ ▄    ▄     ▪    ▄▄     ▐ ▄       ▄▄▄   ▄▄▄      ▄▄▄▄·
 ▐█ ▌ ▐█ ▀█ ·█▌▐█   ██    ██  ▐█ ▀    █▌▐█      ▐▄ █· █  ▀·  .▀  .█▌
 ██ ▄▄▄█▀▀█ ▐█▐▐▌   ▐█·   ▐█· ▄█ ▀█▄ ▐█▐▐▌ ▄█▀▄ ▐▀▀▄ ▐█▀      ▄█▀▀▀·
 ▐███▌▐█ ▪▐▌██▐█▌   ▐█▌   ▐█▌ ▐█▄ ▐█ ██▐█▌▐█▌.▐▌▐▄ █▌▐█▄▄▄▌   ▀
 ·▀▀▀  ▀  ▀ ▀▀ █▪   ▀▀▀   ▀▀▀ ·▀▀▀▀  ▀▀ █▪ ▀█▄▀▪.▀  ▀ ▀▀▀     ▀

▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Found following packages with scripts:
[ ignore ] 'pre-commit' has scripts but they can be ignored 
             reason: used in local development
[ ignore ] 'core-js' has scripts but they can be ignored 
             reason: funding
[  keep  ] 'grpc' needs its scripts to run
[  keep  ] 'bignum' needs its scripts to run

▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
What now? Run rebuild after 'npm ci --ignore-scripts' to trigger scripts you need to keep. 

A suggestion to get you started:
npm rebuild bignum grpc
█▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄█

Then take a look at the recommendations and add the rebuild line after the installation in CI

npm rebuild bignum grpc

Go hack yourself

Don't know if postinstall scripts actually run in your CI? Or maybe you need to convince someone it'a an issue? Hack yourself by installing @naugtur/pentest-my-ci as your dev dependency. It contains a preinstall script that stops the CI and tries to scare the reader of the logs a bit.

Do you need help with your npm audit?

naugtur — Wed, 07 Jul 2021 20:41:06 +0000

Ok, I'm gonna try and surf the wave of publicity resulting from Dan Abramov's recent post and its discussions.
It's 10PM and English is not my first language, so... hold on to your grammars.

Let me address the elephant in the room too. Or talk about how I'm working to address it.

I've encountered the npm audit fatigue just days after the audit feature was released. It was on a Node.js project. (ok, 20+ of them at once)

It resulted with the first version of npm-audit-resolver

If you want to know how npm-audit-resolver came to life, I've told the story in this recording:
OpenJS World 2021 pkg vuln talk
apologies for the quality of my webcam

The video introduces Package Vulnerability Management & Reporting Collaboration Space.

Actually, I recommend you stop reading and watch a bit of it now.

What I want to talk about here is the ideas for the future of npm-audit-resolver.

And that future is tightly bound to the Package Vulnerability Management & Reporting Collaboration Space, I hope.

Current state

Let me give you a quick summary

it's an interactive tool that asks you what to do with each vulnerability
lets you ignore vulnerabilities with surgical precision
helps maintain a culture of caring about security by reducing annoyance (not enough yet)
maintains a json file with your decisions audit-resolve.json
wraps npm audit for running in CI and applies your ignores
supports yarn too
npm7 support on its way (I'm working with npm folks on some details)

Plans

Decisions file

I intend to donate the JSONSchema of the audit-resolve.json file to OpenJS Foundation. When it's ready :)

The format evolved a bit already, but I also need to adapt it to the new usecase of sharing.

Sharing decisions

The new usecase for audit-resolve.json is sharing decisions.

Imagine an internal security team publishing a file with recommendations what to safely ignore that shows up as suggestions or can be applied automatically.

How about a central location to manage shared decisions across projects?

Ok, now the best part - security influencers!

Jokes aside, package maintainers could publish ignore lists for the dependencies of their package when they did the research to verify the package is not affected.
Such lists could be aggregated into recommendations maintained by security professionals.

`audit-resolve.json` support everywhere!

The plan is to make the default npm audit command take the file into account. I've extracted the core from npm-audit-resolver so that anyone can embed it in their tooling.

It's not much, it's not 100% ready, but it's doing basic work for you.

I hope yarn, pnpm, snyk and so on would eventually understand the format.

pkg-vuln-collab-space

These ideas are just my ideas. I'm hoping to see them shaped by real data and feedback and discussions in the Collab Space.

Please participate in the Collab Space.
Please try npm-audit-resolver
Please don't get demotivated - try caring about security at least to the point of ignoring the vulnerabilities one by one ;)

Hey, did you watch the OpenJsWorld video already?

DEV Community: naugtur

Is this my last meet.js Summit?

Don't we all look forward to code-review full time?

The missing link

What's in the script

What's the environment

Sometimes the best thing to do is an explicit nothing

react-dom under LavaMoat

The emulation LavaMoat does

window.event behavior

Conclusion

Wait, what?

Conclusion, for real this time

Update

All ways to get a DOM element reference

Creating DOM nodes

Finding existing DOM nodes

Globally Available DOM API Types

Core Node Types

Element Subclasses

HTML Elements (all inherit from HTMLElement)

SVG Elements (all inherit from SVGElement)

MathML Elements

Document Types

Other DOM-Related Classes

NodeList/Collections

Attribute/Style/Other

Miscellaneous

Event Classes

Same but with inheritance depicted

A Phish on a Fork, no Chips

𐂐 The fork

🐟 The phish

The full story

🍟 The chip

Avoiding the phish on a fork

🍣 A solution that, ehm, scales 🫣

The @lavamoat/git-safe-dependencies validator

How private are your class #private fields?

EcmaScript Class

Would type-checking help?

Is anything private?

GPT teaches me how to make my logic sync and async at the same time with trampolines

Complete example file

Disclaimer and license

Supply chain security - prevent, not avoid

Additive changes to your cjs exports are now breaking changes.

Wait, what?

But why??

What should a package maintainer do?

Get safe and remain productive with can-i-ignore-scripts

--ignore-scripts and no regrets

Go hack yourself

Do you need help with your npm audit?

Current state

Plans

Decisions file

Sharing decisions

audit-resolve.json support everywhere!

pkg-vuln-collab-space

HTML Elements (all inherit from `HTMLElement`)

SVG Elements (all inherit from `SVGElement`)

The `@lavamoat/git-safe-dependencies` validator

`--ignore-scripts` and no regrets

`audit-resolve.json` support everywhere!