# Introducing warg a WebAssembly ReGistry The Bytecode Alliance has been hard at work defining an API and protocol for a **W**eb**A**ssembly **R**e**g**istry also known as **warg**. We just started, but we want this to be an open standard, built, and reviewed by the community, and its time to share our ideas! ## But why build a (yet another) registry? Registries are a critical part of any software stack. They are the means for software publish and share your code, but perhaps more importantly, pull your dependencies. A modern application in today's world is made up of more lines of code from external dependencies than what is written in the application. This becomes more apparent with supply chain attacks on the rise. [TODO add supply chain attack stats] Many registries have added methods for security like auditing, signing, and two-factor authentication, but often these have come after the fact - after a major CVE that left applications vulnerable and maintenance work (updating dependencies, rebuilding, and reshipping is churn for devs). Registries are an even more fundamental backbone of the software stack than most developers realize. They can dictate how applications are package, how they describe their contents for *what* is distributed, *who* can publish, and *how* applications are assembled. There are very good reasons for why registries assemble so many fundamental aspects of the software stack. They are complex pieces of software with expensive ingress needs. This is why most successful registries require a software foundation to pay and maintain the integrity of the system. For us, there is another fundamental key element. We are building a new standard, built on other open standards, that continues on the secure by design, capability based architecture of WebAssembly and the Component Model. Many existing registries are built around other protocols and package types that do not understand components. If we were to take a step back and design a new fundamental layer of the software stack, what would that look like? Wapm?15:17 Luke asked about the reflect status in tinygo since he had a use case needing json deserialization/serialization. 15:17 I think the status is that it's not great and undergoing heavy construction Luke Wagner15:32 That matches what I heard also, so thanks for the confirmation and links. Sounds like someone on our team (dgryski) may end up trying to help move this forward before too long. OCI? supergloo engineerd NPM? SIG-store? ## Component Model The aspects of the component model that are relevant to Warg, are well, all of them. [TODO] ## Ability to mirror A company’s instance could mirror from the Bytecode Alliance registry, ## The Registry is based on Transparency Registries Assert Package Contents Diagram: Mapping of (registry, package, version) to digest Registries Can Lie about Package Contents Diagram: Prior diagram, where mapping has been changed to new digest How can we know when they lie? Picture: Panopticon Using and Extending Transparency Data Structures Title Card Verifiable Log Diagram Verifiable Map Diagram Log-Backed Map Diagram Linked Log-Backed Map Diagram Package Logs Diagram Operator Logs Diagram ## Summary cert trans gives logs, this gives us a map, now we can talk about the state as one structure Why Wasm? The answer has always been Security First. ## Goals The Bytecode Alliance will stand up a canonical instance And communities with specific components, can collaborate with the canonical instance. This is a pre-security review design. Supply imports When you load it as a ES Module loader system When you load a component as an ES Module Put a URL in an import as the module specifier overridden by an import map Look and feel like es module With these DAGs Top-level component will either bundle or will have a URL component then takes over how they are linked together components would link themselves separation of loading the code and instantation longer term story expose Web API's as built-in modules as ES Modules import objects from the module system Then with component model could use those es modules. polyfill story there that we could use all the way through. TUF general-purpose WebAssembly has new and better approaches to security, and we want to use these new approaches