Skip to content

Commit

Permalink
Update report.json, rec-track-repos.json, hr-repos.json
Browse files Browse the repository at this point in the history
  • Loading branch information
w3c-validate-repos-bot committed Dec 5, 2024
1 parent 0c9060d commit b3d81b6
Showing 1 changed file with 23 additions and 11 deletions.
34 changes: 23 additions & 11 deletions report.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9884,7 +9884,7 @@
}
]
},
"timestamp": "2024-12-04T00:24:44.779Z",
"timestamp": "2024-12-05T00:25:02.081Z",
"repos": [
{
"id": "MDEwOlJlcG9zaXRvcnk4MTAyMTg2MA==",
Expand Down Expand Up @@ -56134,6 +56134,10 @@
"name": "s:html-ruby-extensions",
"color": "6bc5c6"
},
{
"name": "s:idna-rfc5891bis",
"color": "6bc5c6"
},
{
"name": "s:ietf:httpapi-linkset",
"color": "6bc5c6"
Expand Down Expand Up @@ -56230,6 +56234,10 @@
"name": "s:miniapp-packaging",
"color": "6bc5c6"
},
{
"name": "s:modern-network-unicode",
"color": "6bc5c6"
},
{
"name": "s:mst-content-hint",
"color": "6bc5c6"
Expand Down Expand Up @@ -56414,6 +56422,10 @@
"name": "s:uievents-key",
"color": "6bc5c6"
},
{
"name": "s:unichars",
"color": "6bc5c6"
},
{
"name": "s:url",
"color": "6bc5c6"
Expand Down Expand Up @@ -57770,6 +57782,10 @@
"name": "FPWD",
"color": "fbca04"
},
{
"name": "IETF",
"color": "0052cc"
},
{
"name": "LC",
"color": "d93f0b"
Expand All @@ -57790,10 +57806,6 @@
"name": "REVIEW REQUESTED",
"color": "6ff265"
},
{
"name": "s:baggage",
"color": "C5DEF5"
},
{
"name": "SR",
"color": "d93f0b"
Expand Down Expand Up @@ -98808,10 +98820,6 @@
"name": "collections",
"color": "1DF18E"
},
{
"name": "defer",
"color": "b60205"
},
{
"name": "documentation",
"color": "FADF83"
Expand All @@ -98836,6 +98844,10 @@
"name": "extension",
"color": "BAE508"
},
{
"name": "future edition",
"color": "b60205"
},
{
"name": "i18n-needs-resolution",
"color": "F9C9FF"
Expand Down Expand Up @@ -100604,7 +100616,7 @@
"body": "# Code of Conduct\n\nAll documentation, code, communication and discussion in this repository are covered by the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/).\n"
},
"readme": {
"text": "# W3C Security Interest Group\n\nThis GitHub repository serves the [W3C Security Interest Group](https://www.w3.org/groups/ig/security/). \n\n# Security Reviews\n\n* **Do you need a security review?** Open an [issue in the w3c/security-request repository](https://github.com/w3c/security-request/issues/new/choose)\n* **Would you like to do a security review?** Join us ([how to contribute](CONTRIBUTING.md)), and read the [how to review](https://github.com/w3c/securityig/blob/main/administration/how-to-review.md)\n* Thanks our [Security Reviewers](https://www.w3.org/PM/horizontal/leaderboard.html?repo=Security)\n \n# Administration\n\n* [Administration](https://github.com/w3c/securityig/administration)\n* [Meetings](https://github.com/w3c/securityig/meetings)\n\n# Tools \n\n* [Chair Dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=ig/security)\n* [Horizontal Dashboard](https://www.w3.org/PM/horizontal/board.html?name=Security)\n* [Comment Tracker](https://www.w3.org/PM/horizontal/?repo=w3c/security-review)\n\n# Pages\n* [Contribution guidelines](CONTRIBUTING.md)\n* [Governance and roles](GOVERNANCE.md)\n* [Code of Conduct](CODE_OF_CONDUCT.md)\n\n<!--\n\n**Here are some ideas to get you started:**\n\n🙋‍♀️ A short introduction - what is your organization all about?\n🌈 Contribution guidelines - how can the community get involved?\n👩‍💻 Useful resources - where can the community find your docs? Is there anything else the community should know?\n🍿 Fun facts - what does your team eat for breakfast?\n🧙 Remember, you can do mighty things with the power of [Markdown](https://docs.github.com/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax)\n-->\n"
"text": "# W3C Security Interest Group\n\nThis GitHub repository serves the [W3C Security Interest Group](https://www.w3.org/groups/ig/security/). \n\n# Security Reviews\n\n* **Do you need a security review?** Open an [issue in the w3c/security-request repository](https://github.com/w3c/security-request/issues/new/choose)\n* **Would you like to do a security review?** Join us ([how to contribute](CONTRIBUTING.md)), read the [how to review](https://github.com/w3c/securityig/blob/main/administration/how-to-review.md), and look at our [backlog](https://github.com/w3c/security-request/issues)\n* Thanks our [Security Reviewers](https://www.w3.org/PM/horizontal/leaderboard.html?repo=Security)\n \n# Administration\n\n* [Administration](https://github.com/w3c/securityig/administration)\n* [Meetings](https://github.com/w3c/securityig/meetings)\n\n# Tools \n\n* [Chair Dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=ig/security)\n* [Horizontal Dashboard](https://www.w3.org/PM/horizontal/board.html?name=Security)\n* [Comment Tracker](https://www.w3.org/PM/horizontal/?repo=w3c/security-review)\n\n# Pages\n* [Contribution guidelines](CONTRIBUTING.md)\n* [Governance and roles](GOVERNANCE.md)\n* [Code of Conduct](CODE_OF_CONDUCT.md)\n\n<!--\n\n**Here are some ideas to get you started:**\n\n🙋‍♀️ A short introduction - what is your organization all about?\n🌈 Contribution guidelines - how can the community get involved?\n👩‍💻 Useful resources - where can the community find your docs? Is there anything else the community should know?\n🍿 Fun facts - what does your team eat for breakfast?\n🧙 Remember, you can do mighty things with the power of [Markdown](https://docs.github.com/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax)\n-->\n"
},
"w3c": {
"group": [
Expand Down Expand Up @@ -169158,7 +169170,7 @@
"body": "Please find the code of conduct at https://github.com/WebAssembly/meetings/blob/main/CODE_OF_CONDUCT.md.\n"
},
"readme": {
"text": "[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.4323447.svg)](https://doi.org/10.5281/zenodo.4323447)\n \n# WebAssembly System Interface\n\n![WASI](WASI.png)\n\nThe WebAssembly System Interface (WASI) is a set of APIs for WASI being\ndeveloped for eventual standardization by the WASI Subgroup, which is a\nsubgroup of the WebAssembly Community Group.\n\nWASI started with launching what is now called [Preview 1], an API using\nthe witx IDL, and it is now widely used. Its major influences are POSIX and\nCloudABI.\n\n[WASI Preview 2] is now in development, which is a modular collection of\nAPIs defined with the [Wit IDL], and it incorporates many of the lessons\nlearned from Preview 1, including adding support for a wider range of\nsource languages, modularity, a more expressive type system,\nvirtualizability, and more.\n\n[Preview 1]: https://github.com/WebAssembly/WASI/tree/main/legacy/README.md\n[WASI Preview 2]: https://github.com/WebAssembly/WASI/blob/main/wasip2/README.md\n[Wit IDL]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md\n\n## Find the APIs\n\nDevelopment of each API happens in its own repo, which you can access\nfrom the [proposals list](Proposals.md).\n\nThis repo is for general discussion, as well as documenting how we work\nand high-level goals.\n\n## Propose a new API\n\nIf you would like to create a new proposal, get started with our\n[Contributing guide](Contributing.md).\n\nAll new API proposals should use the new format and the new repo structure that is shown in the [proposal template](https://github.com/WebAssembly/wasi-proposal-template).\n\nSee the [Wit in WASI](docs/WitInWasi.md) document for more information about using Wit for WASI proposals.\n\n## WASI High Level Goals\n\n(In the spirit of [WebAssembly's High-Level Goals](https://github.com/WebAssembly/design/blob/main/HighLevelGoals.md).)\n\n1. Define a set of portable, modular, runtime-independent, and\n WebAssembly-native APIs which can be used by WebAssembly code to interact\n with the outside world. These APIs preserve the essential sandboxed nature of\n WebAssembly through a [Capability-based] API design.\n2. Specify and implement incrementally. Start with a Minimum Viable Product\n (MVP), then adding additional features, prioritized by feedback and\n experience.\n3. Supplement API designs with documentation and tests, and, when feasible,\n reference implementations which can be shared between wasm engines.\n4. Make a great platform:\n * Work with WebAssembly tool and library authors to help them provide\n WASI support for their users.\n * When being WebAssembly-native means the platform isn't directly\n compatible with existing applications written for other platforms,\n design to enable compatibility to be provided by tools and libraries.\n * Allow the overall API to evolve over time; to make changes to API\n modules that have been standardized, build implementations of them\n using libraries on top of new API modules to provide compatibility.\n\n[Capability-based]: https://en.wikipedia.org/wiki/Capability-based_security\n\n## WASI Design Principles\n\n### Capability-based security\n\nWASI is designed with capability-based security principles, using the\nfacilities provided by the Wasm [component model]. All access to external\nresources is provided by capabilities.\n\nThere are two kinds of capabilities:\n\n - Handles, defined in the [component-model type system], dynamically\n identify and provide access to resources. They are unforgeable, meaning\n there's no way for an instance to acquire access to a handle other than\n to have another instance explicitly pass one to it.\n\n - Link-time capabilities, which are functions which require no handle\n arguments, are used sparingly, in situations where it's not necessary\n to identify more than one instance of a resource at runtime. Link-time\n capabilities are *interposable*, so they are still refusable in a\n capability-based security sense.\n\nWASI has no *ambient authorities*, meaning that there are no global\nnamespaces at runtime, and no global functions at link time.\n\n[component model]: https://github.com/WebAssembly/component-model\n[component-model type system]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#type-definitions\n\nNote that this is a different sense of \"capability\" than [Linux\ncapabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html)\nor the withdrawn [POSIX\ncapabilities](https://archive.org/details/posix_1003.1e-990310), which\nare per-process rather than per-resource.\n\n### Interposition\n\nInterposition in the context of WASI interfaces is the ability for a\nWebassembly instance to implement a given WASI interface, and for a\nconsumer WebAssembly instance to be able to use this implementation\ntransparently. This can be used to adapt or attenuate the functionality\nof a WASI API without changing the code using it.\n\nComponent model interfaces always support link-time interposition. While\nWASI APIs are often implemented in hosts, they can also be implemented\nin Wasm, which may itself be a wrapper around the host. This may be used\nto implement *attenuation*, providing filtered access to the underlying\nhost-provided functionality.\n\nInterposition is sometimes referred to as \"virtualization\", however we\nuse \"interposition\" here because the word \"virtualization\" has several\nrelated meanings.\n\n### Compatibility\n\nCompatibility with existing applications and libraries, as well as\nexisting host platforms, is important, but will sometimes be in conflict\nwith overall API cleanliness, safety, performance, or portability.\nWhere practical, WASI seeks to keep the WASI API itself free of\ncompatibility concerns, and provides compatibility through libraries,\nsuch as WASI libc, and tools. This way, applications which don't require\ncompatibility for compatibility's sake aren't burdened by it.\n\n### Portability\n\nPortability is important to WASI, however the meaning of portability\nwill be specific to each API.\n\nWASI's modular nature means that engines don't need to implement every\nAPI in WASI, so we don't need to exclude APIs just because some host\nenvironments can't implement them. We prefer APIs which can run across\na wide variety of engines when feasible, but we'll ultimately decide\nwhether something is \"portable enough\" on an API-by-API basis.\n\n### Modularity\n\nWASI will include many interfaces that are not appropriate for every host\nenvironment, so WASI uses the component model's worlds mechanism to allow\nspecific sets of APIs to be described which meet the needs of different\nenvironments.\n"
"text": "[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.4323447.svg)](https://doi.org/10.5281/zenodo.4323447)\n \n# WebAssembly System Interface\n\n![WASI](WASI.png)\n\nThe WebAssembly System Interface (WASI) is a set of APIs for WASI being\ndeveloped for eventual standardization by the WASI Subgroup, which is a\nsubgroup of the WebAssembly Community Group.\n\nWASI started with launching what is now called [Preview 1], an API using\nthe witx IDL, and it is now widely used. Its major influences are POSIX and\nCloudABI.\n\n[WASI Preview 2] is now stable, and is a modular collection of\nAPIs defined with the [Wit IDL], and it incorporates many of the lessons\nlearned from Preview 1, including adding support for a wider range of\nsource languages, modularity, a more expressive type system,\nvirtualizability, and more.\n\n[Preview 1]: https://github.com/WebAssembly/WASI/tree/main/legacy/README.md\n[WASI Preview 2]: https://github.com/WebAssembly/WASI/blob/main/wasip2/README.md\n[Wit IDL]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md\n\n## Find the APIs\n\nDevelopment of each API happens in its own repo, which you can access\nfrom the [proposals list](Proposals.md).\n\nThis repo is for general discussion, as well as documenting how we work\nand high-level goals.\n\n## Propose a new API\n\nIf you would like to create a new proposal, get started with our\n[Contributing guide](Contributing.md).\n\nAll new API proposals should use the new format and the new repo structure that is shown in the [proposal template](https://github.com/WebAssembly/wasi-proposal-template).\n\nSee the [Wit in WASI](docs/WitInWasi.md) document for more information about using Wit for WASI proposals.\n\n## WASI High Level Goals\n\n(In the spirit of [WebAssembly's High-Level Goals](https://github.com/WebAssembly/design/blob/main/HighLevelGoals.md).)\n\n1. Define a set of portable, modular, runtime-independent, and\n WebAssembly-native APIs which can be used by WebAssembly code to interact\n with the outside world. These APIs preserve the essential sandboxed nature of\n WebAssembly through a [Capability-based] API design.\n2. Specify and implement incrementally. Start with a Minimum Viable Product\n (MVP), then adding additional features, prioritized by feedback and\n experience.\n3. Supplement API designs with documentation and tests, and, when feasible,\n reference implementations which can be shared between wasm engines.\n4. Make a great platform:\n * Work with WebAssembly tool and library authors to help them provide\n WASI support for their users.\n * When being WebAssembly-native means the platform isn't directly\n compatible with existing applications written for other platforms,\n design to enable compatibility to be provided by tools and libraries.\n * Allow the overall API to evolve over time; to make changes to API\n modules that have been standardized, build implementations of them\n using libraries on top of new API modules to provide compatibility.\n\n[Capability-based]: https://en.wikipedia.org/wiki/Capability-based_security\n\n## WASI Design Principles\n\n### Capability-based security\n\nWASI is designed with capability-based security principles, using the\nfacilities provided by the Wasm [component model]. All access to external\nresources is provided by capabilities.\n\nThere are two kinds of capabilities:\n\n - Handles, defined in the [component-model type system], dynamically\n identify and provide access to resources. They are unforgeable, meaning\n there's no way for an instance to acquire access to a handle other than\n to have another instance explicitly pass one to it.\n\n - Link-time capabilities, which are functions which require no handle\n arguments, are used sparingly, in situations where it's not necessary\n to identify more than one instance of a resource at runtime. Link-time\n capabilities are *interposable*, so they are still refusable in a\n capability-based security sense.\n\nWASI has no *ambient authorities*, meaning that there are no global\nnamespaces at runtime, and no global functions at link time.\n\n[component model]: https://github.com/WebAssembly/component-model\n[component-model type system]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#type-definitions\n\nNote that this is a different sense of \"capability\" than [Linux\ncapabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html)\nor the withdrawn [POSIX\ncapabilities](https://archive.org/details/posix_1003.1e-990310), which\nare per-process rather than per-resource.\n\n### Interposition\n\nInterposition in the context of WASI interfaces is the ability for a\nWebassembly instance to implement a given WASI interface, and for a\nconsumer WebAssembly instance to be able to use this implementation\ntransparently. This can be used to adapt or attenuate the functionality\nof a WASI API without changing the code using it.\n\nComponent model interfaces always support link-time interposition. While\nWASI APIs are often implemented in hosts, they can also be implemented\nin Wasm, which may itself be a wrapper around the host. This may be used\nto implement *attenuation*, providing filtered access to the underlying\nhost-provided functionality.\n\nInterposition is sometimes referred to as \"virtualization\", however we\nuse \"interposition\" here because the word \"virtualization\" has several\nrelated meanings.\n\n### Compatibility\n\nCompatibility with existing applications and libraries, as well as\nexisting host platforms, is important, but will sometimes be in conflict\nwith overall API cleanliness, safety, performance, or portability.\nWhere practical, WASI seeks to keep the WASI API itself free of\ncompatibility concerns, and provides compatibility through libraries,\nsuch as WASI libc, and tools. This way, applications which don't require\ncompatibility for compatibility's sake aren't burdened by it.\n\n### Portability\n\nPortability is important to WASI, however the meaning of portability\nwill be specific to each API.\n\nWASI's modular nature means that engines don't need to implement every\nAPI in WASI, so we don't need to exclude APIs just because some host\nenvironments can't implement them. We prefer APIs which can run across\na wide variety of engines when feasible, but we'll ultimately decide\nwhether something is \"portable enough\" on an API-by-API basis.\n\n### Modularity\n\nWASI will include many interfaces that are not appropriate for every host\nenvironment, so WASI uses the component model's worlds mechanism to allow\nspecific sets of APIs to be described which meet the needs of different\nenvironments.\n"
}
},
{
Expand Down

0 comments on commit b3d81b6

Please sign in to comment.