Thicket data repository for the EEG
anil.recoil.org
1{
2 "id": "https://ryan.freumh.org/2025-05-12.html",
3 "title": "12 May 2025",
4 "link": "https://ryan.freumh.org/2025-05-12.html",
5 "updated": "2025-05-12T00:00:00",
6 "published": "2025-05-12T00:00:00",
7 "summary": "<div>\n <span> Previous: <a href=\"2025-05-05.html\"> 5 May 2025</a> </span>\n <span> Next: <a href=\"2025-05-19.html\">19 May 2025</a> </span>\n </div>\n \n \n\n <h2><span>X</span> <a href=\"https://github.com/RyanGibb/uvx-ocaml\">uvx OxCaml</a>\nexperiment</h2>\n<p><span>Can we use <code>uv</code> to package python? Part of <a href=\"enki.html\">Enki</a>.</span></p>\n<h2><span>X</span>\nRead <a href=\"https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf\">Solving\nthe Bottom Turtle</a></h2>\n<p><span>They’re thinking\nabout a similar problem, but are much more focused on the corporate\nside.</span></p>\n<h2><span>X</span> Read <a href=\"https://www.usenix.org/sites/default/files/conference/protected-files/enigma_haken_slides.pdf\">Secrets\nat Scale: Automated Bootstrapping of Secrets & Identity in the\nCloud</a></h2>\n<p><span>They\njust use AWS as their root of trust</span></p>\n<h2>Identity as a Function</h2>\n\n\n<img src=\"./images/2025-05-09-identity-dependencies.svg\">\n\nIdentity Dependencies in the Network\n\n<ol>\n<li><p><span>Problem</span></p>\n<ul>\n<li>Service managers have no purview over the lifetimes of the\nidentities networked services create, such as X.509 certificates, DNS\nrecords, and protocol-specific keys.</li>\n<li>Such identities are managed in an ad-hoc way that makes it difficult\nto have insight as to what identities have been created and which might\nhave been compromised.</li>\n<li>There is a complex web of dependencies that makes revoking and\nrotating identities a manual and error-prone process.</li>\n</ul></li>\n<li><p><span>Cost</span></p>\n<ul>\n<li>Unused identities leave a larger attack surface for access to\ncritical systems, and failure to understand the implications of\ncompromises on downstream identities leaves us vulnerable.</li>\n<li>For example, persisting an outdated SSH key in a server’s <code>authorized_keys</code> creates a unnecessary\nbackdoor.</li>\n<li>If an attacker gains access to the system, say, running a\nnameserver, they could move laterally use the ACME protocol to provision\nTLS certificates for the domain.</li>\n<li>On discovering this compromise all the dependent identities, such as\nTLS certificates, will need to be revoked.</li>\n</ul></li>\n<li><p><span>SOTA</span></p>\n<ul>\n<li>Existing software deployment techniques layer complexity in order to\nmanage all these identities.</li>\n<li>There’s many useful bits that are stitched together piecemeal with\nfragile glue, but a lack of a unified interface to identity in the\nnetwork across disparate protocols.</li>\n</ul></li>\n<li><p><span>Solution</span></p>\n<ul>\n<li>We define a identity Domain Specific Language to describe the types\nof identities in play in the TCP/IP networking stack, showing the roots\nof trust in our systems and their transitive dependants.</li>\n<li>By defining identities in this way, we can express identities as\nfunctions that return an authentication token, and unclock the\nprogramability of identities in the network.</li>\n<li>We can understand the lifetime of identities and garbage collect\nthem when they’re no longer used.</li>\n<li>We can create hundred of honey-pot keys that if used we know there’s\nbeen a compromise in the network.</li>\n<li>We can spin up a self-hosted digital island for the duration of a\nproject and manage the full lifetime of the identities involved; from\ncreation, to rotation, to expiry and revocation.</li>\n<li>We can minimising the chain of trust by re-anchoring identities like\nMatrix user IDs from HTTPS well-known paths to DNSSEC-verified\nresource-records, using DNSSEC as the narrow waist of trust.</li>\n<li>We can <a href=\"https://www.tunbury.org/bluesky-ssh-authentication-2/\">authenticate\nSSH keys with an AtProto Personal Data Service</a>.</li>\n<li>We provide a framework to understand the roots of trusts of our\nidentities and any weak points in the chain of trust.</li>\n</ul></li>\n<li><p><span>Impl</span></p>\n<ul>\n<li>What if we had registry of identities?</li>\n<li>What are the constituent parts?</li>\n<li>How do we use this language?</li>\n<li>What are we trying to prove?</li>\n<li>Provide clarify to provide to an existing set of rules?</li>\n<li>Are we trying to prove some properties of this system (identities in\nthe network)?</li>\n<li>What is our stunt?</li>\n<li>The service manager could talk to identity service and mount the\nsecrets in a namespace?</li>\n<li>Do we wrap Docker compose?</li>\n<li>Do we implement a service/registry with a Cap’N Proto API that\napplications can talk to? Using Cap’N Proto as the system call\nlayer.</li>\n<li>Or maybe we can change the mechanism by which the file gets\nthere?</li>\n<li>This is exactly what I’ve done <a href=\"https://github.com/RyanGibb/eon/blob/main/acme.nix\">here</a>.</li>\n<li>This is a horrible hack though: the service needs to kill itself to\ncommunicate that the downstream dependencies need to restart.</li>\n<li>We’re in this liminal space between building (Nix) and running\n(SystemD).</li>\n</ul></li>\n</ol>\n<h2>Service Managers a la Carte</h2>\n<p><span>They’re just build\nsystems that continue to run. The difference between docker run and\ndocker build is that docker run commands don’t terminate. They’re both\nsandboxed. Service managers mange to manage dynamic processes: if a\nservice restarts maybe it’s downstream dependencies need to\nrestart.</span></p>\n<p><span>Starting building\nblock: formalised framework for service managers. It’s within this that\nwe can define what identity is.</span></p>\n<p><span>What do these systems\nallow you to express? Restart policies? Are they static or dynamic? None\nof them are triggered by the fileystem restarting.</span></p>\n<p><span>It would be insightful\nto know what the hell goes on on Windows.</span></p>\n<p><span>A service is a process\nexecution environment and set of dependencies. We have a forest: disjunc\ngraphs with no cycles. Service can be long running or not (just mutate\nsomething on the disk/network).</span></p>\n<p><span>It becomes a build\nsystem when the dependencies are run to set up the state of some\nservice. How can we depend on a resource, like a TLS certificate? We\ncould have the service that provides it, and a service that consumes\nit.</span></p>\n<p><span>Dune rules service\nmanager.</span></p>\n<p><span>It is a reactive system\n(see froc) – you need a notion of time.</span></p>\n<h2><span>X</span> read <a href=\"https://github.com/royangkr/bigraph-of-the-world\">Bigraph of the\nWorld</a> final draft</h2>\n<h2>PROJ\nupdate the package management paper for arxiv publication</h2>\n<ol>\n<li><p><span><span>X</span> update formalism</span></p>\n<p><span>It\nturns out depopts aren’t a part of the resolution at all, they’re only\nused to assemble the action graph and order installations from the\nresolved set of packages. Purely a post-resolution processing step. No\ndepopt we add to any package will actually change the resolved package\nset; they only change the order in which they’re installed, or whether a\npackage needs to be rebuild given a dependency change.</span></p>\n<p><span>Some\nother improvements:</span></p>\n<ul>\n<li>we don’t add conflicts to the core calculus since we can encode them\nwith a conflict package</li>\n<li>we don’t jump through hoops to support multi-version solving as we\nencode different cargo package major versions as different package\nnames, with a proxy package to depend on cross-major version bumps</li>\n<li>this means we can resolve for a resolved set of packages and\nreconstruct their installation order from their dependencies</li>\n</ul></li>\n<li><p><span>MOVE\nPak language</span></p>\n<p><span>A\nmaximally expressive lingua franca for package\nmanagement</span></p></li>\n<li><p><span>MOVE\nalgorithm discussion</span></p>\n<p><span>We\nalready discuss SAT solving but we should describe Answer-set\nprogramming solutions like PubGrub, and how CUDF fits in\nhere</span></p></li>\n<li><p><span>MOVE\nbidirectional translations - [[*<span>$$\\[https://github.com/RyanGibb/uvx-ocaml$$</span><span><em>u</em><em>v</em><em>x</em><em>O</em><em>x</em><em>C</em><em>a</em><em>m</em><em>l</em></span>\\]\nexperiment][opam to uv]]</span></p></li>\n<li><p><span>MOVE\nwhat can we reason about with the package calculus?</span></p>\n<ul>\n<li>diamond dependency problem?</li>\n<li>how to extract it from an arbitrarily complex graph?</li>\n</ul></li>\n</ol>\n<h2>MOVE Read up on GNU Shepard</h2>\n<h2>MOVE\nhook <a href=\"bigraphs-real-world.html\">Roy</a>’s <a href=\"https://github.com/royangkr/bigraph-of-the-world\">Bigraph of the\nWorld</a> up to <a href=\"https://github.com/ryanGibb/eo\">Eon</a> to form\nthe basis of the <a href=\"spatial-computing.html\">Spatial Name\nSystem</a></h2>\n<h2>MOVE\nRe-read the service management chapter of <a href=\"https://edolstra.github.io/pubs/phd-thesis.pdf\">https://edolstra.github.io/pubs/phd-thesis.pdf</a></h2>",
8 "content": "<div>\n <span> Previous: <a href=\"2025-05-05.html\"> 5 May 2025</a> </span>\n <span> Next: <a href=\"2025-05-19.html\">19 May 2025</a> </span>\n </div>\n \n \n\n <h2><span>X</span> <a href=\"https://github.com/RyanGibb/uvx-ocaml\">uvx OxCaml</a>\nexperiment</h2>\n<p><span>Can we use <code>uv</code> to package python? Part of <a href=\"enki.html\">Enki</a>.</span></p>\n<h2><span>X</span>\nRead <a href=\"https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf\">Solving\nthe Bottom Turtle</a></h2>\n<p><span>They’re thinking\nabout a similar problem, but are much more focused on the corporate\nside.</span></p>\n<h2><span>X</span> Read <a href=\"https://www.usenix.org/sites/default/files/conference/protected-files/enigma_haken_slides.pdf\">Secrets\nat Scale: Automated Bootstrapping of Secrets & Identity in the\nCloud</a></h2>\n<p><span>They\njust use AWS as their root of trust</span></p>\n<h2>Identity as a Function</h2>\n\n\n<img src=\"./images/2025-05-09-identity-dependencies.svg\">\n\nIdentity Dependencies in the Network\n\n<ol>\n<li><p><span>Problem</span></p>\n<ul>\n<li>Service managers have no purview over the lifetimes of the\nidentities networked services create, such as X.509 certificates, DNS\nrecords, and protocol-specific keys.</li>\n<li>Such identities are managed in an ad-hoc way that makes it difficult\nto have insight as to what identities have been created and which might\nhave been compromised.</li>\n<li>There is a complex web of dependencies that makes revoking and\nrotating identities a manual and error-prone process.</li>\n</ul></li>\n<li><p><span>Cost</span></p>\n<ul>\n<li>Unused identities leave a larger attack surface for access to\ncritical systems, and failure to understand the implications of\ncompromises on downstream identities leaves us vulnerable.</li>\n<li>For example, persisting an outdated SSH key in a server’s <code>authorized_keys</code> creates a unnecessary\nbackdoor.</li>\n<li>If an attacker gains access to the system, say, running a\nnameserver, they could move laterally use the ACME protocol to provision\nTLS certificates for the domain.</li>\n<li>On discovering this compromise all the dependent identities, such as\nTLS certificates, will need to be revoked.</li>\n</ul></li>\n<li><p><span>SOTA</span></p>\n<ul>\n<li>Existing software deployment techniques layer complexity in order to\nmanage all these identities.</li>\n<li>There’s many useful bits that are stitched together piecemeal with\nfragile glue, but a lack of a unified interface to identity in the\nnetwork across disparate protocols.</li>\n</ul></li>\n<li><p><span>Solution</span></p>\n<ul>\n<li>We define a identity Domain Specific Language to describe the types\nof identities in play in the TCP/IP networking stack, showing the roots\nof trust in our systems and their transitive dependants.</li>\n<li>By defining identities in this way, we can express identities as\nfunctions that return an authentication token, and unclock the\nprogramability of identities in the network.</li>\n<li>We can understand the lifetime of identities and garbage collect\nthem when they’re no longer used.</li>\n<li>We can create hundred of honey-pot keys that if used we know there’s\nbeen a compromise in the network.</li>\n<li>We can spin up a self-hosted digital island for the duration of a\nproject and manage the full lifetime of the identities involved; from\ncreation, to rotation, to expiry and revocation.</li>\n<li>We can minimising the chain of trust by re-anchoring identities like\nMatrix user IDs from HTTPS well-known paths to DNSSEC-verified\nresource-records, using DNSSEC as the narrow waist of trust.</li>\n<li>We can <a href=\"https://www.tunbury.org/bluesky-ssh-authentication-2/\">authenticate\nSSH keys with an AtProto Personal Data Service</a>.</li>\n<li>We provide a framework to understand the roots of trusts of our\nidentities and any weak points in the chain of trust.</li>\n</ul></li>\n<li><p><span>Impl</span></p>\n<ul>\n<li>What if we had registry of identities?</li>\n<li>What are the constituent parts?</li>\n<li>How do we use this language?</li>\n<li>What are we trying to prove?</li>\n<li>Provide clarify to provide to an existing set of rules?</li>\n<li>Are we trying to prove some properties of this system (identities in\nthe network)?</li>\n<li>What is our stunt?</li>\n<li>The service manager could talk to identity service and mount the\nsecrets in a namespace?</li>\n<li>Do we wrap Docker compose?</li>\n<li>Do we implement a service/registry with a Cap’N Proto API that\napplications can talk to? Using Cap’N Proto as the system call\nlayer.</li>\n<li>Or maybe we can change the mechanism by which the file gets\nthere?</li>\n<li>This is exactly what I’ve done <a href=\"https://github.com/RyanGibb/eon/blob/main/acme.nix\">here</a>.</li>\n<li>This is a horrible hack though: the service needs to kill itself to\ncommunicate that the downstream dependencies need to restart.</li>\n<li>We’re in this liminal space between building (Nix) and running\n(SystemD).</li>\n</ul></li>\n</ol>\n<h2>Service Managers a la Carte</h2>\n<p><span>They’re just build\nsystems that continue to run. The difference between docker run and\ndocker build is that docker run commands don’t terminate. They’re both\nsandboxed. Service managers mange to manage dynamic processes: if a\nservice restarts maybe it’s downstream dependencies need to\nrestart.</span></p>\n<p><span>Starting building\nblock: formalised framework for service managers. It’s within this that\nwe can define what identity is.</span></p>\n<p><span>What do these systems\nallow you to express? Restart policies? Are they static or dynamic? None\nof them are triggered by the fileystem restarting.</span></p>\n<p><span>It would be insightful\nto know what the hell goes on on Windows.</span></p>\n<p><span>A service is a process\nexecution environment and set of dependencies. We have a forest: disjunc\ngraphs with no cycles. Service can be long running or not (just mutate\nsomething on the disk/network).</span></p>\n<p><span>It becomes a build\nsystem when the dependencies are run to set up the state of some\nservice. How can we depend on a resource, like a TLS certificate? We\ncould have the service that provides it, and a service that consumes\nit.</span></p>\n<p><span>Dune rules service\nmanager.</span></p>\n<p><span>It is a reactive system\n(see froc) – you need a notion of time.</span></p>\n<h2><span>X</span> read <a href=\"https://github.com/royangkr/bigraph-of-the-world\">Bigraph of the\nWorld</a> final draft</h2>\n<h2>PROJ\nupdate the package management paper for arxiv publication</h2>\n<ol>\n<li><p><span><span>X</span> update formalism</span></p>\n<p><span>It\nturns out depopts aren’t a part of the resolution at all, they’re only\nused to assemble the action graph and order installations from the\nresolved set of packages. Purely a post-resolution processing step. No\ndepopt we add to any package will actually change the resolved package\nset; they only change the order in which they’re installed, or whether a\npackage needs to be rebuild given a dependency change.</span></p>\n<p><span>Some\nother improvements:</span></p>\n<ul>\n<li>we don’t add conflicts to the core calculus since we can encode them\nwith a conflict package</li>\n<li>we don’t jump through hoops to support multi-version solving as we\nencode different cargo package major versions as different package\nnames, with a proxy package to depend on cross-major version bumps</li>\n<li>this means we can resolve for a resolved set of packages and\nreconstruct their installation order from their dependencies</li>\n</ul></li>\n<li><p><span>MOVE\nPak language</span></p>\n<p><span>A\nmaximally expressive lingua franca for package\nmanagement</span></p></li>\n<li><p><span>MOVE\nalgorithm discussion</span></p>\n<p><span>We\nalready discuss SAT solving but we should describe Answer-set\nprogramming solutions like PubGrub, and how CUDF fits in\nhere</span></p></li>\n<li><p><span>MOVE\nbidirectional translations - [[*<span>$$\\[https://github.com/RyanGibb/uvx-ocaml$$</span><span><em>u</em><em>v</em><em>x</em><em>O</em><em>x</em><em>C</em><em>a</em><em>m</em><em>l</em></span>\\]\nexperiment][opam to uv]]</span></p></li>\n<li><p><span>MOVE\nwhat can we reason about with the package calculus?</span></p>\n<ul>\n<li>diamond dependency problem?</li>\n<li>how to extract it from an arbitrarily complex graph?</li>\n</ul></li>\n</ol>\n<h2>MOVE Read up on GNU Shepard</h2>\n<h2>MOVE\nhook <a href=\"bigraphs-real-world.html\">Roy</a>’s <a href=\"https://github.com/royangkr/bigraph-of-the-world\">Bigraph of the\nWorld</a> up to <a href=\"https://github.com/ryanGibb/eo\">Eon</a> to form\nthe basis of the <a href=\"spatial-computing.html\">Spatial Name\nSystem</a></h2>\n<h2>MOVE\nRe-read the service management chapter of <a href=\"https://edolstra.github.io/pubs/phd-thesis.pdf\">https://edolstra.github.io/pubs/phd-thesis.pdf</a></h2>",
9 "content_type": "html",
10 "categories": [],
11 "source": "https://ryan.freumh.org/atom.xml"
12}