mjolnir/yarn.lock

3623 lines
138 KiB
Plaintext
Raw Normal View History

2019-09-26 02:13:20 +00:00
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
"@alloc/quick-lru@^5.2.0":
version "5.2.0"
resolved "https://registry.npmjs.org/@alloc/quick-lru/-/quick-lru-5.2.0.tgz"
integrity sha512-UrcABB+4bUrFABwbluTIBErXwvbsU/V7TZWfmbgJfbkwiBuziS9gxdODUyuiecfdGQ85jglMW6juS3+z5TsKLw==
2023-04-03 20:03:02 +00:00
"@babel/code-frame@7.12.11", "@babel/code-frame@^7.0.0":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "7.12.11"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.12.11.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Zt1yodBx1UcyiePMSkWnU4hPqhwq7hGi2nFL1LeA3EUl+q2LQx16MISgJ0+z7dnmgvP9QtIleuETGOiOH1RcIw==
dependencies:
"@babel/highlight" "^7.10.4"
2023-04-03 20:03:02 +00:00
"@babel/code-frame@^7.12.13":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "7.14.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.14.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-9pzDqyc6OLDaqe+zbACgFkb6fKMNG6CObKpnYXChRsvYGyEdc7CA2BaqeOM+vOtCS5ndmJicPJhKAwYRI6UfFw==
dependencies:
"@babel/highlight" "^7.14.5"
2021-07-01 19:45:28 +00:00
"@babel/helper-validator-identifier@^7.14.5":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "7.15.7"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.15.7.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-K4JvCtQqad9OY2+yTU8w+E82ywk/fe+ELNlt1G8z3bVGlZfn/hOcQQsUhGhW/N+tb3fxK800wLtKOE/aM0m72w==
2019-09-26 02:13:20 +00:00
"@babel/highlight@^7.10.4", "@babel/highlight@^7.14.5":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "7.14.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@babel/highlight/-/highlight-7.14.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-qf9u2WFWVV0MppaL877j2dBtQIDgmidgjGk5VIMw3OadXvYaXn66U1BFlH2t4+t3i+8PhedppRv+i40ABzd+gg==
dependencies:
2021-07-01 19:45:28 +00:00
"@babel/helper-validator-identifier" "^7.14.5"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
chalk "^2.0.0"
js-tokens "^4.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
"@colors/colors@1.5.0":
version "1.5.0"
resolved "https://registry.npmjs.org/@colors/colors/-/colors-1.5.0.tgz"
integrity sha512-ooWCrlZP11i8GImSjTHYHLkvFDP48nS4+204nGb1RiX/WXYHmJA2III9/e2DWVabCESdW7hBAEzHRqUn9OUVvQ==
"@dabh/diagnostics@^2.0.2":
version "2.0.3"
resolved "https://registry.npmjs.org/@dabh/diagnostics/-/diagnostics-2.0.3.tgz"
integrity sha512-hrlQOIi7hAfzsMqlGSFyVucrx38O+j6wiGOf//H2ecvIEqYN4ADBSS2iLMh5UFyDunCNniUIPk/q3riFv45xRA==
dependencies:
colorspace "1.1.x"
enabled "2.0.x"
kuler "^2.0.0"
"@eslint/eslintrc@^0.4.3":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "0.4.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@eslint/eslintrc/-/eslintrc-0.4.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-J6KFFz5QCYUJq3pf0mjEcCJVERbzv71PUIDczuh9JkwGEzced6CO5ADLHB1rbf/+oPBtoPfMYNOpGDzCANlbXw==
dependencies:
ajv "^6.12.4"
debug "^4.1.1"
espree "^7.3.0"
globals "^13.9.0"
ignore "^4.0.6"
import-fresh "^3.2.1"
js-yaml "^3.13.1"
minimatch "^3.0.4"
strip-json-comments "^3.1.1"
"@humanwhocodes/config-array@^0.5.0":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "0.5.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@humanwhocodes/config-array/-/config-array-0.5.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-FagtKFz74XrTl7y6HCzQpwDfXP0yhxe9lHLD1UZxjvZIcbyRz8zTFF/yYNfSfzU414eDwZ1SrO0Qvtyf+wFMQg==
dependencies:
"@humanwhocodes/object-schema" "^1.2.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
debug "^4.1.1"
minimatch "^3.0.4"
"@humanwhocodes/object-schema@^1.2.0":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@humanwhocodes/object-schema/-/object-schema-1.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-wdppn25U8z/2yiaT6YGquE6X8sSv7hNMWSXYSSU1jGv/yd6XqjXgTDJ8KP4NgjTXfJ3GbRjeeb8RTV7a/VpM+w==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
"@jest/types@^27.2.4":
version "27.2.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@jest/types/-/types-27.2.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-IDO2ezTxeMvQAHxzG/ZvEyA47q0aVfzT95rGFl7bZs/Go0aIucvfDbS2rmnoEdXxlLQhcolmoG/wvL/uKx4tKA==
2020-04-14 22:17:05 +00:00
dependencies:
"@types/istanbul-lib-coverage" "^2.0.0"
2021-07-01 19:45:28 +00:00
"@types/istanbul-reports" "^3.0.0"
"@types/node" "*"
"@types/yargs" "^16.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
chalk "^4.0.0"
2020-04-14 22:17:05 +00:00
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
"@matrix-org/matrix-sdk-crypto-nodejs@^0.1.0-beta.1":
version "0.1.0-beta.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@matrix-org/matrix-sdk-crypto-nodejs/-/matrix-sdk-crypto-nodejs-0.1.0-beta.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-jCSKrmNh6kaqnOwS/Pqgqkeb+CAvwGuS0oNEW3LaWKrJWFAfUrt+lXBCs7kAP79Qo5ZKBU06BekbZuwYhWbhkQ==
dependencies:
node-downloader-helper "^2.1.1"
"@selderee/plugin-htmlparser2@^0.6.0":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "0.6.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@selderee/plugin-htmlparser2/-/plugin-htmlparser2-0.6.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-J3jpy002TyBjd4N/p6s+s90eX42H2eRhK3SbsZuvTDv977/E8p2U3zikdiehyJja66do7FlxLomZLPlvl2/xaA==
dependencies:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
domhandler "^4.2.0"
selderee "^0.6.0"
"@sentry/core@7.22.0":
version "7.22.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@sentry/core/-/core-7.22.0.tgz"
integrity sha512-qYJiJrL1mfQQln84mNunBRUkXq7xDGQQoNh4Sz9VYP5698va51zmS5BLYRCZ5CkPwRYNuhUqlUXN7bpYGYOOIA==
dependencies:
"@sentry/types" "7.22.0"
"@sentry/utils" "7.22.0"
tslib "^1.9.3"
"@sentry/node@^7.17.2":
version "7.22.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@sentry/node/-/node-7.22.0.tgz"
integrity sha512-jKhxqKsbEEaY/g3FTzpj1fwukN0IkNv4V+0Fl+t/EmSNUL/7q5FMmDBa+fFQuQzwps8UEpzqPOzMSRapVsoP0w==
dependencies:
"@sentry/core" "7.22.0"
"@sentry/types" "7.22.0"
"@sentry/utils" "7.22.0"
cookie "^0.4.1"
https-proxy-agent "^5.0.0"
lru_map "^0.3.3"
tslib "^1.9.3"
"@sentry/tracing@^7.17.2":
version "7.22.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@sentry/tracing/-/tracing-7.22.0.tgz"
integrity sha512-s68aSnrRaWQ+Z5oG9ozIegUkofZy9PwicuXYEPA8K/R30F1CVpHvDZ/3KlFnByl+aXTbAyLBQzN2sAObB5g4pQ==
dependencies:
"@sentry/core" "7.22.0"
"@sentry/types" "7.22.0"
"@sentry/utils" "7.22.0"
tslib "^1.9.3"
"@sentry/types@7.22.0":
version "7.22.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@sentry/types/-/types-7.22.0.tgz"
integrity sha512-LhCL+wb1Jch+OesB2CIt6xpfO1Ab6CRvoNYRRzVumWPLns1T3ZJkarYfhbLaOEIb38EIbPgREdxn2AJT560U4Q==
"@sentry/utils@7.22.0":
version "7.22.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@sentry/utils/-/utils-7.22.0.tgz"
integrity sha512-1GiNw1opIngxg0nktCTc9wibh4/LV12kclrnB9dAOHrqazZXHXZRAkjqrhQphKcMpT+3By91W6EofjaDt5a/hg==
dependencies:
"@sentry/types" "7.22.0"
tslib "^1.9.3"
"@tootallnate/once@1":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.1.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@tootallnate/once/-/once-1.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-RbzJvlNzmRq5c3O09UipeuXno4tA1FE6ikOjxZK0tuxVv3412l64l5t1W5pj4+rJq9vpkm/kwiR07aZXnsKPxw==
"@types/body-parser@*":
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "1.19.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@types/body-parser/-/body-parser-1.19.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-ALYone6pm6QmwZoAgeyNksccT9Q4AWZQ6PvfwR37GT6r6FWUPguq6sUmNGSMV2Wr761oQoBxwGGa6DR5o1DC9g==
dependencies:
"@types/connect" "*"
"@types/node" "*"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
"@types/caseless@*":
version "0.12.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@types/caseless/-/caseless-0.12.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-6ckxMjBBD8URvjB6J3NcnuAn5Pkl7t3TizAg+xdlzzQGSPSmBcXf8KoIH0ua/i+tio+ZRUHEXp0HEmvaR4kt0w==
"@types/config@^3.3.0":
version "3.3.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@types/config/-/config-3.3.0.tgz"
integrity sha512-9kZSbl3/X3TVNowLCu5HFQdQmD+4287Om55avknEYkuo6R2dDrsp/EXEHUFvfYeG7m1eJ0WYGj+cbcUIhARJAQ==
"@types/connect@*":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "3.4.35"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/connect/-/connect-3.4.35.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-cdeYyv4KWoEgpBISTxWvqYsVy444DOqehiF3fM3ne10AmJ62RSyNkUnxMJXHQWRQQX2eR94m5y1IZyDwBjV9FQ==
dependencies:
"@types/node" "*"
"@types/crypto-js@^4.0.2":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "4.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/crypto-js/-/crypto-js-4.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-sCVniU+h3GcGqxOmng11BRvf9TfN9yIs8KKjB8C8d75W69cpTfZG80gau9yTx5SxF3gvHGbJhdESzzvnjtf3Og==
2021-07-01 19:45:28 +00:00
"@types/express-serve-static-core@^4.17.18":
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "4.17.30"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@types/express-serve-static-core/-/express-serve-static-core-4.17.30.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-gstzbTWro2/nFed1WXtf+TtrpwxH7Ggs4RLYTLbeVgIkUQOI3WG/JKjgeOU1zXDvezllupjrf8OPIdvTbIaVOQ==
2021-07-01 19:45:28 +00:00
dependencies:
"@types/node" "*"
"@types/qs" "*"
"@types/range-parser" "*"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
"@types/express@^4.17.13", "@types/express@^4.17.8":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "4.17.13"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/express/-/express-4.17.13.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-6bSZTPaTIACxn48l50SR+axgrqm6qXFIxrdAKaG6PaJk3+zuUr35hBlgT7vOmJcum+OEaIBLtHV/qloEAFITeA==
dependencies:
"@types/body-parser" "*"
2021-07-01 19:45:28 +00:00
"@types/express-serve-static-core" "^4.17.18"
"@types/qs" "*"
"@types/serve-static" "*"
"@types/html-to-text@^8.0.1":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "8.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/html-to-text/-/html-to-text-8.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-0B/OifmJYmk5r9z9+KJtGWOF0LEjbTN4D2QeCh+mAw81JkJwC83NvNWUZFEqRT5PpnjX7vX0ab1SMGcwCs3Lag==
"@types/humanize-duration@^3.27.1":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "3.27.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/humanize-duration/-/humanize-duration-3.27.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-K3e+NZlpCKd6Bd/EIdqjFJRFHbrq5TzPPLwREk5Iv/YoIjQrs6ljdAUCo+Lb2xFlGNOjGSE0dqsVD19cZL137w==
"@types/istanbul-lib-coverage@*", "@types/istanbul-lib-coverage@^2.0.0":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "2.0.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/istanbul-lib-coverage/-/istanbul-lib-coverage-2.0.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-sz7iLqvVUg1gIedBOvlkxPlc8/uVzyS5OwGz1cKjXzkl3FpL3al0crU8YGU1WoHkxn0Wxbw5tyi6hvzJKNzFsw==
"@types/istanbul-lib-report@*":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "3.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/istanbul-lib-report/-/istanbul-lib-report-3.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-plGgXAPfVKFoYfa9NpYDAkseG+g6Jr294RqeqcqDixSbU34MZVJRi/P+7Y8GDpzkEwLaGZZOpKIEmeVZNtKsrg==
dependencies:
"@types/istanbul-lib-coverage" "*"
2021-07-01 19:45:28 +00:00
"@types/istanbul-reports@^3.0.0":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "3.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/istanbul-reports/-/istanbul-reports-3.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-c3mAZEuK0lvBp8tmuL74XRKn1+y2dcwOUpH7x4WrF6gk1GIgiluDRgMYQtw2OFcBvAJWlt6ASU3tSqxp0Uu0Aw==
dependencies:
"@types/istanbul-lib-report" "*"
"@types/js-yaml@^4.0.5":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "4.0.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/js-yaml/-/js-yaml-4.0.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-FhpRzf927MNQdRZP0J5DLIdTXhjLYzeUTmLAu69mnVksLH9CJY3IuSeEgbKUki7GQZm0WqDkGzyxju2EZGD2wA==
"@types/jsdom@^16.2.11":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "16.2.13"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/jsdom/-/jsdom-16.2.13.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-8JQCjdeAidptSsOcRWk2iTm9wCcwn9l+kRG6k5bzUacrnm1ezV4forq0kWjUih/tumAeoG+OspOvQEbbRucBTw==
dependencies:
"@types/node" "*"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
"@types/parse5" "*"
"@types/tough-cookie" "*"
"@types/json5@^0.0.29":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "0.0.29"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/json5/-/json5-0.0.29.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-dRLjCWHYg4oaA77cxO64oO+7JwCwnIzkZPdrrC71jQmQtlhM556pwKo5bUzqvZndkVbeFLIIi+9TC40JNF5hNQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
"@types/mime@^1":
version "1.3.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/mime/-/mime-1.3.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-YATxVxgRqNH6nHEIsvg6k2Boc1JHI9ZbH5iWFFv/MTkchz3b1ieGDa5T0a9RznNdI0KhVbdbWSN+KWWrQZRxTw==
"@types/mocha@^9.0.0":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "9.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/mocha/-/mocha-9.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-scN0hAWyLVAvLR9AyW7HoFF5sJZglyBsbPuHO4fv7JRvfmPBMfp1ozWqOf/e4wwPNxezBZXRfWzMb6iFLgEVRA==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
"@types/nedb@^1.8.12":
version "1.8.12"
resolved "https://registry.npmjs.org/@types/nedb/-/nedb-1.8.12.tgz"
integrity sha512-ICDoQMORMjOSqfNFXT4ENXfwwCir1BPblXNm0SPH7C4Q10ou+pvVagcFAJ+rrzf3A47tGU4K/KbzKu7wO9j45Q==
dependencies:
"@types/node" "*"
"@types/node@*":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "16.10.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@types/node/-/node-16.10.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-zCclL4/rx+W5SQTzFs9wyvvyCwoK9QtBpratqz2IYJ3O8Umrn0m3nsTv0wQBk9sRGpvUe9CwPDrQFB10f1FIjQ==
"@types/node@^18.0.0":
version "18.18.9"
resolved "https://registry.yarnpkg.com/@types/node/-/node-18.18.9.tgz#5527ea1832db3bba8eb8023ce8497b7d3f299592"
integrity sha512-0f5klcuImLnG4Qreu9hPj/rEfFq6YRc5n2mAjSsH+ec/mJL+3voBH0+8T7o8RpFjH7ovc+TRsL/c7OYIQsPTfQ==
dependencies:
undici-types "~5.26.4"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
"@types/parse5@*":
version "6.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/parse5/-/parse5-6.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ARATsLdrGPUnaBvxLhUlnltcMgn7pQG312S8ccdYlnyijabrX9RN/KN/iGj9Am96CoW8e/K9628BA7Bv4XHdrA==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
"@types/pg@^8.6.5":
version "8.6.5"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@types/pg/-/pg-8.6.5.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-tOkGtAqRVkHa/PVZicq67zuujI4Oorfglsr2IbKofDwBSysnaqSx7W1mDqFqdkGE6Fbgh+PZAl0r/BWON/mozw==
dependencies:
"@types/node" "*"
pg-protocol "*"
pg-types "^2.2.0"
"@types/pkginfo@^0.4.0":
version "0.4.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@types/pkginfo/-/pkginfo-0.4.0.tgz"
integrity sha512-4DGKkOlWkMuVDZQvytWzzWWAjyqDmlLKRYE4lzeA8t0s7fK0aF25uPbX9eBVermUjLJdeLHu9k1WmNiAssqCcg==
dependencies:
"@types/node" "*"
2021-07-01 19:45:28 +00:00
"@types/qs@*":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "6.9.7"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/qs/-/qs-6.9.7.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-FGa1F62FT09qcrueBA6qYTrJPVDzah9a+493+o2PCXsesWHIn27G98TsSMs3WPNbZIEj4+VJf6saSFpvD+3Zsw==
2021-07-01 19:45:28 +00:00
"@types/range-parser@*":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.2.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/range-parser/-/range-parser-1.2.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-EEhsLsD6UsDM1yFhAvy0Cjr6VwmpMWqFBCb9w07wVugF7w9nfajxLuVmngTIpgS6svCnm6Vaw+MZhoDCKnOfsw==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
"@types/request@^2.48.8":
version "2.48.8"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/@types/request/-/request-2.48.8.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-whjk1EDJPcAR2kYHRbFl/lKeeKYTi05A15K9bnLInCVroNDCtXce57xKdI0/rQaA3K+6q0eFyUBPmqfSndUZdQ==
dependencies:
"@types/caseless" "*"
"@types/node" "*"
"@types/tough-cookie" "*"
form-data "^2.5.0"
"@types/serve-static@*":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.13.10"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/serve-static/-/serve-static-1.13.10.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-nCkHGI4w7ZgAdNkrEu0bv+4xNV/XDqW+DydknebMOQwkpDGx8G+HTlj7R7ABI8i8nKxVw0wtKPi1D+lPOkh4YQ==
dependencies:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
"@types/mime" "^1"
"@types/node" "*"
"@types/shell-quote@1.7.1":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.7.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/shell-quote/-/shell-quote-1.7.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-SWZ2Nom1pkyXCDohRSrkSKvDh8QOG9RfAsrt5/NsPQC4UQJ55eG0qClA40I+Gkez4KTQ0uDUT8ELRXThf3J5jw==
2021-07-01 19:45:28 +00:00
"@types/stack-utils@^2.0.0":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "2.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/stack-utils/-/stack-utils-2.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Hl219/BT5fLAaz6NDkSuhzasy49dwQS/DSdu4MdggFB8zcXv7vflBI3xp7FEmkmdDkBUI2bPUNeMttp2knYdxw==
"@types/tough-cookie@*":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "4.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/tough-cookie/-/tough-cookie-4.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Y0K95ThC3esLEYD6ZuqNek29lNX2EM1qxV8y2FTLUB0ff5wWrk7az+mLrnNFUnaXcgKye22+sFBRXOgpPILZNg==
"@types/yargs-parser@*":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "20.2.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/yargs-parser/-/yargs-parser-20.2.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-7tFImggNeNBVMsn0vLrpn1H1uPrUBdnARPTpZoitY37ZrdJREzf7I16tMrlK3hen349gr1NYh8CmZQa7CTG6Aw==
2021-07-01 19:45:28 +00:00
"@types/yargs@^16.0.0":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "16.0.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@types/yargs/-/yargs-16.0.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-T8Yc9wt/5LbJyCaLiHPReJa0kApcIgJ7Bn735GjItUfh08Z1pJvu8QZqb9s+mMvKV6WUQRV7K2R46YbjMXTTJw==
dependencies:
"@types/yargs-parser" "*"
2021-07-01 19:45:28 +00:00
"@ungap/promise-all-settled@1.1.2":
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/@ungap/promise-all-settled/-/promise-all-settled-1.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-sL/cEvJWAnClXw0wHk85/2L0G6Sj8UB0Ctc1TEMbKSsmpRosqhwj9gWgFRZSrBr2f9tiXISwNhCPmlfqUqyb9Q==
abab@^2.0.3, abab@^2.0.5:
version "2.0.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/abab/-/abab-2.0.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-9IK9EadsbHo6jLWIpxpR6pL0sazTXV6+SQv25ZB+F7Bj9mJNaOc4nCRabwd5M/JwmUa8idz6Eci6eKfJryPs6Q==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
abbrev@1:
version "1.1.1"
resolved "https://registry.npmjs.org/abbrev/-/abbrev-1.1.1.tgz"
integrity sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q==
accepts@~1.3.8:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "1.3.8"
resolved "https://registry.npmjs.org/accepts/-/accepts-1.3.8.tgz"
integrity sha512-PYAthTa2m2VKxuvSD3DPC/Gy+U+sOA1LAuT8mkmRuvw+NACSaeXEQ+NHcVF7rONl6qcaxV3Uuemwawk+7+SJLw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
mime-types "~2.1.34"
negotiator "0.6.3"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
acorn-globals@^6.0.0:
version "6.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/acorn-globals/-/acorn-globals-6.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ZQl7LOWaF5ePqqcX4hLuv/bLXYQNfNWw2c0/yX/TsPRKamzHcTGQnlCjHT3TsmkOUVEPS3crCxiPfdzE/Trlhg==
dependencies:
acorn "^7.1.1"
acorn-walk "^7.1.1"
acorn-jsx@^5.3.1:
version "5.3.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/acorn-jsx/-/acorn-jsx-5.3.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-rq9s+JNhf0IChjtDXxllJ7g41oZk5SlXtp0LHwyA5cejwn7vKmKp4pPri6YEePv2PU65sAsegbXtIinmDFDXgQ==
acorn-walk@^7.1.1:
version "7.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/acorn-walk/-/acorn-walk-7.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-OPdCF6GsMIP+Az+aWfAAOEt2/+iVDKE7oy6lJ098aoe59oAmK76qV6Gw60SbZ8jHuG2wH058GF4pLFbYamYrVA==
acorn@^7.1.1, acorn@^7.4.0:
version "7.4.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/acorn/-/acorn-7.4.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-nQyp0o1/mNdbTO1PO6kHkwSrmgZ0MT/jCCpNiwbUjGoRN4dlBhqJtoQuCnEOKzgTVwg0ZWiCoQy6SxMebQVh8A==
acorn@^8.2.4:
version "8.5.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/acorn/-/acorn-8.5.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-yXbYeFy+jUuYd3/CDcg2NkIYE991XYX/bje7LmjJigUciaeO1JR4XxXgCIV1/Zc/dRuFEyw1L0pbA+qynJkW5Q==
agent-base@6:
version "6.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/agent-base/-/agent-base-6.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-RZNwNclF7+MS/8bDg70amg32dyeZGZxiDuQmZxKLAlQjr3jGyLx+4Kkk58UO7D2QdgFIQCovuSuZESne6RG6XQ==
dependencies:
debug "4"
ajv@^6.10.0, ajv@^6.12.3, ajv@^6.12.4:
version "6.12.6"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ajv/-/ajv-6.12.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==
dependencies:
fast-deep-equal "^3.1.1"
fast-json-stable-stringify "^2.0.0"
json-schema-traverse "^0.4.1"
uri-js "^4.2.2"
ajv@^8.0.1:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "8.11.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/ajv/-/ajv-8.11.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-wGgprdCvMalC0BztXvitD2hC04YffAvtsUn93JbGXYLAtCUO4xd17mCCZQxUOItiBwZvJScWo8NIvQMQ71rdpg==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
fast-deep-equal "^3.1.1"
json-schema-traverse "^1.0.0"
require-from-string "^2.0.2"
uri-js "^4.2.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
another-json@^0.2.0:
version "0.2.0"
resolved "https://registry.npmjs.org/another-json/-/another-json-0.2.0.tgz"
integrity sha512-/Ndrl68UQLhnCdsAzEXLMFuOR546o2qbYRqCglaNHbjXrwG1ayTcdwr3zkSGOGtGXDyR5X9nCFfnyG2AFJIsqg==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
ansi-colors@4.1.1, ansi-colors@^4.1.1:
version "4.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ansi-colors/-/ansi-colors-4.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-JoX0apGbHaUJBNl6yF+p6JAFYZ666/hhCGKN5t9QFjbJQKUU/g8MNbFDbvfrgKXvI1QpZplPOnwIo99lX/AAmA==
ansi-regex@^5.0.1:
version "5.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==
ansi-styles@^3.2.1:
version "3.2.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==
dependencies:
color-convert "^1.9.0"
ansi-styles@^4.0.0, ansi-styles@^4.1.0:
version "4.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==
dependencies:
color-convert "^2.0.1"
ansi-styles@^5.0.0:
version "5.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ansi-styles/-/ansi-styles-5.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Cxwpt2SfTzTtXcfOlzGEee8O+c+MmUgGrNiBcXnuWxuFJHe6a5Hz7qwhwe5OgaSYI0IJvkLqWX1ASG+cJOkEiA==
anymatch@~3.1.2:
version "3.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/anymatch/-/anymatch-3.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-P43ePfOAIupkguHUycrc4qJ9kz8ZiuOUijaETwX7THt0Y/GNK7v0aa8rY816xWjZ7rJdA5XdMcpVFTKMq+RvWg==
dependencies:
normalize-path "^3.0.0"
picomatch "^2.0.4"
argparse@^1.0.7:
version "1.0.10"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/argparse/-/argparse-1.0.10.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==
dependencies:
sprintf-js "~1.0.2"
argparse@^2.0.1:
version "2.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==
array-flatten@1.1.1:
version "1.1.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/array-flatten/-/array-flatten-1.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-PCVAQswWemu6UdxsDFFX/+gVeYqKAod3D3UVm91jHwynguOwAvYPhx8nNlM++NqRcK6CxxpUafjmhIdKiHibqg==
arrify@^1.0.0:
version "1.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/arrify/-/arrify-1.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-3CYzex9M9FGQjCGMGyi6/31c8GJbgb0qGyrx5HWxPd0aCwh4cB2YjMb2Xf9UuoogrMrlO9cTqnB5rI5GHZTcUA==
asn1@~0.2.3:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "0.2.6"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/asn1/-/asn1-0.2.6.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-ix/FxPn0MDjeyJ7i/yoHGFt/EX6LyNbxSEhPPXODPL+KB0VPk86UYfL0lMdy+KCnv+fmvIzySwaK5COwqVbWTQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
safer-buffer "~2.1.0"
assert-plus@1.0.0, assert-plus@^1.0.0:
version "1.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/assert-plus/-/assert-plus-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-NfJ4UzBCcQGLDlQq7nHxH+tv3kyZ0hHQqF5BO6J7tNJeP5do1llPr8dZ8zHonfhAu0PHAdMkSo+8o0wxg9lZWw==
astral-regex@^2.0.0:
version "2.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/astral-regex/-/astral-regex-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Z7tMw1ytTXt5jqMcOP+OQteU1VuNK9Y02uuJtKQ1Sv69jXQKKg5cibLwGJow8yzZP+eAc18EmLGPal0bp36rvQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
async-lock@^1.3.2:
version "1.3.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/async-lock/-/async-lock-1.3.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-phnXdS3RP7PPcmP6NWWzWMU0sLTeyvtZCxBPpZdkYE3seGLKSQZs9FrmVO/qwypq98FUtWWUEYxziLkdGk5nnA==
async@0.2.10:
version "0.2.10"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/async/-/async-0.2.10.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-eAkdoKxU6/LkKDBzLpT+t6Ff5EtfSF4wx1WfJiPEEV7WNLnDaRXk0oVysiEPm262roaachGexwUv94WhSgN5TQ==
async@^3.2.3:
version "3.2.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/async/-/async-3.2.4.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-iAB+JbDEGXhyIUavoDl9WP/Jj106Kz9DEn1DPgYw5ruDn0e3Wgi3sKFm55sASdGBNOQB8F59d9qQ7deqrHA8wQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
asynckit@^0.4.0:
version "0.4.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/asynckit/-/asynckit-0.4.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Oei9OH4tRh0YqU3GxhX79dM/mwVgvbZJaSNaRk+bshkj0S5cfHcgYakreBjrHwatXKbz+IoIdYLxrKim2MjW0Q==
await-lock@^2.2.2:
version "2.2.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/await-lock/-/await-lock-2.2.2.tgz"
integrity sha512-aDczADvlvTGajTDjcjpJMqRkOF6Qdz3YbPZm/PyW6tKPkx2hlYBzxMhEywM/tU72HrVZjgl5VCdRuMlA7pZ8Gw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
aws-sign2@~0.7.0:
version "0.7.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/aws-sign2/-/aws-sign2-0.7.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-08kcGqnYf/YmjoRhfxyu+CLxBjUtHLXLXX/vUfx9l2LYzG3c1m61nrpyFUZI6zeS+Li/wWMMidD9KgrqtGq3mA==
aws4@^1.8.0:
version "1.11.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/aws4/-/aws4-1.11.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-xh1Rl34h6Fi1DC2WWKfxUTVqRsNnr6LsKz2+hfwDxQJWmrx8+c7ylaqBMcHfl1U1r2dsifOvKX3LQuLNZ+XSvA==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
axios@^0.27.2:
version "0.27.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/axios/-/axios-0.27.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-t+yRIyySRTp/wua5xEr+z1q60QmLq8ABsS5O9Me1AsE5dfKqgnCFzwiCZZ/cGNd1lq4/7akDWMxdhVlucjmnOQ==
dependencies:
follow-redirects "^1.14.9"
form-data "^4.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
balanced-match@^1.0.0:
version "1.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==
basic-auth@~2.0.1:
version "2.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/basic-auth/-/basic-auth-2.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-NF+epuEdnUYVlGuhaxbbq+dvJttwLnGY+YixlXlME5KpQ5W3CnXA5cVTneY3SPbPDRkcjMbifrwmFYcClgOZeg==
dependencies:
safe-buffer "5.1.2"
bcrypt-pbkdf@^1.0.0:
version "1.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/bcrypt-pbkdf/-/bcrypt-pbkdf-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-qeFIXtP4MSoi6NLqO12WfqARWWuCKi2Rn/9hJLEmtB5yTNr9DqFWkJRCf2qShWzPeAMRnOgCrq0sg/KLv5ES9w==
dependencies:
tweetnacl "^0.14.3"
binary-extensions@^2.0.0:
version "2.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-jDctJ/IVQbZoJykoeHbhXpOlNBqGNcwXJKJog42E5HDPUwQTSdjCHdihjj0DlnheQ7blbT6dHOafNAiS8ooQKA==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
binary-search-tree@0.2.5:
version "0.2.5"
resolved "https://registry.npmjs.org/binary-search-tree/-/binary-search-tree-0.2.5.tgz"
integrity sha512-CvNVKS6iXagL1uGwLagSXz1hzSMezxOuGnFi5FHGKqaTO3nPPWrAbyALUzK640j+xOTVm7lzD9YP8W1f/gvUdw==
dependencies:
underscore "~1.4.4"
bintrees@1.0.2:
version "1.0.2"
resolved "https://registry.npmjs.org/bintrees/-/bintrees-1.0.2.tgz"
integrity sha512-VOMgTMwjAaUG580SXn3LacVgjurrbMme7ZZNYGSSV7mmtY6QQRh0Eg3pwIcntQ77DErK1L0NxkbetjcoXzVwKw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
bluebird@^3.5.0:
version "3.7.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/bluebird/-/bluebird-3.7.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-XpNj6GDQzdfW+r2Wnn7xiSAd7TM3jzkxGXBGTtWKuSXv1xUV+azxAm8jdWZN06QTQk+2N2XB9jRDkvbmQmcRtg==
body-parser@1.20.0:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "1.20.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/body-parser/-/body-parser-1.20.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-DfJ+q6EPcGKZD1QWUjSpqp+Q7bDQTsQIF4zfUAtZ6qk+H/3/QRhg9CEp39ss+/T2vw0+HaidC0ecJj/DRLIaKg==
dependencies:
bytes "3.1.2"
content-type "~1.0.4"
debug "2.6.9"
depd "2.0.0"
destroy "1.2.0"
http-errors "2.0.0"
iconv-lite "0.4.24"
on-finished "2.4.1"
qs "6.10.3"
raw-body "2.5.1"
type-is "~1.6.18"
unpipe "1.0.0"
body-parser@^1.19.0, body-parser@^1.20.1:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "1.20.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/body-parser/-/body-parser-1.20.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-jWi7abTbYwajOytWCQc37VulmWiRae5RyTpaCyDcS5/lMdtwSz5lOpDE67srw/HYe35f1z3fDQw+3txg7gNtWw==
dependencies:
bytes "3.1.2"
content-type "~1.0.4"
debug "2.6.9"
depd "2.0.0"
destroy "1.2.0"
http-errors "2.0.0"
iconv-lite "0.4.24"
on-finished "2.4.1"
qs "6.11.0"
raw-body "2.5.1"
type-is "~1.6.18"
unpipe "1.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
brace-expansion@^1.1.7:
version "1.1.11"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==
dependencies:
balanced-match "^1.0.0"
concat-map "0.0.1"
braces@^3.0.1, braces@~3.0.2:
version "3.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==
dependencies:
fill-range "^7.0.1"
browser-process-hrtime@^1.0.0:
version "1.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/browser-process-hrtime/-/browser-process-hrtime-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-9o5UecI3GhkpM6DrXr69PblIuWxPKk9Y0jHBRhdocZ2y7YECBFCsHm79Pr3OyR2AvjhDkabFJaDJMYRazHgsow==
browser-stdout@1.3.1:
version "1.3.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/browser-stdout/-/browser-stdout-1.3.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-qhAVI1+Av2X7qelOfAIYwXONood6XlZE/fXaBSmW/T5SzLAmCgzi+eiWE7fUvbHaeNBQH13UftjpXxsfLkMpgw==
buffer-from@^1.0.0, buffer-from@^1.1.0:
version "1.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
buffer-writer@2.0.0:
version "2.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/buffer-writer/-/buffer-writer-2.0.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-a7ZpuTZU1TRtnwyCNW3I5dc0wWNC3VR9S++Ewyk2HHZdrO3CQJqSpd+95Us590V6AL7JqUAH2IwZ/398PmNFgw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
builtin-modules@^1.1.1:
version "1.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/builtin-modules/-/builtin-modules-1.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-wxXCdllwGhI2kCC0MnvTGYTMvnVZTvqgypkiTI8Pa5tcz2i6VqsqwYGgqwXji+4RgCzms6EajE4IxiUH6HH8nQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
bytes@3.1.2:
version "3.1.2"
resolved "https://registry.npmjs.org/bytes/-/bytes-3.1.2.tgz"
integrity sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==
call-bind@^1.0.0:
version "1.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/call-bind/-/call-bind-1.0.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-7O+FbCihrB5WGbFYesctwmTKae6rOiIzmz1icreWJ+0aA7LJfuqhEso2T9ncpcFtzMQtzXf2QGGueWJGTYsqrA==
dependencies:
function-bind "^1.1.1"
get-intrinsic "^1.0.2"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
callsites@^3.0.0:
version "3.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/callsites/-/callsites-3.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-P8BjAsXvZS+VIDUI11hHCQEv74YT67YUi5JJFNWIqL235sBmjX4+qx9Muvls5ivyNENctx46xQLQ3aTuE7ssaQ==
camelcase@^6.0.0:
version "6.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/camelcase/-/camelcase-6.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-c7wVvbw3f37nuobQNtgsgG9POC9qMbNuMQmTCqZv23b6MIz0fcYpBiOlv9gEN/hdLdnZTDQhg6e9Dq5M1vKvfg==
caseless@~0.12.0:
version "0.12.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/caseless/-/caseless-0.12.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-4tYFyifaFfGacoiObjJegolkwSU4xQNGbVgUiNYVUxbQ2x2lUsFvY4hVgVzGiIe6WLOPqycWXA40l+PWsxthUw==
chalk@^2.0.0, chalk@^2.3.0:
version "2.4.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==
dependencies:
ansi-styles "^3.2.1"
escape-string-regexp "^1.0.5"
supports-color "^5.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
chalk@^4, chalk@^4.0.0, chalk@^4.1.0:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "4.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/chalk/-/chalk-4.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA==
dependencies:
ansi-styles "^4.1.0"
supports-color "^7.1.0"
chokidar@3.5.3:
version "3.5.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/chokidar/-/chokidar-3.5.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Dr3sfKRP6oTcjf2JmUmFJfeVMvXBdegxB0iVQ5eb2V10uFJUCAS8OByZdVAyVb8xXNz3GjjTgj9kLWsZTqE6kw==
dependencies:
anymatch "~3.1.2"
braces "~3.0.2"
glob-parent "~5.1.2"
is-binary-path "~2.1.0"
is-glob "~4.0.1"
normalize-path "~3.0.0"
readdirp "~3.6.0"
2020-04-14 22:17:05 +00:00
optionalDependencies:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
fsevents "~2.3.2"
cliui@^7.0.2:
version "7.0.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/cliui/-/cliui-7.0.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-OcRE68cOsVMXp1Yvonl/fzkQOyjLSu/8bhPDfQt0e0/Eb283TKP20Fs2MqoPsr9SwA595rRCA+QMzYc9nBP+JQ==
dependencies:
string-width "^4.2.0"
strip-ansi "^6.0.0"
wrap-ansi "^7.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
color-convert@^1.9.0, color-convert@^1.9.3:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.9.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/color-convert/-/color-convert-1.9.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-QfAUtd+vFdAtFQcC8CCyYt1fYWxSqAiK2cSD6zDB8N3cpsEBAvRxp9zOGg6G/SHHJYAT88/az/IuDGALsNVbGg==
dependencies:
color-name "1.1.3"
color-convert@^2.0.1:
version "2.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==
dependencies:
color-name "~1.1.4"
color-name@1.1.3:
version "1.1.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/color-name/-/color-name-1.1.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-72fSenhMw2HZMTVHeCA9KCmpEIbzWiQsjN+BHcBbS9vr1mtt+vJjPdksIBNUmKAW8TFUDPJK5SUU3QhE9NEXDw==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
color-name@^1.0.0, color-name@~1.1.4:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.1.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
color-string@^1.6.0:
version "1.9.1"
resolved "https://registry.npmjs.org/color-string/-/color-string-1.9.1.tgz"
integrity sha512-shrVawQFojnZv6xM40anx4CkoDP+fZsw/ZerEMsW/pyzsRbElpsL/DBVW7q3ExxwusdNXI3lXpuhEZkzs8p5Eg==
dependencies:
color-name "^1.0.0"
simple-swizzle "^0.2.2"
color@^3.1.3:
version "3.2.1"
resolved "https://registry.npmjs.org/color/-/color-3.2.1.tgz"
integrity sha512-aBl7dZI9ENN6fUGC7mWpMTPNHmWUSNan9tuWN6ahh5ZLNk9baLJOnSMlrQkHcrfFgz2/RigjUVAjdx36VcemKA==
dependencies:
color-convert "^1.9.3"
color-string "^1.6.0"
colorspace@1.1.x:
version "1.1.4"
resolved "https://registry.npmjs.org/colorspace/-/colorspace-1.1.4.tgz"
integrity sha512-BgvKJiuVu1igBUF2kEjRCZXol6wiiGbY5ipL/oVPwm0BL9sIpMIzM8IK7vwuxIIzOXMV3Ey5w+vxhm0rR/TN8w==
dependencies:
color "^3.1.3"
text-hex "1.0.x"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
combined-stream@^1.0.6, combined-stream@^1.0.8, combined-stream@~1.0.6:
version "1.0.8"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/combined-stream/-/combined-stream-1.0.8.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-FQN4MRfuJeHf7cBbBMJFXhKSDq+2kAArBlmRBvcvFE5BB1HZKXtSFASDhdlz9zOYwxh8lDdnvmMOe/+5cdoEdg==
dependencies:
delayed-stream "~1.0.0"
commander@^2.12.1, commander@^2.19.0:
version "2.20.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/commander/-/commander-2.20.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ==
commandpost@^1.0.0:
version "1.4.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/commandpost/-/commandpost-1.4.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-aE2Y4MTFJ870NuB/+2z1cXBhSBBzRydVVjzhFC4gtenEhpnj15yu0qptWGJsO9YGrcPZ3ezX8AWb1VA391MKpQ==
concat-map@0.0.1:
version "0.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-/Srv4dswyQNBfohGpz9o6Yb3Gz3SrUDqBH5rTuhGR7ahtlbYKnVxw2bCFMRljaA7EXHaXZ8wsHdodFvbkhKmqg==
config@^3.3.8:
version "3.3.8"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/config/-/config-3.3.8.tgz"
integrity sha512-rFzF6VESOdp7wAXFlB9IOZI4ouL05g3A03v2eRcTHj2JBQaTNJ40zhAUl5wRbWHqLZ+uqp/7OE0BWWtAVgrong==
dependencies:
json5 "^2.2.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
content-disposition@0.5.4:
version "0.5.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.4.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-FveZTNuGw04cxlAiWbzi6zTAL/lhehaWbTtgluJh4/E95DqMwTmha3KZN1aAWA8cFIhHzMZUvLevkw5Rqk+tSQ==
dependencies:
safe-buffer "5.2.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
content-type@~1.0.4:
version "1.0.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/content-type/-/content-type-1.0.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-hIP3EEPs8tB9AT1L+NUqtwOAps4mk2Zob89MWXMHjHWg9milF/j4osnnQLXBCBFBk/tvIG/tUc9mOUJiPBhPXA==
cookie-signature@1.0.6:
version "1.0.6"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/cookie-signature/-/cookie-signature-1.0.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-QADzlaHc8icV8I7vbaJXJwod9HWYp8uCqf1xa4OfNu1T7JVxQIrUgOWtHdNDtPiywmFbiS12VjotIXLrKM3orQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
cookie@0.5.0:
version "0.5.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/cookie/-/cookie-0.5.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-YZ3GUyn/o8gfKJlnlX7g7xq4gyO6OSuhGPKaaGssGB2qgDUS0gPgtTvoyZLTt9Ab6dC4hfc9dV5arkvc/OCmrw==
2023-04-03 20:03:02 +00:00
cookie@^0.4.1:
version "0.4.2"
resolved "https://registry.npmjs.org/cookie/-/cookie-0.4.2.tgz"
integrity sha512-aSWTXFzaKWkvHO1Ny/s+ePFpvKsPnjc551iI41v3ny/ow6tBG5Vd+FuqGNhh1LxOmVzOlGUriIlOaokOvhaStA==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
core-util-is@1.0.2:
version "1.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/core-util-is/-/core-util-is-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-3lqz5YjWTYnW6dlDa5TLaTCcShfar1e40rmcJVwCBJC6mWlFuj0eCHIElmG1g5kyuJ/GD+8Wn4FFCcz4gJPfaQ==
cross-spawn@^7.0.2:
version "7.0.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-iRDPJKUPVEND7dHPO8rkbOnPpyDygcDFtWjpeWNCgy8WP2rXcxXL8TskReQl6OrB2G7+UJrags1q15Fudc7G6w==
dependencies:
path-key "^3.1.0"
shebang-command "^2.0.0"
which "^2.0.1"
crypto-js@^4.1.1:
version "4.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/crypto-js/-/crypto-js-4.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-o2JlM7ydqd3Qk9CA0L4NL6mTzU2sdx96a+oOfPu8Mkl/PK51vSyoi8/rQ8NknZtk44vq15lmhAj9CIAGwgeWKw==
cssom@^0.4.4:
version "0.4.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/cssom/-/cssom-0.4.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-p3pvU7r1MyyqbTk+WbNJIgJjG2VmTIaB10rI93LzVPrmDJKkzKYMtxxyAvQXR/NS6otuzveI7+7BBq3SjBS2mw==
cssom@~0.3.6:
version "0.3.8"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/cssom/-/cssom-0.3.8.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-b0tGHbfegbhPJpxpiBPU2sCkigAqtM9O121le6bbOlgyV+NyGyCmVfJ6QW9eRjz8CpNfWEOYBIMIGRYkLwsIYg==
cssstyle@^2.3.0:
version "2.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/cssstyle/-/cssstyle-2.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-AZL67abkUzIuvcHqk7c09cezpGNcxUxU4Ioi/05xHk4DQeTkWmGYftIE6ctU6AEt+Gn4n1lDStOtj7FKycP71A==
dependencies:
cssom "~0.3.6"
dashdash@^1.12.0:
version "1.14.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/dashdash/-/dashdash-1.14.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-jRFi8UDGo6j+odZiEpjazZaWqEal3w/basFjQHQEwVtZJGDpxbH1MeYluwCS8Xq5wmLJooDlMgvVarmWfGM44g==
dependencies:
assert-plus "^1.0.0"
data-urls@^2.0.0:
version "2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/data-urls/-/data-urls-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-X5eWTSXO/BJmpdIKCRuKUgSCgAN0OwliVK3yPKbwIWU1Tdw5BRajxlzMidvh+gwko9AfQ9zIj52pzF91Q3YAvQ==
dependencies:
abab "^2.0.3"
whatwg-mimetype "^2.3.0"
whatwg-url "^8.0.0"
debug@2.6.9:
version "2.6.9"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==
dependencies:
ms "2.0.0"
debug@4, debug@4.3.3, debug@^4.0.1, debug@^4.1.1:
version "4.3.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/debug/-/debug-4.3.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-/zxw5+vh1Tfv+4Qn7a5nsbcJKPaSvCDhojn6FEl9vupwK2VCSDtEiEtqr8DFtzYFOdz63LBkxec7DYuc2jon6Q==
dependencies:
ms "2.1.2"
decamelize@^4.0.0:
version "4.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/decamelize/-/decamelize-4.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-9iE1PgSik9HeIIw2JO94IidnE3eBoQrFJ3w7sFuzSX4DpmZ3v5sZpUiV5Swcf6mQEF+Y0ru8Neo+p+nyh2J+hQ==
decimal.js@^10.2.1:
version "10.3.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/decimal.js/-/decimal.js-10.3.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-V0pfhfr8suzyPGOx3nmq4aHqabehUZn6Ch9kyFpV79TGDTWFmHqUqXdabR7QHqxzrYolF4+tVmJhUG4OURg5dQ==
deep-is@^0.1.3, deep-is@~0.1.3:
version "0.1.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/deep-is/-/deep-is-0.1.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-oIPzksmTg4/MriiaYGO+okXDT7ztn/w3Eptv/+gSIdMdKsJo0u4CfYNFJPy+4SKMuCqGw2wxnA+URMg3t8a/bQ==
deepmerge@^4.2.2:
version "4.2.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/deepmerge/-/deepmerge-4.2.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-FJ3UgI4gIl+PHZm53knsuSFpE+nESMr7M4v9QcgB7S63Kj/6WqMiFQJpBBYz1Pt+66bZpP3Q7Lye0Oo9MPKEdg==
delayed-stream@~1.0.0:
version "1.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/delayed-stream/-/delayed-stream-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ZySD7Nf91aLB0RxL4KGrKHBXl7Eds1DAmEdcoVawXnLD7SDhpNgtuII2aAkg7a7QS41jxPSZ17p4VdGnMHk3MQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
depd@2.0.0, depd@~2.0.0:
version "2.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/depd/-/depd-2.0.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-g7nH6P6dyDioJogAAGprGpCtVImJhpPk/roCzdb3fIh61/s/nPsfR6onyMwkCAR/OlC3yBC0lESvUoQEAssIrw==
destroy@1.2.0:
version "1.2.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/destroy/-/destroy-1.2.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-2sJGJTaXIIaR1w4iJSNoN0hnMY7Gpc/n8D4qSCJw8QqFWXf7cuAgnEHxBpweaVcPevC2l3KpjYCx3NypQQgaJg==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
diff-sequences@^27.0.6:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "27.5.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/diff-sequences/-/diff-sequences-27.5.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-k1gCAXAsNgLwEL+Y8Wvl+M6oEFj5bgazfZULpS5CneoPPXRaCCW7dm+q21Ky2VEE5X+VeRDBVg1Pcvvsr4TtNQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
diff@5.0.0:
version "5.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/diff/-/diff-5.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-/VTCrvm5Z0JGty/BWHljh+BAiw3IK+2j87NGMu8Nwc/f48WoDAC395uomO9ZD117ZOBaHmkX1oyLvkVM/aIT3w==
diff@^3.1.0:
version "3.5.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/diff/-/diff-3.5.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-A46qtFgd+g7pDZinpnwiRJtxbC1hpgf0uzP3iG89scHk0AUC7A1TGxf5OiiOUv/JMZR8GOt8hL900hV0bOy5xA==
diff@^4.0.1:
version "4.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/diff/-/diff-4.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-58lmxKSA4BNyLz+HHMUzlOEpg09FV+ev6ZMe3vJihgdxzgcwZ8VoEEPmALCZG9LmqfVoNMMKpttIYTVG6uDY7A==
discontinuous-range@1.0.0:
version "1.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/discontinuous-range/-/discontinuous-range-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-c68LpLbO+7kP/b1Hr1qs8/BJ09F5khZGTxqxZuhzxpmwJKOgRFHJWIb9/KmqnqHhLdO55aOxFH/EGBvUQbL/RQ==
doctrine@^3.0.0:
version "3.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/doctrine/-/doctrine-3.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-yS+Q5i3hBf7GBkd4KG8a7eBNNWNGLTaEwwYWUijIYM7zrlYDM0BFXHjjPWlWZ1Rg7UaddZeIDmi9jF3HmqiQ2w==
dependencies:
esutils "^2.0.2"
dom-serializer@^1.0.1:
version "1.3.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/dom-serializer/-/dom-serializer-1.3.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-5c54Bk5Dw4qAxNOI1pFEizPSjVsx5+bpJKmL2kPn8JhBUq2q09tTCa3mjijun2NfK78NMouDYNMBkOrPZiS+ig==
dependencies:
domelementtype "^2.0.1"
domhandler "^4.2.0"
entities "^2.0.0"
domelementtype@^2.0.1, domelementtype@^2.2.0:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "2.3.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/domelementtype/-/domelementtype-2.3.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-OLETBj6w0OsagBwdXnPdN0cnMfF9opN69co+7ZrbfPGrdpPVNBUj02spi6B1N7wChLQiPn4CSH/zJvXw56gmHw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
domexception@^2.0.1:
version "2.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/domexception/-/domexception-2.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-yxJ2mFy/sibVQlu5qHjOkf9J3K6zgmCxgJ94u2EdvDOV09H+32LtRswEcUsmUWN72pVLOEnTSRaIVVzVQgS0dg==
dependencies:
webidl-conversions "^5.0.0"
domhandler@^4.0.0, domhandler@^4.2.0:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "4.3.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/domhandler/-/domhandler-4.3.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-GrwoxYN+uWlzO8uhUXRl0P+kHE4GtVPfYzVLcUxPL7KNdHKj66vvlhiweIHqYYXWlw+T8iLMp42Lm67ghw4WMQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
domelementtype "^2.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
domutils@^2.5.2:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "2.8.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/domutils/-/domutils-2.8.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-w96Cjofp72M5IIhpjgobBimYEfoPjx1Vx0BSX9P30WBdZW2WIKU0T1Bd0kz2eNZ9ikjKgHbEyKx8BB6H1L3h3A==
dependencies:
dom-serializer "^1.0.1"
domelementtype "^2.2.0"
domhandler "^4.2.0"
ecc-jsbn@~0.1.1:
version "0.1.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/ecc-jsbn/-/ecc-jsbn-0.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-eh9O+hwRHNbG4BLTjEl3nw044CkGm5X6LoaCf7LPp7UU8Qrt47JYNi6nPX8xjW97TKGKm1ouctg0QSpZe9qrnw==
dependencies:
jsbn "~0.1.0"
safer-buffer "^2.1.0"
editorconfig@^0.15.0:
version "0.15.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/editorconfig/-/editorconfig-0.15.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-M9wIMFx96vq0R4F+gRpY3o2exzb8hEj/n9S8unZtHSvYjibBp/iMufSzvmOcV/laG0ZtuTVGtiJggPOSW2r93g==
dependencies:
commander "^2.19.0"
lru-cache "^4.1.5"
semver "^5.6.0"
sigmund "^1.0.1"
ee-first@1.1.1:
version "1.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ee-first/-/ee-first-1.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-WMwm9LhRUo+WUaRN+vRuETqG89IgZphVSNkdFgeb6sS/E4OrDIN7t48CAewSHXc6C8lefD8KKfr5vY61brQlow==
emoji-regex@^8.0.0:
version "8.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
enabled@2.0.x:
version "2.0.0"
resolved "https://registry.npmjs.org/enabled/-/enabled-2.0.0.tgz"
integrity sha512-AKrN98kuwOzMIdAizXGI86UFBoo26CL21UM763y1h/GMSJ4/OHU9k2YlsmBpyScFo/wbLzWQJBMCW4+IO3/+OQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
encodeurl@~1.0.2:
version "1.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/encodeurl/-/encodeurl-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-TPJXq8JqFaVYm2CWmPvnP2Iyo4ZSM7/QKcSmuMLDObfpH5fi7RUGmd/rTDf+rut/saiDiQEeVTNgAmJEdAOx0w==
enquirer@^2.3.5:
version "2.3.6"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/enquirer/-/enquirer-2.3.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-yjNnPr315/FjS4zIsUxYguYUPP2e1NK4d7E7ZOLiyYCcbFBiTMyID+2wvm2w6+pZ/odMA7cRkjhsPbltwBOrLg==
dependencies:
ansi-colors "^4.1.1"
entities@^2.0.0:
version "2.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/entities/-/entities-2.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-p92if5Nz619I0w+akJrLZH0MX0Pb5DX39XOwQTtXSdQQOaYH03S1uIQp4mhOZtAXrxq4ViO67YTiLBo2638o9A==
escalade@^3.1.1:
version "3.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/escalade/-/escalade-3.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-k0er2gUkLf8O0zKJiAhmkTnJlTvINGv7ygDNPbeIsX/TJjGJZHuh9B2UxbsaEkmlEo9MfhrSzmhIlhRlI2GXnw==
escape-html@~1.0.3:
version "1.0.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/escape-html/-/escape-html-1.0.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-NiSupZ4OeuGwr68lGIeym/ksIZMJodUGOSCZ/FSnTxcrekbvqrgdUxlJOMpijaKZVjAJrWrGs/6Jy8OMuyj9ow==
escape-string-regexp@4.0.0, escape-string-regexp@^4.0.0:
version "4.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-4.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-TtpcNJ3XAzx3Gq8sWRzJaVajRs0uVxA2YAkdb1jm2YkPz4G6egUFAyA3n5vtEIZefPk5Wa4UXbKuS5fKkJWdgA==
escape-string-regexp@^1.0.5:
version "1.0.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg==
escape-string-regexp@^2.0.0:
version "2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-UpzcLCXolUWcNu5HtVMHYdXJjArjsF9C0aNnquZYY4uW/Vu0miy5YoWvbV345HauVvcAUnpRuhMMcqTcGOY2+w==
escodegen@^2.0.0:
version "2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/escodegen/-/escodegen-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-mmHKys/C8BFUGI+MAWNcSYoORYLMdPzjrknd2Vc+bUsjN5bXcr8EhrNB+UTqfL1y3I9c4fw2ihgtMPQLBRiQxw==
dependencies:
esprima "^4.0.1"
estraverse "^5.2.0"
esutils "^2.0.2"
optionator "^0.8.1"
optionalDependencies:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
source-map "~0.6.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
eslint-scope@^5.1.1:
version "5.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/eslint-scope/-/eslint-scope-5.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-2NxwbF/hZ0KpepYN0cNbo+FN6XoK7GaHlQhgx/hIZl6Va0bF45RQOOwhLIy8lQDbuCiadSLCBnH2CFYquit5bw==
dependencies:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
esrecurse "^4.3.0"
estraverse "^4.1.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
eslint-utils@^2.1.0:
version "2.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/eslint-utils/-/eslint-utils-2.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-w94dQYoauyvlDc43XnGB8lU3Zt713vNChgt4EWwhXAP2XkBvndfxF0AgIqKOOasjPIPzj9JqgwkwbCYD0/V3Zg==
dependencies:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
eslint-visitor-keys "^1.1.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
eslint-visitor-keys@^1.1.0, eslint-visitor-keys@^1.3.0:
version "1.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-1.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-6J72N8UNa462wa/KFODt/PJ3IU60SDpC3QXC1Hjc1BXXpfL2C9R5+AU7jhe0F6GREqVMh4Juu+NY7xn+6dipUQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
eslint-visitor-keys@^2.0.0:
version "2.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-2.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-0rSmRBzXgDzIsD6mGdJgevzgezI534Cer5L/vyMX0kHzT/jiB43jRhd9YUlMGYLQy2zprNmoT8qasCGtY+QaKw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
eslint@^7.32:
version "7.32.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/eslint/-/eslint-7.32.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-VHZ8gX+EDfz+97jGcgyGCyRia/dPOd6Xh9yPv8Bl1+SoaIwD+a/vlrOmGRUyOYu7MwUhc7CxqeaDZU13S4+EpA==
dependencies:
"@babel/code-frame" "7.12.11"
"@eslint/eslintrc" "^0.4.3"
"@humanwhocodes/config-array" "^0.5.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
ajv "^6.10.0"
chalk "^4.0.0"
cross-spawn "^7.0.2"
debug "^4.0.1"
doctrine "^3.0.0"
enquirer "^2.3.5"
escape-string-regexp "^4.0.0"
eslint-scope "^5.1.1"
eslint-utils "^2.1.0"
eslint-visitor-keys "^2.0.0"
espree "^7.3.1"
esquery "^1.4.0"
esutils "^2.0.2"
fast-deep-equal "^3.1.3"
file-entry-cache "^6.0.1"
functional-red-black-tree "^1.0.1"
glob-parent "^5.1.2"
globals "^13.6.0"
ignore "^4.0.6"
import-fresh "^3.0.0"
imurmurhash "^0.1.4"
is-glob "^4.0.0"
js-yaml "^3.13.1"
json-stable-stringify-without-jsonify "^1.0.1"
levn "^0.4.1"
lodash.merge "^4.6.2"
minimatch "^3.0.4"
natural-compare "^1.4.0"
optionator "^0.9.1"
progress "^2.0.0"
regexpp "^3.1.0"
semver "^7.2.1"
strip-ansi "^6.0.0"
strip-json-comments "^3.1.0"
table "^6.0.9"
text-table "^0.2.0"
v8-compile-cache "^2.0.3"
espree@^7.3.0, espree@^7.3.1:
version "7.3.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/espree/-/espree-7.3.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-v3JCNCE64umkFpmkFGqzVKsOT0tN1Zr+ueqLZfpV1Ob8e+CEgPWa+OxCoGH3tnhimMKIaBm4m/vaRpJ/krRz2g==
dependencies:
acorn "^7.4.0"
acorn-jsx "^5.3.1"
eslint-visitor-keys "^1.3.0"
esprima@^4.0.0, esprima@^4.0.1:
version "4.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/esprima/-/esprima-4.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==
esquery@^1.4.0:
version "1.4.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/esquery/-/esquery-1.4.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-cCDispWt5vHHtwMY2YrAQ4ibFkAL8RbH5YGBnZBc90MolvvfkkQcJro/aZiAQUlQ3qgrYS6D6v8Gc5G5CQsc9w==
dependencies:
estraverse "^5.1.0"
esrecurse@^4.3.0:
version "4.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/esrecurse/-/esrecurse-4.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-KmfKL3b6G+RXvP8N1vr3Tq1kL/oCFgn2NYXEtqP8/L3pKapUA4G8cFVaoF3SU323CD4XypR/ffioHmkti6/Tag==
dependencies:
estraverse "^5.2.0"
estraverse@^4.1.1:
version "4.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/estraverse/-/estraverse-4.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-39nnKffWz8xN1BU/2c79n9nB9HDzo0niYUqx6xyqUnyoAnQyyWpOTdZEeiCch8BBu515t4wp9ZmgVfVhn9EBpw==
estraverse@^5.1.0, estraverse@^5.2.0:
version "5.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/estraverse/-/estraverse-5.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-BxbNGGNm0RyRYvUdHpIwv9IWzeM9XClbOxwoATuFdOE7ZE6wHL+HQ5T8hoPM+zHvmKzzsEqhgy0GrQ5X13afiQ==
esutils@^2.0.2:
version "2.0.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/esutils/-/esutils-2.0.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-kVscqXk4OCp68SZ0dkgEKVi6/8ij300KBWTJq32P/dYeWTSwK41WyTxalN1eRmA5Z9UU/LX9D7FWSmV9SAYx6g==
etag@~1.8.1:
version "1.8.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/etag/-/etag-1.8.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-aIL5Fx7mawVa300al2BnEE4iNvo1qETxLrPI/o05L7z6go7fCw1J6EQmbK4FmJ2AS7kgVF/KEZWufBfdClMcPg==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
eventemitter3@^4.0.4:
version "4.0.7"
resolved "https://registry.npmjs.org/eventemitter3/-/eventemitter3-4.0.7.tgz"
integrity sha512-8guHBZCwKnFhYdHr2ysuRWErTwhoN2X8XELRlrRwpmfeY2jjuUN4taQMsULKUVo1K4DvZl+0pgfyoysHxvmvEw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
expect@^27.0.6:
version "27.2.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/expect/-/expect-27.2.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-gOtuonQ8TCnbNNCSw2fhVzRf8EFYDII4nB5NmG4IEV0rbUnW1I5zXvoTntU4iicB/Uh0oZr20NGlOLdJiwsOZA==
dependencies:
"@jest/types" "^27.2.4"
ansi-styles "^5.0.0"
jest-get-type "^27.0.6"
jest-matcher-utils "^27.2.4"
jest-message-util "^27.2.4"
jest-regex-util "^27.0.6"
express-rate-limit@^6.7.0:
version "6.8.1"
resolved "https://registry.yarnpkg.com/express-rate-limit/-/express-rate-limit-6.8.1.tgz#f614bc3a7040fe6f75dc3198536f4cc13526f989"
integrity sha512-xJyudsE60CsDShK74Ni1MxsldYaIoivmG3ieK2tAckMsYCBewEuGalss6p/jHmFFnqM9xd5ojE0W2VlanxcOKg==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
2023-04-03 20:03:02 +00:00
express@^4.17, express@^4.17.1, express@^4.18.1:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "4.18.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/express/-/express-4.18.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-zZBcOX9TfehHQhtupq57OF8lFZ3UZi08Y97dwFCkD8p9d/d2Y3M+ykKcwaMDEL+4qyUolgBDX6AblpR3fL212Q==
dependencies:
accepts "~1.3.8"
array-flatten "1.1.1"
body-parser "1.20.0"
content-disposition "0.5.4"
content-type "~1.0.4"
cookie "0.5.0"
cookie-signature "1.0.6"
debug "2.6.9"
depd "2.0.0"
encodeurl "~1.0.2"
escape-html "~1.0.3"
etag "~1.8.1"
finalhandler "1.2.0"
fresh "0.5.2"
http-errors "2.0.0"
merge-descriptors "1.0.1"
methods "~1.1.2"
on-finished "2.4.1"
parseurl "~1.3.3"
path-to-regexp "0.1.7"
proxy-addr "~2.0.7"
qs "6.10.3"
range-parser "~1.2.1"
safe-buffer "5.2.1"
send "0.18.0"
serve-static "1.15.0"
setprototypeof "1.2.0"
statuses "2.0.1"
type-is "~1.6.18"
utils-merge "1.0.1"
vary "~1.1.2"
extend@^3.0.2, extend@~3.0.2:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "3.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/extend/-/extend-3.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==
2023-04-03 20:03:02 +00:00
extsprintf@1.3.0, extsprintf@^1.2.0:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.3.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/extsprintf/-/extsprintf-1.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-11Ndz7Nv+mvAC1j0ktTa7fAb0vLyGGX+rMHNBYQviQDGU0Hw7lhctJANqbPhu9nV9/izT/IntTgZ7Im/9LJs9g==
fast-deep-equal@^3.1.1, fast-deep-equal@^3.1.3:
version "3.1.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==
fast-json-stable-stringify@^2.0.0:
version "2.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==
fast-levenshtein@^2.0.6, fast-levenshtein@~2.0.6:
version "2.0.6"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/fast-levenshtein/-/fast-levenshtein-2.0.6.tgz"
integrity "sha1-PYpcZog6FqMMqGQ+hR8Zuqd5eRc= sha512-DCXu6Ifhqcks7TZKY3Hxp3y6qphY5SJZmrWMDrKcERSOXWQdMhU9Ig/PYrzyw/ul9jOIyh0N4M0tbC5hodg8dw=="
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
fecha@^4.2.0:
version "4.2.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/fecha/-/fecha-4.2.3.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-OP2IUU6HeYKJi3i0z4A19kHMQoLVs4Hc+DPqqxI2h/DPZHTm/vjsfC6P0b4jCMy14XizLBqvndQ+UilD7707Jw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
file-entry-cache@^6.0.1:
version "6.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/file-entry-cache/-/file-entry-cache-6.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-7Gps/XWymbLk2QLYK4NzpMOrYjMhdIxXuIvy2QBsLE6ljuodKvdkWs/cpyJJ3CVIVpH0Oi1Hvg1ovbMzLdFBBg==
dependencies:
flat-cache "^3.0.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
file-stream-rotator@^0.6.1:
version "0.6.1"
resolved "https://registry.npmjs.org/file-stream-rotator/-/file-stream-rotator-0.6.1.tgz"
integrity sha512-u+dBid4PvZw17PmDeRcNOtCP9CCK/9lRN2w+r1xIS7yOL9JFrIBKTvrYsxT4P0pGtThYTn++QS5ChHaUov3+zQ==
dependencies:
moment "^2.29.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
fill-range@^7.0.1:
version "7.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==
dependencies:
to-regex-range "^5.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
finalhandler@1.2.0:
version "1.2.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/finalhandler/-/finalhandler-1.2.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-5uXcUVftlQMFnWC9qu/svkWv3GTd2PfUhK/3PLkYNAe7FbqJMt3515HaxE6eRL74GdsriiwujiawdaB1BpEISg==
dependencies:
debug "2.6.9"
encodeurl "~1.0.2"
escape-html "~1.0.3"
on-finished "2.4.1"
parseurl "~1.3.3"
statuses "2.0.1"
unpipe "~1.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
find-up@5.0.0:
version "5.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/find-up/-/find-up-5.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-78/PXT1wlLLDgTzDs7sjq9hzz0vXD+zn+7wypEe4fXQxCmdmqfGsEPQxmiCSQI3ajFV91bVSsvNtrJRiW6nGng==
dependencies:
locate-path "^6.0.0"
path-exists "^4.0.0"
flat-cache@^3.0.4:
version "3.0.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/flat-cache/-/flat-cache-3.0.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-dm9s5Pw7Jc0GvMYbshN6zchCA9RgQlzzEZX3vylR9IqFfS8XciblUXOKfW6SiuJ0e13eDYZoZV5wdrev7P3Nwg==
dependencies:
flatted "^3.1.0"
rimraf "^3.0.2"
flat@^5.0.2:
version "5.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/flat/-/flat-5.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-b6suED+5/3rTpUBdG1gupIl8MPFCAMA0QXwmljLhvCUKcUvdE4gWky9zpuGCcXHOsz4J9wPGNWq6OKpmIzz3hQ==
flatted@^3.1.0:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "3.2.7"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/flatted/-/flatted-3.2.7.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-5nqDSxl8nn5BSNxyR3n4I6eDmbolI6WT+QqR547RwxQapgjQBmtktdP+HTBb/a/zLsbzERTONyUB5pefh5TtjQ==
fn.name@1.x.x:
version "1.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/fn.name/-/fn.name-1.1.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-GRnmB5gPyJpAhTQdSZTSp9uaPSvl09KoYcMQtsB9rQoOmzs9dH6ffeccH+Z+cv6P68Hu5bC6JjRh4Ah/mHSNRw==
follow-redirects@^1.14.9:
version "1.15.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-yLAMQs+k0b2m7cVxpS1VKJVvoz7SS9Td1zss3XRwXj+ZDH00RJgnuLx7E44wx02kQLrdM3aOOy+FpzS7+8OizA==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
forever-agent@~0.6.1:
version "0.6.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/forever-agent/-/forever-agent-0.6.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-j0KLYPhm6zeac4lz3oJ3o65qvgQCcPubiyotZrXqEaG4hNagNYO8qdlUrX5vwqv9ohqeT/Z3j6+yW067yWWdUw==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
form-data@^2.5.0:
version "2.5.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/form-data/-/form-data-2.5.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-m21N3WOmEEURgk6B9GLOE4RuWOFf28Lhh9qGYeNlGq4VDXUlJy2th2slBNU8Gp8EzloYZOibZJ7t5ecIrFSjVA==
dependencies:
asynckit "^0.4.0"
combined-stream "^1.0.6"
mime-types "^2.1.12"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
form-data@^3.0.0:
version "3.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/form-data/-/form-data-3.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-RHkBKtLWUVwd7SqRIvCZMEvAMoGUp0XU+seQiZejj0COz3RI3hWP4sCv3gZWWLjJTd7rGwcsF5eKZGii0r/hbg==
dependencies:
asynckit "^0.4.0"
combined-stream "^1.0.8"
mime-types "^2.1.12"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
form-data@^4.0.0:
version "4.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/form-data/-/form-data-4.0.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-ETEklSGi5t0QMZuiXoA/Q6vcnxcLQP5vdugSpuAyi6SVGi2clPPp+xgEhuMaHC+zGgn31Kd235W35f7Hykkaww==
dependencies:
asynckit "^0.4.0"
combined-stream "^1.0.8"
mime-types "^2.1.12"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
form-data@~2.3.2:
version "2.3.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/form-data/-/form-data-2.3.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-1lLKB2Mu3aGP1Q/2eCOx0fNbRMe7XdwktwOruhfqqd0rIJWwN4Dh+E3hrPSlDCXnSR7UtZ1N38rVXm+6+MEhJQ==
dependencies:
asynckit "^0.4.0"
combined-stream "^1.0.6"
mime-types "^2.1.12"
forwarded@0.2.0:
version "0.2.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/forwarded/-/forwarded-0.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow==
fresh@0.5.2:
version "0.5.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/fresh/-/fresh-0.5.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==
fs.realpath@^1.0.0:
version "1.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==
fsevents@~2.3.2:
version "2.3.2"
resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.3.2.tgz#8a526f78b8fdf4623b709e0b975c52c24c02fd1a"
integrity sha512-xiqMQR4xAeHTuB9uWm+fFRcIOgKBMiOBP+eXiyT7jsgVCq1bkVygt00oASowB7EdtpOHaaPgKt812P9ab+DDKA==
function-bind@^1.1.1:
version "1.1.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/function-bind/-/function-bind-1.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-yIovAzMX49sF8Yl58fSCWJ5svSLuaibPxXQJFLmBObTuCr0Mf1KiPopGM9NiFjiYBCbfaa2Fh6breQ6ANVTI0A==
functional-red-black-tree@^1.0.1:
version "1.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/functional-red-black-tree/-/functional-red-black-tree-1.0.1.tgz"
integrity "sha1-GwqzvVU7Kg1jmdKcDj6gslIHgyc= sha512-dsKNQNdj6xA3T+QlADDA7mOSlX0qiMINjn0cgr+eGHGsbSHzTabcIogz2+p/iqP1Xs6EP/sS2SbqH+brGTbq0g=="
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
generate-function@^2.0.0:
version "2.3.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/generate-function/-/generate-function-2.3.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-eeB5GfMNeevm/GRYq20ShmsaGcmI81kIX2K9XQx5miC8KdHaC6Jm0qQ8ZNeGOi7wYB8OsdxKs+Y2oVuTFuVwKQ==
dependencies:
is-property "^1.0.2"
generate-object-property@^1.1.0:
version "1.2.0"
resolved "https://registry.npmjs.org/generate-object-property/-/generate-object-property-1.2.0.tgz"
integrity sha512-TuOwZWgJ2VAMEGJvAyPWvpqxSANF0LDpmyHauMjFYzaACvn+QTT/AZomvPCzVBV7yDN3OmwHQ5OvHaeLKre3JQ==
dependencies:
is-property "^1.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
get-caller-file@^2.0.5:
version "2.0.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/get-caller-file/-/get-caller-file-2.0.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
get-intrinsic@^1.0.2:
version "1.1.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.1.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-Jfm3OyCxHh9DJyc28qGk+JmfkpO41A4XkneDSujN9MDXrm4oDKdHvndhZ2dN94+ERNfkYJWDclW6k2L/ZGHjXA==
dependencies:
function-bind "^1.1.1"
has "^1.0.3"
has-symbols "^1.0.3"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
getpass@^0.1.1:
version "0.1.7"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/getpass/-/getpass-0.1.7.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-0fzj9JxOLfJ+XGLhR8ze3unN0KZCgZwiSSDz168VERjK8Wl8kVSdcu2kspd4s4wtAa1y/qrVRiAA0WclVsu0ng==
dependencies:
assert-plus "^1.0.0"
glob-parent@^5.1.2, glob-parent@~5.1.2:
version "5.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==
dependencies:
is-glob "^4.0.1"
glob-to-regexp@^0.4.1:
version "0.4.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/glob-to-regexp/-/glob-to-regexp-0.4.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-lkX1HJXwyMcprw/5YUZc2s7DrpAiHB21/V+E1rHUrVNokkvB6bqMzT0VfV6/86ZNabt1k14YOIaT7nDvOX3Iiw==
2023-04-03 20:03:02 +00:00
glob@7.2.0, glob@^7.1.1, glob@^7.1.3:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "7.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/glob/-/glob-7.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-lmLf6gtyrPq8tTjSmrO94wBeQbFR3HbLHbuyD69wuyQkImp2hWqMGB47OX65FBkPffO641IP9jWa1z4ivqG26Q==
dependencies:
fs.realpath "^1.0.0"
inflight "^1.0.4"
inherits "2"
minimatch "^3.0.4"
once "^1.3.0"
path-is-absolute "^1.0.0"
globals@^13.6.0, globals@^13.9.0:
version "13.11.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/globals/-/globals-13.11.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-08/xrJ7wQjK9kkkRoI3OFUBbLx4f+6x3SGwcPvQ0QH6goFDrOU2oyAWrmh3dJezu65buo+HBMzAMQy6rovVC3g==
dependencies:
type-fest "^0.20.2"
2023-04-03 20:03:02 +00:00
graceful-fs@^4.1.3, graceful-fs@^4.2.4:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "4.2.8"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.8.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-qkIilPUYcNhJpd33n0GBXTB1MMPp14TxEsEs0pTrsSVucApsYzW5V+Q8Qxhik6KU3evy+qkAAowTByymK0avdg==
growl@1.10.5:
version "1.10.5"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/growl/-/growl-1.10.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-qBr4OuELkhPenW6goKVXiv47US3clb3/IbuWF9KNKEijAy9oeHxU9IgzjvJhHkUzhaj7rOUD7+YGWqUjLp5oSA==
har-schema@^2.0.0:
version "2.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/har-schema/-/har-schema-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Oqluz6zhGX8cyRaTQlFMPw80bSJVG2x/cFb8ZPhUILGgHka9SsokCCOQgpveePerqidZOrT14ipqfJb7ILcW5Q==
har-validator@~5.1.3:
version "5.1.5"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/har-validator/-/har-validator-5.1.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-nmT2T0lljbxdQZfspsno9hgrG3Uir6Ks5afism62poxqBM6sDnMEuPmzTq8XN0OEwqKLLdh1jQI3qyE66Nzb3w==
dependencies:
ajv "^6.12.3"
har-schema "^2.0.0"
has-flag@^3.0.0:
version "3.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/has-flag/-/has-flag-3.0.0.tgz"
integrity "sha1-tdRU3CGZriJWmfNGfloH87lVuv0= sha512-sKJf1+ceQBr4SMkvQnBDNDtf4TXpVhVGateu0t918bl30FnbE2m4vNLX+VWe/dpjlb+HugGYzW7uQXH98HPEYw=="
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
has-flag@^4.0.0:
version "4.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
has-symbols@^1.0.3:
version "1.0.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/has-symbols/-/has-symbols-1.0.3.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-l3LCuF6MgDNwTDKkdYGEihYjt5pRPbEg46rtlmnSPlUbgmB8LOIrKJbYYFBSbnPaJexMKtiPO8hmeRjRz2Td+A==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
has@^1.0.3:
version "1.0.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/has/-/has-1.0.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-f2dvO0VU6Oej7RkWJGrehjbzMAjFp5/VKPp5tTpWIV4JHHZK1/BxbFRtf/siA2SWTe09caDmVtYYzWEIbBS4zw==
dependencies:
function-bind "^1.1.1"
hash.js@^1.1.7:
version "1.1.7"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/hash.js/-/hash.js-1.1.7.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-taOaskGt4z4SOANNseOviYDvjEJinIkRgmp7LbKP2YTTmVxWBl87s/uzK9r+44BclBSp2X7K1hqeNfz9JbBeXA==
dependencies:
inherits "^2.0.3"
minimalistic-assert "^1.0.1"
he@1.2.0, he@^1.2.0:
version "1.2.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/he/-/he-1.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-F/1DnUGPopORZi0ni+CvrCgHQ5FyEAHRLSApuYWMmrbSwoN2Mn/7k+Gl38gJnR7yyDZk6WLXwiGod1JOWNDKGw==
html-encoding-sniffer@^2.0.1:
version "2.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/html-encoding-sniffer/-/html-encoding-sniffer-2.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-D5JbOMBIR/TVZkubHT+OyT2705QvogUW4IBn6nHd756OwieSF9aDYFj4dv6HHEVGYbHaLETa3WggZYWWMyy3ZQ==
dependencies:
whatwg-encoding "^1.0.5"
2023-04-03 20:03:02 +00:00
html-to-text@^8.0.0, html-to-text@^8.2.0:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "8.2.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/html-to-text/-/html-to-text-8.2.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-CLXExYn1b++Lgri+ZyVvbUEFwzkLZppjjZOwB7X1qv2jIi8MrMEvxWX5KQ7zATAzTvcqgmtO00M2kCRMtEdOKQ==
dependencies:
"@selderee/plugin-htmlparser2" "^0.6.0"
deepmerge "^4.2.2"
he "^1.2.0"
htmlparser2 "^6.1.0"
minimist "^1.2.6"
selderee "^0.6.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
htmlencode@^0.0.4:
version "0.0.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/htmlencode/-/htmlencode-0.0.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-0uDvNVpzj/E2TfvLLyyXhKBRvF1y84aZsyRxRXFsQobnHaL4pcaXk+Y9cnFlvnxrBLeXDNq/VJBD+ngdBgQG1w==
htmlparser2@^6.0.0, htmlparser2@^6.1.0:
version "6.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/htmlparser2/-/htmlparser2-6.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-gyyPk6rgonLFEDGoeRgQNaEUvdJ4ktTmmUh/h2t7s+M8oPpIPxgNACWa+6ESR57kXstwqPiCut0V8NRpcwgU7A==
dependencies:
domelementtype "^2.0.1"
domhandler "^4.0.0"
domutils "^2.5.2"
entities "^2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
http-errors@2.0.0:
version "2.0.0"
resolved "https://registry.npmjs.org/http-errors/-/http-errors-2.0.0.tgz"
integrity sha512-FtwrG/euBzaEjYeRqOgly7G0qviiXoJWnvEH2Z1plBdXgbyjv34pHTSb9zoeHMyDy33+DWy5Wt9Wo+TURtOYSQ==
dependencies:
depd "2.0.0"
inherits "2.0.4"
setprototypeof "1.2.0"
statuses "2.0.1"
toidentifier "1.0.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
http-proxy-agent@^4.0.1:
version "4.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/http-proxy-agent/-/http-proxy-agent-4.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-k0zdNgqWTGA6aeIRVpvfVob4fL52dTfaehylg0Y4UvSySvOq/Y+BOyPrgpUrA7HylqvU8vIZGsRuXmspskV0Tg==
dependencies:
"@tootallnate/once" "1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
agent-base "6"
debug "4"
http-signature@~1.2.0:
version "1.2.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/http-signature/-/http-signature-1.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-CAbnr6Rz4CYQkLYUtSNXxQPUH2gK8f3iWexVlsnMeD+GjlsQ0Xsy1cOX+mN3dtxYomRy21CiOzU8Uhw6OwncEQ==
dependencies:
assert-plus "^1.0.0"
jsprim "^1.2.2"
sshpk "^1.7.0"
https-proxy-agent@^5.0.0:
version "5.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/https-proxy-agent/-/https-proxy-agent-5.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-EkYm5BcKUGiduxzSt3Eppko+PiNWNEpa4ySk9vTC6wDsQJW9rHSa+UhGNJoRYp7bz6Ht1eaRIa6QaJqO5rCFbA==
dependencies:
agent-base "6"
debug "4"
humanize-duration-ts@^2.1.1:
version "2.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/humanize-duration-ts/-/humanize-duration-ts-2.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-TibNF2/fkypjAfHdGpWL/dmWUS0G6Qi+3mKyiB6LDCowbMy+PtzbgPTnFMNTOVAJXDau01jYrJ3tFoz5AJSqhA==
humanize-duration@^3.27.1:
version "3.27.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/humanize-duration/-/humanize-duration-3.27.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-A15OmA3FLFRnehvF4ZMocsxTZYvHq4ze7L+AgR1DeHw0xC9vMd4euInY83uqGU9/XXKNnVIEeKc1R8G8nKqtzg==
iconv-lite@0.4.24:
version "0.4.24"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.24.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA==
dependencies:
safer-buffer ">= 2.1.2 < 3"
ignore@^4.0.6:
version "4.0.6"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ignore/-/ignore-4.0.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-cyFDKrqc/YdcWFniJhzI42+AzS+gNwmUzOSFcRCQYwySuBBBy/KjuxWLZ/FHEH6Moq1NizMOBWyTcv8O4OZIMg==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
immediate@~3.0.5:
version "3.0.6"
resolved "https://registry.npmjs.org/immediate/-/immediate-3.0.6.tgz"
integrity sha512-XXOFtyqDjNDAQxVfYxuF7g9Il/IbWmmlQg2MYKOH8ExIT1qg6xc4zyS3HaEEATgs1btfzxq15ciUiY7gjSXRGQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
import-fresh@^3.0.0, import-fresh@^3.2.1:
version "3.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/import-fresh/-/import-fresh-3.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-veYYhQa+D1QBKznvhUHxb8faxlrwUnxseDAbAp457E0wLNio2bOSKnjYDhMj+YiAq61xrMGhQk9iXVk5FzgQMw==
dependencies:
parent-module "^1.0.0"
resolve-from "^4.0.0"
imurmurhash@^0.1.4:
version "0.1.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/imurmurhash/-/imurmurhash-0.1.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-JmXMZ6wuvDmLiHEml9ykzqO6lwFbof0GG4IkcGaENdCRDDmMVnny7s5HsIgHCbaq0w2MyPhDqkhTUgS2LU2PHA==
inflight@^1.0.4:
version "1.0.6"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==
dependencies:
once "^1.3.0"
wrappy "1"
inherits@2, inherits@2.0.4, inherits@^2.0.3:
version "2.0.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
ip-address@^7.1.0:
version "7.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/ip-address/-/ip-address-7.1.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-V9pWC/VJf2lsXqP7IWJ+pe3P1/HCYGBMZrrnT62niLGjAfCbeiwXMUxaeHvnVlz19O27pvXP4azs+Pj/A0x+SQ==
dependencies:
jsbn "1.1.0"
sprintf-js "1.1.2"
ip-cidr@^3.0.4:
version "3.0.10"
resolved "https://registry.npmjs.org/ip-cidr/-/ip-cidr-3.0.10.tgz"
integrity sha512-PXSsrRYirsuaCI1qBVyVXRLUIpNzxm76eHd3UvN5NXTMUG85GWGZpr6P+70mimc5e7Nfh/tShmjk0oSywErMWg==
dependencies:
ip-address "^7.1.0"
jsbn "^1.1.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
ipaddr.js@1.9.1:
version "1.9.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ipaddr.js/-/ipaddr.js-1.9.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-0KI/607xoxSToH7GjN1FfSbLoU0+btTicjsQSWQlh/hZykN8KpmMf7uYwPW3R+akZ6R/w18ZlXSHBYXiYUPO3g==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
is-arrayish@^0.3.1:
version "0.3.2"
resolved "https://registry.npmjs.org/is-arrayish/-/is-arrayish-0.3.2.tgz"
integrity sha512-eVRqCvVlZbuw3GrM63ovNSNAeA1K16kaR/LRY/92w0zxQ5/1YzwblUX652i4Xs9RwAGjW9d9y6X88t8OaAJfWQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
is-binary-path@~2.1.0:
version "2.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==
dependencies:
binary-extensions "^2.0.0"
is-core-module@^2.2.0:
version "2.7.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/is-core-module/-/is-core-module-2.7.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ByY+tjCciCr+9nLryBYcSD50EOGWt95c7tIsKTG1J2ixKKXPvF7Ej3AVd+UfDydAJom3biBGDBALaO79ktwgEQ==
dependencies:
has "^1.0.3"
is-extglob@^2.1.1:
version "2.1.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz"
integrity "sha1-qIwCU1eR8C7TfHahueqXc8gz+MI= sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ=="
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
is-fullwidth-code-point@^3.0.0:
version "3.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==
is-glob@^4.0.0, is-glob@^4.0.1, is-glob@~4.0.1:
version "4.0.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==
dependencies:
is-extglob "^2.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
is-my-ip-valid@^1.0.0:
version "1.0.1"
resolved "https://registry.npmjs.org/is-my-ip-valid/-/is-my-ip-valid-1.0.1.tgz"
integrity sha512-jxc8cBcOWbNK2i2aTkCZP6i7wkHF1bqKFrwEHuN5Jtg5BSaZHUZQ/JTOJwoV41YvHnOaRyWWh72T/KvfNz9DJg==
is-my-json-valid@^2.20.5:
version "2.20.6"
resolved "https://registry.npmjs.org/is-my-json-valid/-/is-my-json-valid-2.20.6.tgz"
integrity sha512-1JQwulVNjx8UqkPE/bqDaxtH4PXCe/2VRh/y3p99heOV87HG4Id5/VfDswd+YiAfHcRTfDlWgISycnHuhZq1aw==
dependencies:
generate-function "^2.0.0"
generate-object-property "^1.1.0"
is-my-ip-valid "^1.0.0"
jsonpointer "^5.0.0"
xtend "^4.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
is-number@^7.0.0:
version "7.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==
is-plain-obj@^2.1.0:
version "2.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/is-plain-obj/-/is-plain-obj-2.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-YWnfyRwxL/+SsrWYfOpUtz5b3YD+nyfkHvjbcanzk8zgyO4ASD67uVMRt8k5bM4lLMDnXfriRhOpemw+NfT1eA==
is-plain-object@^5.0.0:
version "5.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/is-plain-object/-/is-plain-object-5.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-VRSzKkbMm5jMDoKLbltAkFQ5Qr7VDiTFGXxYFXXowVj387GeGNOCsOH6Msy00SGZ3Fp84b1Naa1psqgcCIEP5Q==
is-potential-custom-element-name@^1.0.1:
version "1.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/is-potential-custom-element-name/-/is-potential-custom-element-name-1.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-bCYeRA2rVibKZd+s2625gGnGF/t7DSqDs4dP7CrLA1m7jKWz6pps0LpYLJN8Q64HtmPKJ1hrN3nzPNKFEKOUiQ==
is-promise@^2.1.0:
version "2.2.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/is-promise/-/is-promise-2.2.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-+lP4/6lKUBfQjZ2pdxThZvLUAafmZb8OAxFb8XXtiQmS35INgr85hdOGoEs124ez1FCnZJt6jau/T+alh58QFQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
is-property@^1.0.0, is-property@^1.0.2:
version "1.0.2"
resolved "https://registry.npmjs.org/is-property/-/is-property-1.0.2.tgz"
integrity sha512-Ks/IoX00TtClbGQr4TWXemAnktAQvYB7HzcCxDGqEZU6oCmb2INHuOoKxbtR+HFkmYWBKv/dOZtGRiAjDhj92g==
is-stream@^2.0.0:
version "2.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/is-stream/-/is-stream-2.0.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-hFoiJiTl63nn+kstHGBtewWSKnQLpyb155KHheA1l39uvtO9nWIop1p3udqPcUd/xbF1VLMO4n7OI6p7RbngDg==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
is-typedarray@~1.0.0:
version "1.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/is-typedarray/-/is-typedarray-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-cyA56iCMHAh5CdzjJIa4aohJyeO1YbwLi3Jc35MmRU6poroFjIGZzUzupGiRPOjgHg9TLu43xbpwXk523fMxKA==
is-unicode-supported@^0.1.0:
version "0.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/is-unicode-supported/-/is-unicode-supported-0.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-knxG2q4UC3u8stRGyAVJCOdxFmv5DZiRcdlIaAQXAbSfJya+OhopNotLQrstBhququ4ZpuKbDc/8S6mgXgPFPw==
isexe@^2.0.0:
version "2.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz"
integrity "sha1-6PvzdNxVb/iUehDcsFctYz8s+hA= sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw=="
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
isstream@~0.1.2:
version "0.1.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/isstream/-/isstream-0.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Yljz7ffyPbrLpLngrMtZ7NduUgVvi6wG9RJ9IUcyCd59YQ911PBJphODUcbOVbqYfxe1wuYf/LJ8PauMRwsM/g==
jest-diff@^27.2.4:
version "27.2.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/jest-diff/-/jest-diff-27.2.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-bLAVlDSCR3gqUPGv+4nzVpEXGsHh98HjUL7Vb2hVyyuBDoQmja8eJb0imUABsuxBeUVmf47taJSAd9nDrwWKEg==
dependencies:
chalk "^4.0.0"
diff-sequences "^27.0.6"
jest-get-type "^27.0.6"
pretty-format "^27.2.4"
jest-get-type@^27.0.6:
version "27.0.6"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/jest-get-type/-/jest-get-type-27.0.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-XTkK5exIeUbbveehcSR8w0bhH+c0yloW/Wpl+9vZrjzztCPWrxhHwkIFpZzCt71oRBsgxmuUfxEqOYoZI2macg==
jest-matcher-utils@^27.2.4:
version "27.2.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/jest-matcher-utils/-/jest-matcher-utils-27.2.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-nQeLfFAIPPkyhkDfifAPfP/U5wm1x0fLtAzqXZSSKckXDNuk2aaOfQiDYv1Mgf5GY6yOsxfUnvNm3dDjXM+BXw==
dependencies:
chalk "^4.0.0"
jest-diff "^27.2.4"
jest-get-type "^27.0.6"
pretty-format "^27.2.4"
jest-message-util@^27.2.4:
version "27.2.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/jest-message-util/-/jest-message-util-27.2.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-wbKT/BNGnBVB9nzi+IoaLkXt6fbSvqUxx+IYY66YFh96J3goY33BAaNG3uPqaw/Sh/FR9YpXGVDfd5DJdbh4nA==
2021-07-01 19:45:28 +00:00
dependencies:
"@babel/code-frame" "^7.12.13"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
"@jest/types" "^27.2.4"
2021-07-01 19:45:28 +00:00
"@types/stack-utils" "^2.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
chalk "^4.0.0"
graceful-fs "^4.2.4"
micromatch "^4.0.4"
pretty-format "^27.2.4"
slash "^3.0.0"
stack-utils "^2.0.3"
jest-regex-util@^27.0.6:
version "27.0.6"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/jest-regex-util/-/jest-regex-util-27.0.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-SUhPzBsGa1IKm8hx2F4NfTGGp+r7BXJ4CulsZ1k2kI+mGLG+lxGrs76veN2LF/aUdGosJBzKgXmNCw+BzFqBDQ==
js-tokens@^4.0.0:
version "4.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/js-tokens/-/js-tokens-4.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
js-yaml@4.1.0, js-yaml@^4.0.0, js-yaml@^4.1.0:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "4.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==
dependencies:
argparse "^2.0.1"
js-yaml@^3.13.1:
version "3.14.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/js-yaml/-/js-yaml-3.14.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-okMH7OXXJ7YrN9Ok3/SXrnu4iX9yOk+25nqX4imS2npuvTYDmo/QEZoqwZkYaIDk3jVvBOTOIEgEhaLOynBS9g==
dependencies:
argparse "^1.0.7"
esprima "^4.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
jsbn@1.1.0, jsbn@^1.1.0:
version "1.1.0"
resolved "https://registry.npmjs.org/jsbn/-/jsbn-1.1.0.tgz"
integrity sha512-4bYVV3aAMtDTTu4+xsDYa6sy9GyJ69/amsu9sYF2zqjiEoZA5xJi3BrfX3uY+/IekIu7MwdObdbDWpoZdBv3/A==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
jsbn@~0.1.0:
version "0.1.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/jsbn/-/jsbn-0.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-UVU9dibq2JcFWxQPA6KCqj5O42VOmAY3zQUfEKxU0KpTGXwNoCjkX1e13eHNvw/xPynt6pU0rZ1htjWTNTSXsg==
jsdom@^16.6.0:
version "16.7.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/jsdom/-/jsdom-16.7.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-u9Smc2G1USStM+s/x1ru5Sxrl6mPYCbByG1U/hUmqaVsm4tbNyS7CicOSRyuGQYZhTu0h84qkZZQ/I+dzizSVw==
dependencies:
abab "^2.0.5"
acorn "^8.2.4"
acorn-globals "^6.0.0"
cssom "^0.4.4"
cssstyle "^2.3.0"
data-urls "^2.0.0"
decimal.js "^10.2.1"
domexception "^2.0.1"
escodegen "^2.0.0"
form-data "^3.0.0"
html-encoding-sniffer "^2.0.1"
http-proxy-agent "^4.0.1"
https-proxy-agent "^5.0.0"
is-potential-custom-element-name "^1.0.1"
nwsapi "^2.2.0"
parse5 "6.0.1"
saxes "^5.0.1"
symbol-tree "^3.2.4"
tough-cookie "^4.0.0"
w3c-hr-time "^1.0.2"
w3c-xmlserializer "^2.0.0"
webidl-conversions "^6.1.0"
whatwg-encoding "^1.0.5"
whatwg-mimetype "^2.3.0"
whatwg-url "^8.5.0"
ws "^7.4.6"
xml-name-validator "^3.0.0"
json-schema-traverse@^0.4.1:
version "0.4.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-0.4.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==
json-schema-traverse@^1.0.0:
version "1.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==
json-schema@0.4.0:
version "0.4.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/json-schema/-/json-schema-0.4.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-es94M3nTIfsEPisRafak+HDLfHXnKBhV3vU5eqPcS3flIWqcxJWgXHXiey3YrpaNsanY5ei1VoYEbOzijuq9BA==
json-stable-stringify-without-jsonify@^1.0.1:
version "1.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/json-stable-stringify-without-jsonify/-/json-stable-stringify-without-jsonify-1.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Bdboy+l7tA3OGW6FjyFHWkP5LuByj1Tk33Ljyq0axyzdk9//JSi2u3fP1QSmd1KNwq6VOKYGlAu87CisVir6Pw==
json-stringify-safe@~5.0.1:
version "5.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/json-stringify-safe/-/json-stringify-safe-5.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ZClg6AaYvamvYEE82d3Iyd3vSSIjQ+odgjaTzRuO3s7toCdFKczob2i0zCh7JE8kWn17yvAWhUVxvqGwUalsRA==
json5@^1.0.1:
version "1.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/json5/-/json5-1.0.2.tgz"
integrity sha512-g1MWMLBiz8FKi1e4w0UyVL3w+iJceWAFBAaBnnGKOpNa5f8TLktkbre1+s6oICydWAm+HRUGTmI+//xv2hvXYA==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
minimist "^1.2.0"
json5@^2.2.1:
version "2.2.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/json5/-/json5-2.2.1.tgz"
integrity sha512-1hqLFMSrGHRHxav9q9gNjJ5EXznIxGVO09xQRrwplcS8qs28pZ8s8hupZAmqDwZUmVZ2Qb2jnyPOWcDH8m8dlA==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
jsonpointer@^5.0.0:
version "5.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/jsonpointer/-/jsonpointer-5.0.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-p/nXbhSEcu3pZRdkW1OfJhpsVtW1gd4Wa1fnQc9YLiTfAjn0312eMKimbdIQzuZl9aa9xUGaRlP9T/CJE/ditQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
jsprim@^1.2.2:
version "1.4.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/jsprim/-/jsprim-1.4.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-P2bSOMAc/ciLz6DzgjVlGJP9+BrJWu5UDGK70C2iweC5QBIeFf0ZXRvGjEj2uYgrY2MkAAhsSWHDWlFtEroZWw==
dependencies:
assert-plus "1.0.0"
extsprintf "1.3.0"
json-schema "0.4.0"
verror "1.10.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
kuler@^2.0.0:
version "2.0.0"
resolved "https://registry.npmjs.org/kuler/-/kuler-2.0.0.tgz"
integrity sha512-Xq9nH7KlWZmXAtodXDDRE7vs6DU1gTU8zYDHDiWLSip45Egwq3plLHzPn27NgvzL2r1LMPC1vdqh98sQxtqj4A==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
A look at `PolicyList.update` (#454) This started out as just a way to find out why mjolnir was syncing with lists several times for each update to a policy list. The main changes are - Verbosity was irrelevant to the sync command but for some reason was an option. Unfortunately all this did was suppress whether to tell you when it had finished, meaning it wouldn't when verbose logging was disabled. Historically this was probably a parameter that got passed through to applyServerAcl/applyUserBans, which can be horribly verbose, but they access the config directly. - Stop emitting `'PolicyList.update'` when there are no changes. - Include a revision ID for the `'PolicyList.update'`method and event. - Use the revision ID in the `ProtectedRoomsSet` so that we don't unnecessarily resynchronize all rooms when the `'PolicyList.update'` event is received. Though not when the `sync` command is used. Since this is supposed to `sync` in the case when there is a state reset or otherwise or the user has changed some room settings. - insert an await lock around the `PolicyList.update` method to avoid a race condition where a call can be started and finished within the extent of an existing call (via another task, this can happen if the server is slow with handling one request). `PolicyList.udpate` now has a helper that is synchronous to be called directly after requesting the room state. The reason for this is to enforce that no one `await`s while updating the policy list's cache of rules. Which is important because it is one of the biggest methods that I tolerate and visually checking for `await` is impossible. - The revision ID uses a ULID, but this is unnecessary and could have just been a "dumb counter". closes https://github.com/matrix-org/mjolnir/issues/447
2022-12-08 16:09:55 +00:00
layerr@^0.1.2:
version "0.1.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/layerr/-/layerr-0.1.2.tgz"
A look at `PolicyList.update` (#454) This started out as just a way to find out why mjolnir was syncing with lists several times for each update to a policy list. The main changes are - Verbosity was irrelevant to the sync command but for some reason was an option. Unfortunately all this did was suppress whether to tell you when it had finished, meaning it wouldn't when verbose logging was disabled. Historically this was probably a parameter that got passed through to applyServerAcl/applyUserBans, which can be horribly verbose, but they access the config directly. - Stop emitting `'PolicyList.update'` when there are no changes. - Include a revision ID for the `'PolicyList.update'`method and event. - Use the revision ID in the `ProtectedRoomsSet` so that we don't unnecessarily resynchronize all rooms when the `'PolicyList.update'` event is received. Though not when the `sync` command is used. Since this is supposed to `sync` in the case when there is a state reset or otherwise or the user has changed some room settings. - insert an await lock around the `PolicyList.update` method to avoid a race condition where a call can be started and finished within the extent of an existing call (via another task, this can happen if the server is slow with handling one request). `PolicyList.udpate` now has a helper that is synchronous to be called directly after requesting the room state. The reason for this is to enforce that no one `await`s while updating the policy list's cache of rules. Which is important because it is one of the biggest methods that I tolerate and visually checking for `await` is impossible. - The revision ID uses a ULID, but this is unnecessary and could have just been a "dumb counter". closes https://github.com/matrix-org/mjolnir/issues/447
2022-12-08 16:09:55 +00:00
integrity sha512-ob5kTd9H3S4GOG2nVXyQhOu9O8nBgP555XxWPkJI0tR0JeRilfyTp8WtPdIJHLXBmHMSdEq5+KMxiYABeScsIQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
levn@^0.4.1:
version "0.4.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/levn/-/levn-0.4.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-+bT2uH4E5LGE7h/n3evcS/sQlJXCpIp6ym8OWJ5eV6+67Dsql/LaaT7qJBAt2rzfoa/5QBGBhxDix1dMt2kQKQ==
dependencies:
prelude-ls "^1.2.1"
type-check "~0.4.0"
levn@~0.3.0:
version "0.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/levn/-/levn-0.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-0OO4y2iOHix2W6ujICbKIaEQXvFQHue65vUG3pb5EUomzPI90z9hsA1VsO/dbIIpC53J8gxM9Q4Oho0jrCM/yA==
dependencies:
prelude-ls "~1.1.2"
type-check "~0.3.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
lie@3.1.1:
version "3.1.1"
resolved "https://registry.npmjs.org/lie/-/lie-3.1.1.tgz"
integrity sha512-RiNhHysUjhrDQntfYSfY4MU24coXXdEOgw9WGcKHNeEwffDYbF//u87M1EWaMGzuFoSbqW0C9C6lEEhDOAswfw==
dependencies:
immediate "~3.0.5"
localforage@^1.3.0:
version "1.10.0"
resolved "https://registry.npmjs.org/localforage/-/localforage-1.10.0.tgz"
integrity sha512-14/H1aX7hzBBmmh7sGPd+AOMkkIrHM3Z1PAyGgZigA1H1p5O5ANnMyWzvpAETtG68/dC4pC0ncy3+PPGzXZHPg==
dependencies:
lie "3.1.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
locate-path@^6.0.0:
version "6.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/locate-path/-/locate-path-6.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-iPZK6eYjbxRu3uB4/WZ3EsEIMJFMqAoopl3R+zuq0UjcAm/MO6KCweDgPfP3elTztoKP3KtnVHxTn2NHBSDVUw==
dependencies:
p-locate "^5.0.0"
lodash.clonedeep@^4.5.0:
version "4.5.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/lodash.clonedeep/-/lodash.clonedeep-4.5.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-H5ZhCF25riFd9uB5UCkVKo61m3S/xZk1x4wA6yp/L3RFP6Z/eHH1ymQcGLo7J3GMPfm0V/7m1tryHuGVxpqEBQ==
lodash.merge@^4.6.2:
version "4.6.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/lodash.merge/-/lodash.merge-4.6.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==
lodash.truncate@^4.4.2:
version "4.4.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/lodash.truncate/-/lodash.truncate-4.4.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-jttmRe7bRse52OsWIMDLaXxWqRAmtIUccAQ3garviCqJjafXOfNMO0yMfNpdD6zbGaTU0P5Nz7e7gAT6cKmJRw==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
lodash@4, lodash@^4.17.19, lodash@^4.7.0:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "4.17.21"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==
log-symbols@4.1.0:
version "4.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/log-symbols/-/log-symbols-4.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-8XPvpAA8uyhfteu8pIvQxpJZ7SYYdpUivZpGy6sFsBuKRY/7rQGavedeB8aK+Zkyq6upMFVL/9AW6vOYzfRyLg==
dependencies:
chalk "^4.1.0"
is-unicode-supported "^0.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
logform@^2.3.2, logform@^2.4.0:
version "2.4.2"
resolved "https://registry.npmjs.org/logform/-/logform-2.4.2.tgz"
integrity sha512-W4c9himeAwXEdZ05dQNerhFz2XG80P9Oj0loPUMV23VC2it0orMHQhJm4hdnnor3rd1HsGf6a2lPwBM1zeXHGw==
dependencies:
"@colors/colors" "1.5.0"
fecha "^4.2.0"
ms "^2.1.1"
safe-stable-stringify "^2.3.1"
triple-beam "^1.3.0"
lowdb@^1:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/lowdb/-/lowdb-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-2+x8esE/Wb9SQ1F9IHaYWfsC9FIecLOPrK4g17FGEayjUWH172H6nwicRovGvSE2CPZouc2MCIqCI7h9d+GftQ==
dependencies:
graceful-fs "^4.1.3"
is-promise "^2.1.0"
lodash "4"
pify "^3.0.0"
steno "^0.4.1"
lru-cache@^4.1.5:
version "4.1.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/lru-cache/-/lru-cache-4.1.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-sWZlbEP2OsHNkXrMl5GYk/jKk70MBng6UU4YI/qGDYbgf6YbP4EvmqISbXCoJiRKs+1bSpFHVgQxvJ17F2li5g==
dependencies:
pseudomap "^1.0.2"
yallist "^2.1.2"
lru-cache@^6.0.0:
version "6.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/lru-cache/-/lru-cache-6.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Jo6dJ04CmSjuznwJSS3pUeWmd/H0ffTlkXXgwZi+eq1UCmqQwCh+eLsYOYCwY991i2Fah4h1BEMCx4qThGbsiA==
dependencies:
yallist "^4.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
lru-cache@^7.10.1:
version "7.13.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/lru-cache/-/lru-cache-7.13.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-CHqbAq7NFlW3RSnoWXLJBxCWaZVBrfa9UEHId2M3AW8iEBurbqduNexEUCGc3SHc6iCYXNJCDi903LajSVAEPQ==
lru_map@^0.3.3:
version "0.3.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/lru_map/-/lru_map-0.3.3.tgz"
integrity sha512-Pn9cox5CsMYngeDbmChANltQl+5pi6XmTrraMSzhPmMBbmgcxmqWry0U3PGapCU1yB4/LqCcom7qhHZiF/jGfQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
make-error@^1.1.1:
version "1.3.6"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/make-error/-/make-error-1.3.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-s8UhlNe7vPKomQhC1qFelMokr/Sc3AgNbso3n74mVPA5LTZwkB9NlXf4XPamLxJE8h0gh73rM94xvwRT2CVInw==
matrix-appservice-bridge@8.1.2:
version "8.1.2"
resolved "https://registry.yarnpkg.com/matrix-appservice-bridge/-/matrix-appservice-bridge-8.1.2.tgz#30953a4599533fe61a0c37bd5500b654cd236e30"
integrity sha512-OTQVEuYgsnlg7fBFASCaiYHgwi5+I/+vxwjOmR4y9n5ESKXoqI465bN+6zvW8MazdNfBl6NgZVWSm4DZohz8Zw==
2019-09-26 02:13:20 +00:00
dependencies:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
"@alloc/quick-lru" "^5.2.0"
"@types/pkginfo" "^0.4.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
axios "^0.27.2"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
chalk "^4.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
express "^4.18.1"
express-rate-limit "^6.7.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
extend "^3.0.2"
ip-cidr "^3.0.4"
is-my-json-valid "^2.20.5"
js-yaml "^4.0.0"
matrix-appservice "^1.1.0"
matrix-bot-sdk "^0.6.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
nedb "^1.8.0"
nopt "^5.0.0"
p-queue "^6.6.2"
pkginfo "^0.4.1"
postgres "^3.3.1"
prom-client "^14.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
uuid "^8.3.2"
winston "^3.3.3"
winston-daily-rotate-file "^4.5.1"
matrix-appservice@^1.1.0:
version "1.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/matrix-appservice/-/matrix-appservice-1.1.0.tgz"
integrity sha512-6hJdmo9YIbh6dS9MfMHCpHMhklN/+NOcfGQ/3UbbEEfIE8dt0bHqi1nnIiias5IqDFl6ED9y+YQdtyqnIXx+Ww==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
dependencies:
"@types/express" "^4.17.8"
body-parser "^1.19.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
express "^4.17.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
js-yaml "^4.1.0"
morgan "^1.10.0"
matrix-bot-sdk@^0.6.2:
version "0.6.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/matrix-bot-sdk/-/matrix-bot-sdk-0.6.2.tgz"
integrity sha512-+kXlXkQBQgWC6oUwYEosJlXjceaj7jQUnPlALFhGeAabgVm8tmuvFNVKqClwvrrjj+0Gzsmt+rcJHmkvqymFXA==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
dependencies:
"@matrix-org/matrix-sdk-crypto-nodejs" "^0.1.0-beta.1"
"@types/express" "^4.17.13"
another-json "^0.2.0"
async-lock "^1.3.2"
chalk "^4"
express "^4.18.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
glob-to-regexp "^0.4.1"
hash.js "^1.1.7"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
html-to-text "^8.2.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
htmlencode "^0.0.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
lowdb "^1"
lru-cache "^7.10.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
mkdirp "^1.0.4"
morgan "^1.10.0"
request "^2.88.2"
request-promise "^4.2.6"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
sanitize-html "^2.7.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
media-typer@0.3.0:
version "0.3.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-dq+qelQ9akHpcOl/gUVRTxVIOkAJ1wR3QAvb4RsVjS8oVoFjDGTc679wJYmUmknUF5HwMLOgb5O+a3KxfWapPQ==
merge-descriptors@1.0.1:
version "1.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/merge-descriptors/-/merge-descriptors-1.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-cCi6g3/Zr1iqQi6ySbseM1Xvooa98N0w31jzUYrXPX2xqObmFGHJ0tQ5u74H3mVh7wLouTseZyYIq39g8cNp1w==
methods@~1.1.2:
version "1.1.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/methods/-/methods-1.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-iclAHeNqNm68zFtnZ0e+1L2yUIdvzNoauKU4WBA3VvH/vPFieF7qfRlwUZU+DA9P9bPXIS90ulxoUoCH23sV2w==
micromatch@^4.0.4:
version "4.0.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/micromatch/-/micromatch-4.0.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-pRmzw/XUcwXGpD9aI9q/0XOwLNygjETJ8y0ao0wdqprrzDa4YnxLcz7fQRZr8voh8V10kGhABbNcHVk5wHgWwg==
dependencies:
braces "^3.0.1"
picomatch "^2.2.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
mime-db@1.52.0:
version "1.52.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/mime-db/-/mime-db-1.52.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
mime-types@^2.1.12, mime-types@~2.1.19, mime-types@~2.1.24, mime-types@~2.1.34:
version "2.1.35"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/mime-types/-/mime-types-2.1.35.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-ZDY+bPm5zTTF+YpCrAU9nK0UgICYPT0QtT1NZWFv4s++TNkcgVaT0g6+4R2uI4MjQjzysHB1zxuWL50hzaeXiw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
mime-db "1.52.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
mime@1.6.0:
version "1.6.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/mime/-/mime-1.6.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-x0Vn8spI+wuJ1O6S7gnbaQg8Pxh4NNHb7KSINmEWKiPE4RKOplvijn+NkmYmmRgP68mc70j2EbeTFRsrswaQeg==
minimalistic-assert@^1.0.1:
version "1.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/minimalistic-assert/-/minimalistic-assert-1.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-UtJcAD4yEaGtjPezWuO9wC4nwUnVH/8/Im3yEHQP4b67cXlD/Qr9hdITCU1xDbSEXg2XKNaP8jsReV7vQd00/A==
minimatch@4.2.1:
version "4.2.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/minimatch/-/minimatch-4.2.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-9Uq1ChtSZO+Mxa/CL1eGizn2vRn3MlLgzhT0Iz8zaY8NdvxvB0d5QdPFmCKf7JKA9Lerx5vRrnwO03jsSfGG9g==
dependencies:
brace-expansion "^1.1.7"
2023-04-03 20:03:02 +00:00
minimatch@^3.0.4:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "3.1.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==
dependencies:
brace-expansion "^1.1.7"
minimist@^1.2.0, minimist@^1.2.5, minimist@^1.2.6:
version "1.2.7"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/minimist/-/minimist-1.2.7.tgz"
integrity sha512-bzfL1YUZsP41gmu/qjrEk0Q6i2ix/cVeAhbCbqH9u3zYutS1cLg00qhrD0M2MVdCcx4Sc0UpP2eBWo9rotpq6g==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
mkdirp@^0.5.1, mkdirp@^0.5.3:
version "0.5.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-NKmAlESf6jMGym1++R0Ra7wvhV+wFW63FaSOFPwRahvea0gMUcGUhVeAg/0BC0wiv9ih5NYPB1Wn1UEI1/L+xQ==
dependencies:
minimist "^1.2.5"
mkdirp@^1.0.4:
version "1.0.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/mkdirp/-/mkdirp-1.0.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-vVqVZQyf3WLx2Shd0qJ9xuvqgAyKPLAiqITEtqW0oIUjzo3PePDd6fW9iFz30ef7Ysp/oiWqbhszeGWW2T6Gzw==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
mkdirp@~0.5.1:
version "0.5.6"
resolved "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.6.tgz"
integrity sha512-FP+p8RB8OWpF3YZBCrP5gtADmtXApB5AMLn+vdyA+PyxCjrCs00mjyUozssO33cwDeT3wNGdLxJ5M//YqtHAJw==
dependencies:
minimist "^1.2.6"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
mocha@^9.0.1:
version "9.2.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/mocha/-/mocha-9.2.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-L6XC3EdwT6YrIk0yXpavvLkn8h+EU+Y5UcCHKECyMbdUIxyMuZj4bX4U9e1nvnvUUvQVsV2VHQr5zLdcUkhW/g==
dependencies:
2021-07-01 19:45:28 +00:00
"@ungap/promise-all-settled" "1.1.2"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
ansi-colors "4.1.1"
browser-stdout "1.3.1"
chokidar "3.5.3"
debug "4.3.3"
diff "5.0.0"
escape-string-regexp "4.0.0"
find-up "5.0.0"
glob "7.2.0"
growl "1.10.5"
he "1.2.0"
js-yaml "4.1.0"
log-symbols "4.1.0"
minimatch "4.2.1"
ms "2.1.3"
nanoid "3.3.1"
serialize-javascript "6.0.0"
strip-json-comments "3.1.1"
supports-color "8.1.1"
which "2.0.2"
workerpool "6.2.0"
yargs "16.2.0"
yargs-parser "20.2.4"
yargs-unparser "2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
moment@^2.29.1:
version "2.29.4"
resolved "https://registry.npmjs.org/moment/-/moment-2.29.4.tgz"
integrity sha512-5LC9SOxjSc2HF6vO2CyuTDNivEdoz2IvyJJGj6X8DJ0eFyfszE0QiEd+iXmBvUP3WHxSjFH/vIsA0EN00cgr8w==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
moo@^0.5.0, moo@^0.5.1:
version "0.5.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/moo/-/moo-0.5.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-I1mnb5xn4fO80BH9BLcF0yLypy2UKl+Cb01Fu0hJRkJjlCRtxZMWkTdAtDd5ZqCOxtCkhmRwyI57vWT+1iZ67w==
morgan@^1.10.0:
version "1.10.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/morgan/-/morgan-1.10.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-AbegBVI4sh6El+1gNwvD5YIck7nSA36weD7xvIxG4in80j/UoK8AEGaWnnz8v1GxonMCltmlNs5ZKbGvl9b1XQ==
dependencies:
basic-auth "~2.0.1"
debug "2.6.9"
depd "~2.0.0"
on-finished "~2.3.0"
on-headers "~1.0.2"
ms@2.0.0:
version "2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ms/-/ms-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Tpp60P6IUJDTuOq/5Z8cdskzJujfwqfOTkrwIwj7IRISpnkJnT6SyJ4PCPnGMoFjC9ddhal5KVIYtAt97ix05A==
ms@2.1.2:
version "2.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
ms@2.1.3, ms@^2.1.1:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "2.1.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
nanoid@3.3.1:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "3.3.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/nanoid/-/nanoid-3.3.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-n6Vs/3KGyxPQd6uO0eH4Bv0ojGSUvuLlIHtC3Y0kEO23YRge8H9x1GCzLn28YX0H66pMkxuaeESFq4tKISKwdw==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
nanoid@^3.3.4:
version "3.3.4"
resolved "https://registry.npmjs.org/nanoid/-/nanoid-3.3.4.tgz"
integrity sha512-MqBkQh/OHTS2egovRtLk45wEyNXwF+cokD+1YPf9u5VfJiRdAiRwB2froX5Co9Rh20xs4siNPm8naNotSD6RBw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
natural-compare@^1.4.0:
version "1.4.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/natural-compare/-/natural-compare-1.4.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-OWND8ei3VtNC9h7V60qff3SVobHr996CTwgxubgyQYEpg290h9J0buyECNNJexkFm5sOajh5G116RYA1c8ZMSw==
nearley@^2.20.1:
version "2.20.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/nearley/-/nearley-2.20.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-+Mc8UaAebFzgV+KpI5n7DasuuQCHA89dmwm7JXw3TV43ukfNQ9DnBH3Mdb2g/I4Fdxc26pwimBWvjIw0UAILSQ==
dependencies:
commander "^2.19.0"
moo "^0.5.0"
railroad-diagrams "^1.0.0"
randexp "0.4.6"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
nedb@^1.8.0:
version "1.8.0"
resolved "https://registry.npmjs.org/nedb/-/nedb-1.8.0.tgz"
integrity sha512-ip7BJdyb5m+86ZbSb4y10FCCW9g35+U8bDRrZlAfCI6m4dKwEsQ5M52grcDcVK4Vm/vnPlDLywkyo3GliEkb5A==
dependencies:
async "0.2.10"
binary-search-tree "0.2.5"
localforage "^1.3.0"
mkdirp "~0.5.1"
underscore "~1.4.4"
negotiator@0.6.3:
version "0.6.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/negotiator/-/negotiator-0.6.3.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-+EUsqGPLsM+j/zdChZjsnX51g4XrHFOIXwfnCVPGlQk/k5giakcKsuxCObBRu6DSm9opw/O6slWbJdghQM4bBg==
node-downloader-helper@^2.1.1:
version "2.1.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/node-downloader-helper/-/node-downloader-helper-2.1.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-ouk8MGmJj1gYymbJwi1L8Mr6PdyheJLwfsmyx0KtsvyJ+7Fpf0kBBzM8Gmx8Mt/JBfRWP1PQm6dAGV6x7eNedw==
nopt@^5.0.0:
version "5.0.0"
resolved "https://registry.npmjs.org/nopt/-/nopt-5.0.0.tgz"
integrity sha512-Tbj67rffqceeLpcRXrT7vKAN8CwfPeIBgM7E6iBkmKLV7bEMwpGgYLGv0jACUsECaa/vuxP0IjEont6umdMgtQ==
dependencies:
abbrev "1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
normalize-path@^3.0.0, normalize-path@~3.0.0:
version "3.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==
nwsapi@^2.2.0:
version "2.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/nwsapi/-/nwsapi-2.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-h2AatdwYH+JHiZpv7pt/gSX1XoRGb7L/qSIeuqA6GwYoF9w1vP1cw42TO0aI2pNyshRK5893hNSl+1//vHK7hQ==
oauth-sign@~0.9.0:
version "0.9.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/oauth-sign/-/oauth-sign-0.9.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-fexhUFFPTGV8ybAtSIGbV6gOkSv8UtRbDBnAyLQw4QPKkgNlsH2ByPGtMUqdWkos6YCRmAqViwgZrJc/mRDzZQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
object-hash@^2.0.1:
version "2.2.0"
resolved "https://registry.npmjs.org/object-hash/-/object-hash-2.2.0.tgz"
integrity sha512-gScRMn0bS5fH+IuwyIFgnh9zBdo4DV+6GhygmWM9HyNJSgS0hScp1f5vjtm7oIIOiT9trXrShAkLFSc2IqKNgw==
object-inspect@^1.9.0:
version "1.12.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/object-inspect/-/object-inspect-1.12.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-z+cPxW0QGUp0mcqcsgQyLVRDoXFQbXOwBaqyF7VIgI4TWNQsDHrBpUQslRmIfAoYWdYzs6UlKJtB2XJpTaNSpQ==
on-finished@2.4.1:
version "2.4.1"
resolved "https://registry.npmjs.org/on-finished/-/on-finished-2.4.1.tgz"
integrity sha512-oVlzkg3ENAhCk2zdv7IJwd/QUD4z2RxRwpkcGY8psCVcCYZNq4wYnVWALHM+brtuJjePWiYF/ClmuDr8Ch5+kg==
dependencies:
ee-first "1.1.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
on-finished@~2.3.0:
version "2.3.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/on-finished/-/on-finished-2.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ikqdkGAAyf/X/gPhXGvfgAytDZtDbr+bkNUJ0N9h5MI/dmdgCs3l6hoHrcUv41sRKew3jIwrp4qQDXiK99Utww==
dependencies:
ee-first "1.1.1"
on-headers@~1.0.2:
version "1.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/on-headers/-/on-headers-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-pZAE+FJLoyITytdqK0U5s+FIpjN0JP3OzFi/u8Rx+EV5/W+JTWGXG8xFzevE7AjBfDqHv/8vL8qQsIhHnqRkrA==
once@^1.3.0:
version "1.4.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/once/-/once-1.4.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-lNaJgI+2Q5URQBkccEKHTQOPaXdUxnZZElQTZY0MFUAuaEqe1E+Nyvgdz/aIyNi6Z9MzO5dv1H8n58/GELp3+w==
dependencies:
wrappy "1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
one-time@^1.0.0:
version "1.0.0"
resolved "https://registry.npmjs.org/one-time/-/one-time-1.0.0.tgz"
integrity sha512-5DXOiRKwuSEcQ/l0kGCF6Q3jcADFv5tSmRaJck/OqkVFcOzutB134KRSfF0xDrL39MNnqxbHBbUUcjZIhTgb2g==
dependencies:
fn.name "1.x.x"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
optionator@^0.8.1:
version "0.8.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/optionator/-/optionator-0.8.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-+IW9pACdk3XWmmTXG8m3upGUJst5XRGzxMRjXzAuJ1XnIFNvfhjjIuYkDvysnPQ7qzqVzLt78BCruntqRhWQbA==
dependencies:
deep-is "~0.1.3"
fast-levenshtein "~2.0.6"
levn "~0.3.0"
prelude-ls "~1.1.2"
type-check "~0.3.2"
word-wrap "~1.2.3"
optionator@^0.9.1:
version "0.9.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/optionator/-/optionator-0.9.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-74RlY5FCnhq4jRxVUPKDaRwrVNXMqsGsiW6AJw4XK8hmtm10wC0ypZBLw5IIp85NZMr91+qd1RvvENwg7jjRFw==
dependencies:
deep-is "^0.1.3"
fast-levenshtein "^2.0.6"
levn "^0.4.1"
prelude-ls "^1.2.1"
type-check "^0.4.0"
word-wrap "^1.2.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
p-finally@^1.0.0:
version "1.0.0"
resolved "https://registry.npmjs.org/p-finally/-/p-finally-1.0.0.tgz"
integrity sha512-LICb2p9CB7FS+0eR1oqWnHhp0FljGLZCWBE9aix0Uye9W8LTQPwMTYVGWQWIw9RdQiDg4+epXQODwIYJtSJaow==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
p-limit@^3.0.2:
version "3.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/p-limit/-/p-limit-3.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-TYOanM3wGwNGsZN2cVTYPArw454xnXj5qmWF1bEoAc4+cU/ol7GVh7odevjp1FNHduHc3KZMcFduxU5Xc6uJRQ==
dependencies:
yocto-queue "^0.1.0"
p-locate@^5.0.0:
version "5.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/p-locate/-/p-locate-5.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-LaNjtRWUBY++zB5nE/NwcaoMylSPk+S+ZHNB1TzdbMJMny6dynpAGt7X/tl/QYq3TIeE6nxHppbo2LGymrG5Pw==
dependencies:
p-limit "^3.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
p-queue@^6.6.2:
version "6.6.2"
resolved "https://registry.npmjs.org/p-queue/-/p-queue-6.6.2.tgz"
integrity sha512-RwFpb72c/BhQLEXIZ5K2e+AhgNVmIejGlTgiB9MzZ0e93GRvqZ7uSi0dvRF7/XIXDeNkra2fNHBxTyPDGySpjQ==
dependencies:
eventemitter3 "^4.0.4"
p-timeout "^3.2.0"
p-timeout@^3.2.0:
version "3.2.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/p-timeout/-/p-timeout-3.2.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-rhIwUycgwwKcP9yTOOFK/AKsAopjjCakVqLHePO3CC6Mir1Z99xT+R63jZxAT5lFZLa2inS5h+ZS2GvR99/FBg==
dependencies:
p-finally "^1.0.0"
packet-reader@1.0.0:
version "1.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/packet-reader/-/packet-reader-1.0.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-HAKu/fG3HpHFO0AA8WE8q2g+gBJaZ9MG7fcKk+IJPLTGAD6Psw4443l+9DGRbOIh3/aXr7Phy0TjilYivJo5XQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
parent-module@^1.0.0:
version "1.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/parent-module/-/parent-module-1.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-GQ2EWRpQV8/o+Aw8YqtfZZPfNRWZYkbidE9k5rpl/hC3vtHHBfGm2Ifi6qWV+coDGkrUKZAxE3Lot5kcsRlh+g==
dependencies:
callsites "^3.0.0"
parse-duration@^1.0.2:
version "1.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/parse-duration/-/parse-duration-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Dg27N6mfok+ow1a2rj/nRjtCfaKrHUZV2SJpEn/s8GaVUSlf4GGRCRP1c13Hj+wfPKVMrFDqLMLITkYKgKxyyg==
parse-srcset@^1.0.2:
version "1.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/parse-srcset/-/parse-srcset-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-/2qh0lav6CmI15FzA3i/2Bzk2zCgQhGMkvhOhKNcBVQ1ldgpbfiNTVslmooUmWJcADi1f1kIeynbDRVzNlfR6Q==
parse5@6.0.1:
version "6.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/parse5/-/parse5-6.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Ofn/CTFzRGTTxwpNEs9PP93gXShHcTq255nzRYSKe8AkVpZY7e1fpmTfOyoIvjP5HG7Z2ZM7VS9PPhQGW2pOpw==
parseley@^0.7.0:
version "0.7.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/parseley/-/parseley-0.7.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-xyOytsdDu077M3/46Am+2cGXEKM9U9QclBDv7fimY7e+BBlxh2JcBp2mgNsmkyA9uvgyTjVzDi7cP1v4hcFxbw==
dependencies:
moo "^0.5.1"
nearley "^2.20.1"
parseurl@~1.3.3:
version "1.3.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/parseurl/-/parseurl-1.3.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-CiyeOxFT/JZyN5m0z9PfXw4SCBJ6Sygz1Dpl0wqjlhDEGGBP1GnsUVEL0p63hoG1fcj3fHynXi9NYO4nWOL+qQ==
path-exists@^4.0.0:
version "4.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==
path-is-absolute@^1.0.0:
version "1.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-AVbw3UJ2e9bq64vSaS9Am0fje1Pa8pbGqTTsmXfaIiMpnr5DlDhfJOuLj9Sf95ZPVDAUerDfEk88MPmPe7UCQg==
path-key@^3.1.0:
version "3.1.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==
path-parse@^1.0.6:
version "1.0.7"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/path-parse/-/path-parse-1.0.7.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==
path-to-regexp@0.1.7:
version "0.1.7"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-0.1.7.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-5DFkuoqlv1uYQKxy8omFBeJPQcdoE07Kv2sferDCrAq1ohOU+MSDswDIbnx3YAM60qIOnYa53wBhXW0EbMonrQ==
performance-now@^2.1.0:
version "2.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/performance-now/-/performance-now-2.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-7EAHlyLHI56VEIdK57uwHdHKIaAGbnXPiw0yWbarQZOKaKpvUIgW0jWRVLiatnM+XXlSwsanIBH/hzGMJulMow==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
pg-connection-string@^2.5.0:
version "2.5.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/pg-connection-string/-/pg-connection-string-2.5.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-r5o/V/ORTA6TmUnyWZR9nCj1klXCO2CEKNRlVuJptZe85QuhFayC7WeMic7ndayT5IRIR0S0xFxFi2ousartlQ==
pg-int8@1.0.1:
version "1.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/pg-int8/-/pg-int8-1.0.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-WCtabS6t3c8SkpDBUlb1kjOs7l66xsGdKpIPZsg4wR+B3+u9UAum2odSsF9tnvxg80h4ZxLWMy4pRjOsFIqQpw==
pg-pool@^3.5.2:
version "3.5.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/pg-pool/-/pg-pool-3.5.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-His3Fh17Z4eg7oANLob6ZvH8xIVen3phEZh2QuyrIl4dQSDVEabNducv6ysROKpDNPSD+12tONZVWfSgMvDD9w==
pg-protocol@*, pg-protocol@^1.5.0:
version "1.5.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/pg-protocol/-/pg-protocol-1.5.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-muRttij7H8TqRNu/DxrAJQITO4Ac7RmX3Klyr/9mJEOBeIpgnF8f9jAfRz5d3XwQZl5qBjF9gLsUtMPJE0vezQ==
pg-types@^2.1.0, pg-types@^2.2.0:
version "2.2.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/pg-types/-/pg-types-2.2.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-qTAAlrEsl8s4OiEQY69wDvcMIdQN6wdz5ojQiOy6YRMuynxenON0O5oCpJI6lshc6scgAY8qvJ2On/p+CXY0GA==
dependencies:
pg-int8 "1.0.1"
postgres-array "~2.0.0"
postgres-bytea "~1.0.0"
postgres-date "~1.0.4"
postgres-interval "^1.1.0"
pg@^8.8.0:
version "8.8.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/pg/-/pg-8.8.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-UXYN0ziKj+AeNNP7VDMwrehpACThH7LUl/p8TDFpEUuSejCUIwGSfxpHsPvtM6/WXFy6SU4E5RG4IJV/TZAGjw==
dependencies:
buffer-writer "2.0.0"
packet-reader "1.0.0"
pg-connection-string "^2.5.0"
pg-pool "^3.5.2"
pg-protocol "^1.5.0"
pg-types "^2.1.0"
pgpass "1.x"
pgpass@1.x:
version "1.0.5"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/pgpass/-/pgpass-1.0.5.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-FdW9r/jQZhSeohs1Z3sI1yxFQNFvMcnmfuj4WBMUTxOrAyLMaTcE1aAMBiTlbMNaXvBCQuVi0R7hd8udDSP7ug==
dependencies:
split2 "^4.1.0"
picocolors@^1.0.0:
version "1.0.0"
resolved "https://registry.npmjs.org/picocolors/-/picocolors-1.0.0.tgz"
integrity sha512-1fygroTLlHu66zi26VoTDv8yRgm0Fccecssto+MhsZ0D/DGW2sm8E8AjW7NU5VVTRt5GxbeZ5qBuJr+HyLYkjQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
picomatch@^2.0.4, picomatch@^2.2.1, picomatch@^2.2.3:
version "2.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/picomatch/-/picomatch-2.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-lY1Q/PiJGC2zOv/z391WOTD+Z02bCgsFfvxoXXf6h7kv9o+WmsmzYqrAwY63sNgOxE4xEdq0WyUnXfKeBrSvYw==
pify@^3.0.0:
version "3.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/pify/-/pify-3.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-C3FsVNH1udSEX48gGX1xfvwTWfsYWj5U+8/uK15BGzIGrKoUpghX8hWZwa/OFnakBiiVNmBvemTJR5mcy7iPcg==
pkginfo@^0.4.1:
version "0.4.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/pkginfo/-/pkginfo-0.4.1.tgz"
integrity sha512-8xCNE/aT/EXKenuMDZ+xTVwkT8gsoHN2z/Q29l80u0ppGEXVvsKRzNMbtKhg8LS8k1tJLAHHylf6p4VFmP6XUQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
postcss@^8.3.11:
version "8.4.16"
resolved "https://registry.npmjs.org/postcss/-/postcss-8.4.16.tgz"
integrity sha512-ipHE1XBvKzm5xI7hiHCZJCSugxvsdq2mPnsq5+UF+VHCjiBvtDrlxJfMBToWaP9D5XlgNmcFGqoHmUn0EYEaRQ==
dependencies:
nanoid "^3.3.4"
picocolors "^1.0.0"
source-map-js "^1.0.2"
postgres-array@~2.0.0:
version "2.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/postgres-array/-/postgres-array-2.0.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-VpZrUqU5A69eQyW2c5CA1jtLecCsN2U/bD6VilrFDWq5+5UIEVO7nazS3TEcHf1zuPYO/sqGvUvW62g86RXZuA==
postgres-bytea@~1.0.0:
version "1.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/postgres-bytea/-/postgres-bytea-1.0.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-xy3pmLuQqRBZBXDULy7KbaitYqLcmxigw14Q5sj8QBVLqEwXfeybIKVWiqAXTlcvdvb0+xkOtDbfQMOf4lST1w==
postgres-date@~1.0.4:
version "1.0.7"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/postgres-date/-/postgres-date-1.0.7.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-suDmjLVQg78nMK2UZ454hAG+OAW+HQPZ6n++TNDUX+L0+uUlLywnoxJKDou51Zm+zTCjrCl0Nq6J9C5hP9vK/Q==
postgres-interval@^1.1.0:
version "1.2.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/postgres-interval/-/postgres-interval-1.2.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-9ZhXKM/rw350N1ovuWHbGxnGh/SNJ4cnxHiM0rxE4VN41wsg8P8zWn9hv/buK00RP4WvlOyr/RBDiptyxVbkZQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
xtend "^4.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
postgres@^3.3.1:
version "3.3.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/postgres/-/postgres-3.3.2.tgz"
integrity sha512-NaPqFpUC6C7aCQkJXLvuO/3RKNKL4en8opY53YrcXK3//xXra6CZ2qX6290lxuQ1dW1LbRGYCmsawRlCxSBonQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
prelude-ls@^1.2.1:
version "1.2.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/prelude-ls/-/prelude-ls-1.2.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-vkcDPrRZo1QZLbn5RLGPpg/WmIQ65qoWWhcGKf/b5eplkkarX0m9z8ppCat4mlOqUsWpyNuYgO3VRyrYHSzX5g==
prelude-ls@~1.1.2:
version "1.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/prelude-ls/-/prelude-ls-1.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ESF23V4SKG6lVSGZgYNpbsiaAkdab6ZgOxe52p7+Kid3W3u3bxR4Vfd/o21dmN7jSt0IwgZ4v5MUd26FEtXE9w==
pretty-format@^27.2.4:
version "27.2.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/pretty-format/-/pretty-format-27.2.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-NUjw22WJHldzxyps2YjLZkUj6q1HvjqFezkB9Y2cklN8NtVZN/kZEXGZdFw4uny3oENzV5EEMESrkI0YDUH8vg==
dependencies:
"@jest/types" "^27.2.4"
ansi-regex "^5.0.1"
ansi-styles "^5.0.0"
react-is "^17.0.1"
progress@^2.0.0:
version "2.0.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/progress/-/progress-2.0.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-7PiHtLll5LdnKIMw100I+8xJXR5gW2QwWYkT6iJva0bXitZKa/XMrSbdmg3r2Xnaidz9Qumd0VPaMrZlF9V9sA==
prom-client@^14.1.0:
version "14.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/prom-client/-/prom-client-14.1.0.tgz"
integrity sha512-iFWCchQmi4170omLpFXbzz62SQTmPhtBL35v0qGEVRHKcqIeiexaoYeP0vfZTujxEq3tA87iqOdRbC9svS1B9A==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
dependencies:
tdigest "^0.1.1"
proxy-addr@~2.0.7:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "2.0.7"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.7.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-llQsMLSUDUPT44jdrU/O37qlnifitDP+ZwrmmZcoSKyLKvtZxpyV0n2/bD/N4tBAAZ/gJEdZU7KMraoK1+XYAg==
dependencies:
forwarded "0.2.0"
ipaddr.js "1.9.1"
pseudomap@^1.0.2:
version "1.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/pseudomap/-/pseudomap-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-b/YwNhb8lk1Zz2+bXXpS/LK9OisiZZ1SNsSLxN1x2OXVEhW2Ckr/7mWE5vrC1ZTiJlD9g19jWszTmJsB+oEpFQ==
2023-04-03 20:03:02 +00:00
psl@^1.1.28, psl@^1.1.33:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.8.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/psl/-/psl-1.8.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-RIdOzyoavK+hA18OGGWDqUTsCLhtA7IcZ/6NCs4fFJaHBDab+pDDmDIByWFRQJq2Cd7r1OoQxBGKOaztq+hjIQ==
punycode@^2.1.0, punycode@^2.1.1:
version "2.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/punycode/-/punycode-2.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-XRsRjdf+j5ml+y/6GKHPZbrF/8p2Yga0JPtdqTIY2Xe5ohJPD9saDJJLPvp9+NSBprVvevdXZybnj2cv8OEd0A==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
qs@6.10.3:
version "6.10.3"
resolved "https://registry.npmjs.org/qs/-/qs-6.10.3.tgz"
integrity sha512-wr7M2E0OFRfIfJZjKGieI8lBKb7fRCH4Fv5KNPEs7gJ8jadvotdsS08PzOKR7opXhZ/Xkjtt3WF9g38drmyRqQ==
dependencies:
side-channel "^1.0.4"
qs@6.11.0:
version "6.11.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/qs/-/qs-6.11.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-MvjoMCJwEarSbUYk5O+nmoSzSutSsTwF85zcHPQ9OrlFoZOYIjaqBAJIqIXjptyD5vThxGq52Xu/MaJzRkIk4Q==
dependencies:
side-channel "^1.0.4"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
qs@~6.5.2:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "6.5.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/qs/-/qs-6.5.3.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-qxXIEh4pCGfHICj1mAJQ2/2XVZkjCDTcEgfoSQxc/fYivUZxTkk7L3bDBJSoNrEzXI17oUO5Dp07ktqE5KzczA==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
railroad-diagrams@^1.0.0:
version "1.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/railroad-diagrams/-/railroad-diagrams-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-cz93DjNeLY0idrCNOH6PviZGRN9GJhsdm9hpn1YCS879fj4W+x5IFJhhkRZcwVgMmFF7R82UA/7Oh+R8lLZg6A==
randexp@0.4.6:
version "0.4.6"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/randexp/-/randexp-0.4.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-80WNmd9DA0tmZrw9qQa62GPPWfuXJknrmVmLcxvq4uZBdYqb1wYoKTmnlGUchvVWe0XiLupYkBoXVOxz3C8DYQ==
dependencies:
discontinuous-range "1.0.0"
ret "~0.1.10"
randombytes@^2.1.0:
version "2.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/randombytes/-/randombytes-2.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-vYl3iOX+4CKUWuxGi9Ukhie6fsqXqS9FE2Zaic4tNFD2N2QQaXOMFbuKK4QmDHC0JO6B1Zp41J0LpT0oR68amQ==
dependencies:
safe-buffer "^5.1.0"
range-parser@~1.2.1:
version "1.2.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/range-parser/-/range-parser-1.2.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Hrgsx+orqoygnmhFbKaHE6c296J+HTAQXoxEF6gNupROmmGJRoyzfG3ccAveqCBrwr/2yxQ5BVd/GTl5agOwSg==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
raw-body@2.5.1:
version "2.5.1"
resolved "https://registry.npmjs.org/raw-body/-/raw-body-2.5.1.tgz"
integrity sha512-qqJBtEyVgS0ZmPGdCFPWJ3FreoqvG4MVQln/kCgF7Olq95IbOp0/BWyMwbdtn4VTvkM8Y7khCQ2Xgk/tcrCXig==
dependencies:
bytes "3.1.2"
http-errors "2.0.0"
iconv-lite "0.4.24"
unpipe "1.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
react-is@^17.0.1:
version "17.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/react-is/-/react-is-17.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-w2GsyukL62IJnlaff/nRegPQR94C/XXamvMWmSHRJ4y7Ts/4ocGRmTHvOs8PSE6pB3dWOrD/nueuU5sduBsQ4w==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
readable-stream@^3.4.0, readable-stream@^3.6.0:
version "3.6.0"
resolved "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.0.tgz"
integrity sha512-BViHy7LKeTz4oNnkcLJ+lVSL6vpiFeX6/d3oSH8zCW7UxP2onchk+vTGB143xuFjHS3deTgkKoXXymXqymiIdA==
dependencies:
inherits "^2.0.3"
string_decoder "^1.1.1"
util-deprecate "^1.0.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
readdirp@~3.6.0:
version "3.6.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/readdirp/-/readdirp-3.6.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==
dependencies:
picomatch "^2.2.1"
regexpp@^3.1.0:
version "3.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/regexpp/-/regexpp-3.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-pq2bWo9mVD43nbts2wGv17XLiNLya+GklZ8kaDLV2Z08gDCsGpnKn9BFMepvWuHCbyVvY7J5o5+BVvoQbmlJLg==
request-promise-core@1.1.4:
version "1.1.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/request-promise-core/-/request-promise-core-1.1.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-TTbAfBBRdWD7aNNOoVOBH4pN/KigV6LyapYNNlAPA8JwbovRti1E88m3sYAwsLi5ryhPKsE9APwnjFTgdUjTpw==
dependencies:
lodash "^4.17.19"
request-promise@^4.2.6:
version "4.2.6"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/request-promise/-/request-promise-4.2.6.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-HCHI3DJJUakkOr8fNoCc73E5nU5bqITjOYFMDrKHYOXWXrgD/SBaC7LjwuPymUprRyuF06UK7hd/lMHkmUXglQ==
dependencies:
bluebird "^3.5.0"
request-promise-core "1.1.4"
stealthy-require "^1.1.1"
tough-cookie "^2.3.3"
request@^2.88.2:
version "2.88.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/request/-/request-2.88.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-MsvtOrfG9ZcrOwAW+Qi+F6HbD0CWXEh9ou77uOb7FM2WPhwT7smM833PzanhJLsgXjN89Ir6V2PczXNnMpwKhw==
dependencies:
aws-sign2 "~0.7.0"
aws4 "^1.8.0"
caseless "~0.12.0"
combined-stream "~1.0.6"
extend "~3.0.2"
forever-agent "~0.6.1"
form-data "~2.3.2"
har-validator "~5.1.3"
http-signature "~1.2.0"
is-typedarray "~1.0.0"
isstream "~0.1.2"
json-stringify-safe "~5.0.1"
mime-types "~2.1.19"
oauth-sign "~0.9.0"
performance-now "^2.1.0"
qs "~6.5.2"
safe-buffer "^5.1.2"
tough-cookie "~2.5.0"
tunnel-agent "^0.6.0"
uuid "^3.3.2"
require-directory@^2.1.1:
version "2.1.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/require-directory/-/require-directory-2.1.1.tgz"
integrity "sha1-jGStX9MNqxyXbiNE/+f3kqam30I= sha512-fGxEI7+wsG9xrvdjsrlmL22OMTTiHRwAMroiEeMgq8gzoLC/PQr7RsRDSTLUg/bZAZtF+TVIkHc6/4RIKrui+Q=="
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
require-from-string@^2.0.2:
version "2.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/require-from-string/-/require-from-string-2.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Xf0nWe6RseziFMu+Ap9biiUbmplq6S9/p+7w7YXP/JBHhrUDDUhwa+vANyubuqfZWTveU//DYVGsDG7RKL/vEw==
resolve-from@^4.0.0:
version "4.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/resolve-from/-/resolve-from-4.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-pb/MYmXstAkysRFx8piNI1tGFNQIFA3vkE3Gq4EuA1dF6gHp/+vgZqsCGJapvy8N3Q+4o7FwvquPJcnZ7RYy4g==
resolve@^1.3.2:
version "1.20.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/resolve/-/resolve-1.20.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-wENBPt4ySzg4ybFQW2TT1zMQucPK95HSh/nq2CFTZVOGut2+pQvSsgtda4d26YrYcr067wjbmzOG8byDPBX63A==
dependencies:
is-core-module "^2.2.0"
path-parse "^1.0.6"
ret@~0.1.10:
version "0.1.15"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ret/-/ret-0.1.15.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-TTlYpa+OL+vMMNG24xSlQGEJ3B/RzEfUlLct7b5G/ytav+wPrplCpVMFuwzXbkecJrb6IYo1iFb0S9v37754mg==
rimraf@^3.0.2:
version "3.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/rimraf/-/rimraf-3.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-JZkJMZkAGFFPP2YqXZXPbMlMBgsxzE8ILs4lMIX/2o0L9UBw9O/Y3o6wFw/i9YLapcUJWwqbi3kdxIPdC62TIA==
dependencies:
glob "^7.1.3"
safe-buffer@5.1.2:
version "5.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
safe-buffer@5.2.1, safe-buffer@^5.0.1, safe-buffer@^5.1.0, safe-buffer@^5.1.2, safe-buffer@~5.2.0:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "5.2.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
safe-stable-stringify@^2.3.1:
version "2.3.1"
resolved "https://registry.npmjs.org/safe-stable-stringify/-/safe-stable-stringify-2.3.1.tgz"
integrity sha512-kYBSfT+troD9cDA85VDnHZ1rpHC50O0g1e6WlGHVCz/g+JS+9WKLj+XwFYyR8UbrZN8ll9HUpDAAddY58MGisg==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
"safer-buffer@>= 2.1.2 < 3", safer-buffer@^2.0.2, safer-buffer@^2.1.0, safer-buffer@~2.1.0:
version "2.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
sanitize-html@^2.7.0:
version "2.7.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/sanitize-html/-/sanitize-html-2.7.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-oOpe8l4J8CaBk++2haoN5yNI5beekjuHv3JRPKUx/7h40Rdr85pemn4NkvUB3TcBP7yjat574sPlcMAyv4UQig==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
deepmerge "^4.2.2"
escape-string-regexp "^4.0.0"
htmlparser2 "^6.0.0"
is-plain-object "^5.0.0"
parse-srcset "^1.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
postcss "^8.3.11"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
saxes@^5.0.1:
version "5.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/saxes/-/saxes-5.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-5LBh1Tls8c9xgGjw3QrMwETmTMVk0oFgvrFSvWx62llR2hcEInrKNZ2GZCCuuy2lvWrdl5jhbpeqc5hRYKFOcw==
dependencies:
xmlchars "^2.2.0"
selderee@^0.6.0:
version "0.6.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/selderee/-/selderee-0.6.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ibqWGV5aChDvfVdqNYuaJP/HnVBhlRGSRrlbttmlMpHcLuTqqbMH36QkSs9GEgj5M88JDYLI8eyP94JaQ8xRlg==
dependencies:
parseley "^0.7.0"
semver@^5.3.0, semver@^5.6.0:
version "5.7.2"
resolved "https://registry.yarnpkg.com/semver/-/semver-5.7.2.tgz#48d55db737c3287cd4835e17fa13feace1c41ef8"
integrity sha512-cBznnQ9KjJqU67B52RMC65CMarK2600WFnbkcaiwWq3xy/5haFJlshgnpjovMVJ+Hff49d8GEn0b87C5pDQ10g==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
semver@^7.2.1:
version "7.5.4"
resolved "https://registry.yarnpkg.com/semver/-/semver-7.5.4.tgz#483986ec4ed38e1c6c48c34894a9182dbff68a6e"
integrity sha512-1bCSESV6Pv+i21Hvpxp3Dx+pSD8lIPt8uVjRrxAUt/nbswYc+tK6Y2btiULjd4+fnq15PX+nqQDC7Oft7WkwcA==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
lru-cache "^6.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
send@0.18.0:
version "0.18.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/send/-/send-0.18.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-qqWzuOjSFOuqPjFe4NOsMLafToQQwBSOEpS+FwEt3A2V3vKubTquT3vmLTQpFgMXp8AlFWFuP1qKaJZOtPpVXg==
dependencies:
debug "2.6.9"
depd "2.0.0"
destroy "1.2.0"
encodeurl "~1.0.2"
escape-html "~1.0.3"
etag "~1.8.1"
fresh "0.5.2"
http-errors "2.0.0"
mime "1.6.0"
ms "2.1.3"
on-finished "2.4.1"
range-parser "~1.2.1"
statuses "2.0.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
serialize-javascript@6.0.0:
version "6.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/serialize-javascript/-/serialize-javascript-6.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Qr3TosvguFt8ePWqsvRfrKyQXIiW+nGbYpy8XK24NQHE83caxWt+mIymTT19DGFbNWNLfEwsrkSmN64lVWB9ag==
dependencies:
randombytes "^2.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
serve-static@1.15.0:
version "1.15.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/serve-static/-/serve-static-1.15.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-XGuRDNjXUijsUL0vl6nSD7cwURuzEgglbOaFuZM9g3kwDXOWVTck0jLzjPzGD+TazWbboZYu52/9/XPdUgne9g==
dependencies:
encodeurl "~1.0.2"
escape-html "~1.0.3"
parseurl "~1.3.3"
send "0.18.0"
setprototypeof@1.2.0:
version "1.2.0"
resolved "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.2.0.tgz"
integrity sha512-E5LDX7Wrp85Kil5bhZv46j8jOeboKq5JMmYM3gVGdGH8xFpPWXUMsNrlODCrkoxMEeNi/XZIwuRvY4XNwYMJpw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
shebang-command@^2.0.0:
version "2.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==
dependencies:
shebang-regex "^3.0.0"
shebang-regex@^3.0.0:
version "3.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==
shell-quote@^1.7.3:
version "1.7.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/shell-quote/-/shell-quote-1.7.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Vpfqwm4EnqGdlsBFNmHhxhElJYrdfcxPThu+ryKS5J8L/fhAwLazFZtq+S+TWZ9ANj2piSQLGj6NQg+lKPmxrw==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
side-channel@^1.0.4:
version "1.0.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/side-channel/-/side-channel-1.0.4.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-q5XPytqFEIKHkGdiMIrY10mvLRvnQh42/+GoBlFW3b2LXLE2xxJpZFdm94we0BaoV3RwJyGqg5wS7epxTv0Zvw==
dependencies:
call-bind "^1.0.0"
get-intrinsic "^1.0.2"
object-inspect "^1.9.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
sigmund@^1.0.1:
version "1.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/sigmund/-/sigmund-1.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-fCvEXfh6NWpm+YSuY2bpXb/VIihqWA6hLsgboC+0nl71Q7N7o2eaCW8mJa/NLvQhs6jpd3VZV4UiUQlV6+lc8g==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
simple-swizzle@^0.2.2:
version "0.2.2"
resolved "https://registry.npmjs.org/simple-swizzle/-/simple-swizzle-0.2.2.tgz"
integrity sha512-JA//kQgZtbuY83m+xT+tXJkmJncGMTFT+C+g2h2R9uxkYIrE2yy9sgmcLhCnw57/WSD+Eh3J97FPEDFnbXnDUg==
dependencies:
is-arrayish "^0.3.1"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
slash@^3.0.0:
version "3.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/slash/-/slash-3.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-g9Q1haeby36OSStwb4ntCGGGaKsaVSjQ68fBxoQcutl5fS1vuY18H3wSt3jFyFtrkx+Kz0V1G85A4MyAdDMi2Q==
slice-ansi@^4.0.0:
version "4.0.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/slice-ansi/-/slice-ansi-4.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-qMCMfhY040cVHT43K9BFygqYbUPFZKHOg7K73mtTWJRb8pyP3fzf4Ixd5SzdEJQ6MRUg/WBnOLxghZtKKurENQ==
dependencies:
ansi-styles "^4.0.0"
astral-regex "^2.0.0"
is-fullwidth-code-point "^3.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
source-map-js@^1.0.2:
version "1.0.2"
resolved "https://registry.npmjs.org/source-map-js/-/source-map-js-1.0.2.tgz"
integrity sha512-R0XvVJ9WusLiqTCEiGCmICCMplcCkIwwR11mOSD9CR5u+IXYdiseeEuXCVAjS54zqwkLcPNnmU4OeJ6tUrWhDw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
source-map-support@^0.5.6:
version "0.5.20"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/source-map-support/-/source-map-support-0.5.20.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-n1lZZ8Ve4ksRqizaBQgxXDgKwttHDhyfQjA6YZZn8+AroHbsIz+JjwxQDxbp+7y5OYCI8t1Yk7etjD9CRd2hIw==
dependencies:
buffer-from "^1.0.0"
source-map "^0.6.0"
source-map@^0.6.0, source-map@~0.6.1:
version "0.6.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/source-map/-/source-map-0.6.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
split2@^4.1.0:
version "4.1.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/split2/-/split2-4.1.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-VBiJxFkxiXRlUIeyMQi8s4hgvKCSjtknJv/LVYbrgALPwf5zSKmEwV9Lst25AkvMDnvxODugjdl6KZgwKM1WYQ==
sprintf-js@1.1.2:
version "1.1.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.1.2.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-VE0SOVEHCk7Qc8ulkWw3ntAzXuqf7S2lvwQaDLRnUeIEaKNQJzV6BwmLKhOqT61aGhfUMrXeaBk+oDGCzvhcug==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
sprintf-js@~1.0.2:
version "1.0.3"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.0.3.tgz"
integrity "sha1-BOaSb2YolTVPPdAVIDYzuFcpfiw= sha512-D9cPgkvLlV3t3IzL0D0YLvGA9Ahk4PcvVwUbN0dSGr1aP0Nrt4AEnTUbuGvquEC0mA64Gqt1fzirlRs5ibXx8g=="
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
sshpk@^1.7.0:
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
version "1.17.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/sshpk/-/sshpk-1.17.0.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-/9HIEs1ZXGhSPE8X6Ccm7Nam1z8KcoCqPdI7ecm1N33EzAetWahvQWVqLZtaZQ+IDKX4IyA2o0gBzqIMkAagHQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
dependencies:
asn1 "~0.2.3"
assert-plus "^1.0.0"
bcrypt-pbkdf "^1.0.0"
dashdash "^1.12.0"
ecc-jsbn "~0.1.1"
getpass "^0.1.1"
jsbn "~0.1.0"
safer-buffer "^2.0.2"
tweetnacl "~0.14.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
stack-trace@0.0.x:
version "0.0.10"
resolved "https://registry.npmjs.org/stack-trace/-/stack-trace-0.0.10.tgz"
integrity sha512-KGzahc7puUKkzyMt+IqAep+TVNbKP+k2Lmwhub39m1AsTSkaDutx56aDCo+HLDzf/D26BIHTJWNiTG1KAJiQCg==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
stack-utils@^2.0.3:
version "2.0.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/stack-utils/-/stack-utils-2.0.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-xrQcmYhOsn/1kX+Vraq+7j4oE2j/6BFscZ0etmYg81xuM8Gq0022Pxb8+IqgOFUIaxHs0KaSb7T1+OegiNrNFA==
dependencies:
escape-string-regexp "^2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
statuses@2.0.1:
version "2.0.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/statuses/-/statuses-2.0.1.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-RwNA9Z/7PrK06rYLIzFMlaF+l73iwpzsqRIFgbMLbTcLD6cOao82TaWefPXQvB2fOC4AjuYSEndS7N/mTCbkdQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
stealthy-require@^1.1.1:
version "1.1.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/stealthy-require/-/stealthy-require-1.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ZnWpYnYugiOVEY5GkcuJK1io5V8QmNYChG62gSit9pQVGErXtrKuPC55ITaVSukmMta5qpMU7vqLt2Lnni4f/g==
steno@^0.4.1:
version "0.4.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/steno/-/steno-0.4.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-EEHMVYHNXFHfGtgjNITnka0aHhiAlo93F7z2/Pwd+g0teG9CnM3JIINM7hVVB5/rhw9voufD7Wukwgtw2uqh6w==
dependencies:
graceful-fs "^4.1.3"
string-width@^4.1.0, string-width@^4.2.0:
version "4.2.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==
dependencies:
emoji-regex "^8.0.0"
is-fullwidth-code-point "^3.0.0"
strip-ansi "^6.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
string_decoder@^1.1.1:
version "1.3.0"
resolved "https://registry.npmjs.org/string_decoder/-/string_decoder-1.3.0.tgz"
integrity sha512-hkRX8U1WjJFd8LsDJ2yQ/wWWxaopEsABU1XfkM8A+j0+85JAGppt16cr1Whg6KIbb4okU6Mql6BOj+uup/wKeA==
dependencies:
safe-buffer "~5.2.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
strip-ansi@^6.0.0, strip-ansi@^6.0.1:
version "6.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==
dependencies:
ansi-regex "^5.0.1"
strip-bom@^3.0.0:
version "3.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/strip-bom/-/strip-bom-3.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-vavAMRXOgBVNF6nyEEmL3DBK19iRpDcoIwW+swQ+CbGiu7lju6t+JklA1MHweoWtadgt4ISVUsXLyDq34ddcwA==
strip-json-comments@3.1.1, strip-json-comments@^3.1.0, strip-json-comments@^3.1.1:
version "3.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-3.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-6fPc+R4ihwqP6N/aIv2f1gMH8lOVtWQHoqC4yK6oSDVVocumAsfCqjkXnqiYMhmMwS/mEHLp7Vehlt3ql6lEig==
supports-color@8.1.1:
version "8.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/supports-color/-/supports-color-8.1.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-MpUEN2OodtUzxvKQl72cUF7RQ5EiHsGvSsVG0ia9c5RbWGL2CI4C7EpPS8UTBIplnlzZiNuV56w+FuNxy3ty2Q==
dependencies:
has-flag "^4.0.0"
supports-color@^5.3.0:
version "5.5.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/supports-color/-/supports-color-5.5.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==
dependencies:
has-flag "^3.0.0"
supports-color@^7.1.0:
version "7.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==
dependencies:
has-flag "^4.0.0"
symbol-tree@^3.2.4:
version "3.2.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/symbol-tree/-/symbol-tree-3.2.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-9QNk5KwDF+Bvz+PyObkmSYjI5ksVUYtjW7AU22r2NKcfLJcXp96hkDWU3+XndOsUb+AQ9QhfzfCT2O+CNWT5Tw==
table@^6.0.9:
version "6.7.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/table/-/table-6.7.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ZGum47Yi6KOOFDE8m223td53ath2enHcYLgOCjGr5ngu8bdIARQk6mN/wRMv4yMRcHnCSnHbCEha4sobQx5yWg==
dependencies:
ajv "^8.0.1"
lodash.clonedeep "^4.5.0"
lodash.truncate "^4.4.2"
slice-ansi "^4.0.0"
string-width "^4.2.0"
strip-ansi "^6.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
tdigest@^0.1.1:
version "0.1.2"
resolved "https://registry.npmjs.org/tdigest/-/tdigest-0.1.2.tgz"
integrity sha512-+G0LLgjjo9BZX2MfdvPfH+MKLCrxlXSYec5DaPYP1fe6Iyhf0/fSmJ0bFiZ1F8BT6cGXl2LpltQptzjXKWEkKA==
dependencies:
bintrees "1.0.2"
text-hex@1.0.x:
version "1.0.0"
resolved "https://registry.npmjs.org/text-hex/-/text-hex-1.0.0.tgz"
integrity sha512-uuVGNWzgJ4yhRaNSiubPY7OjISw4sw4E5Uv0wbjp+OzcbmVU/rsT8ujgcXJhn9ypzsgr5vlzpPqP+MBBKcGvbg==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
text-table@^0.2.0:
version "0.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/text-table/-/text-table-0.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-N+8UisAXDGk8PFXP4HAzVR9nbfmVJ3zYLAWiTIoqC5v5isinhr+r5uaO8+7r3BMfuNIufIsA7RdpVgacC2cSpw==
to-regex-range@^5.0.1:
version "5.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==
dependencies:
is-number "^7.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
toidentifier@1.0.1:
version "1.0.1"
resolved "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.1.tgz"
integrity sha512-o5sSPKEkg/DIQNmH43V0/uerLrpzVedkUh8tGNvaeXpfpuwjKenlSox/2O/BTlZUtEe+JG7s5YhEz608PlAHRA==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
tough-cookie@^2.3.3, tough-cookie@~2.5.0:
version "2.5.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/tough-cookie/-/tough-cookie-2.5.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-nlLsUzgm1kfLXSXfRZMc1KLAugd4hqJHDTvc2hDIwS3mZAfMEuMbc03SujMF+GEcpaX/qboeycw6iO8JwVv2+g==
dependencies:
psl "^1.1.28"
punycode "^2.1.1"
tough-cookie@^4.0.0:
version "4.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/tough-cookie/-/tough-cookie-4.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-tHdtEpQCMrc1YLrMaqXXcj6AxhYi/xgit6mZu1+EDWUn+qhUf8wMQoFIy9NXuq23zAwtcB0t/MjACGR18pcRbg==
dependencies:
psl "^1.1.33"
punycode "^2.1.1"
universalify "^0.1.2"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
tr46@^2.1.0:
version "2.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/tr46/-/tr46-2.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-15Ih7phfcdP5YxqiB+iDtLoaTz4Nd35+IiAv0kQ5FNKHzXgdWqPoTIqEDDJmXceQt4JZk6lVPT8lnDlPpGDppw==
dependencies:
punycode "^2.1.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
triple-beam@^1.3.0:
version "1.3.0"
resolved "https://registry.npmjs.org/triple-beam/-/triple-beam-1.3.0.tgz"
integrity sha512-XrHUvV5HpdLmIj4uVMxHggLbFSZYIn7HEWsqePZcI50pco+MPqJ50wMGY794X7AOOhxOBAjbkqfAbEe/QMp2Lw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
ts-mocha@^9.0.2:
version "9.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ts-mocha/-/ts-mocha-9.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-WyQjvnzwrrubl0JT7EC1yWmNpcsU3fOuBFfdps30zbmFBgKniSaSOyZMZx+Wq7kytUs5CY+pEbSYEbGfIKnXTw==
dependencies:
ts-node "7.0.1"
optionalDependencies:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
tsconfig-paths "^3.5.0"
ts-node@7.0.1:
version "7.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ts-node/-/ts-node-7.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-BVwVbPJRspzNh2yfslyT1PSbl5uIk03EZlb493RKHN4qej/D06n1cEhjlOJG69oFsE7OT8XjpTUcYf6pKTLMhw==
dependencies:
arrify "^1.0.0"
buffer-from "^1.1.0"
diff "^3.1.0"
make-error "^1.1.1"
minimist "^1.2.0"
mkdirp "^0.5.1"
source-map-support "^0.5.6"
yn "^2.0.0"
tsconfig-paths@^3.5.0:
version "3.11.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/tsconfig-paths/-/tsconfig-paths-3.11.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-7ecdYDnIdmv639mmDwslG6KQg1Z9STTz1j7Gcz0xa+nshh/gKDAHcPxRbWOsA3SPp0tXP2leTcY9Kw+NAkfZzA==
dependencies:
"@types/json5" "^0.0.29"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
json5 "^1.0.1"
minimist "^1.2.0"
strip-bom "^3.0.0"
tslib@^1.13.0, tslib@^1.8.1, tslib@^1.9.3:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.14.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/tslib/-/tslib-1.14.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Xni35NKzjgMrwevysHTCArtLDpPvye8zV/0E4EyYn43P7/7qvQwPh9BGkHewbMulVntbigmcT7rdX3BNo9wRJg==
2020-04-14 22:17:05 +00:00
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
tslint@^6.1.3:
version "6.1.3"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/tslint/-/tslint-6.1.3.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-IbR4nkT96EQOvKE2PW/djGz8iGNeJ4rF2mBfiYaR/nvUWYKJhLwimoJKgjIFEIDibBtOevj7BqCRL4oHeWWUCg==
2019-09-26 02:13:20 +00:00
dependencies:
"@babel/code-frame" "^7.0.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
builtin-modules "^1.1.1"
chalk "^2.3.0"
commander "^2.12.1"
diff "^4.0.1"
glob "^7.1.1"
js-yaml "^3.13.1"
minimatch "^3.0.4"
mkdirp "^0.5.3"
resolve "^1.3.2"
semver "^5.3.0"
tslib "^1.13.0"
tsutils "^2.29.0"
tsutils@^2.29.0:
version "2.29.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/tsutils/-/tsutils-2.29.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-g5JVHCIJwzfISaXpXE1qvNalca5Jwob6FjI4AoPlqMusJ6ftFE7IkkFoMhVLRgK+4Kx3gkzb8UZK5t5yTTvEmA==
dependencies:
tslib "^1.8.1"
tunnel-agent@^0.6.0:
version "0.6.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/tunnel-agent/-/tunnel-agent-0.6.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-McnNiV1l8RYeY8tBgEpuodCC1mLUdbSN+CYBL7kJsJNInOP8UjDDEwdk6Mw60vdLLrr5NHKZhMAOSrR2NZuQ+w==
dependencies:
safe-buffer "^5.0.1"
tweetnacl@^0.14.3, tweetnacl@~0.14.0:
version "0.14.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/tweetnacl/-/tweetnacl-0.14.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-KXXFFdAbFXY4geFIwoyNK+f5Z1b7swfXABfL7HXCmoIWMKU3dmS26672A4EeQtDzLKy7SXmfBu51JolvEKwtGA==
type-check@^0.4.0, type-check@~0.4.0:
version "0.4.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/type-check/-/type-check-0.4.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-XleUoc9uwGXqjWwXaUTZAmzMcFZ5858QA2vvx1Ur5xIcixXIP+8LnFDgRplU30us6teqdlskFfu+ae4K79Ooew==
dependencies:
prelude-ls "^1.2.1"
type-check@~0.3.2:
version "0.3.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/type-check/-/type-check-0.3.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ZCmOJdvOWDBYJlzAoFkC+Q0+bUyEOS1ltgp1MGU03fqHG+dbi9tBFU2Rd9QKiDZFAYrhPh2JUf7rZRIuHRKtOg==
dependencies:
prelude-ls "~1.1.2"
type-fest@^0.20.2:
version "0.20.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/type-fest/-/type-fest-0.20.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Ne+eE4r0/iWnpAxD852z3A+N0Bt5RN//NjJwRd2VFHEmrywxf5vsZlh4R6lixl6B+wz/8d+maTSAkN1FIkI3LQ==
type-is@~1.6.18:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "1.6.18"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/type-is/-/type-is-1.6.18.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-TkRKr9sUTxEH8MdfuCSP7VizJyzRNMjj2J2do2Jr3Kym598JVdEksuzPQCnlFPW4ky9Q+iA+ma9BGm06XQBy8g==
dependencies:
media-typer "0.3.0"
mime-types "~2.1.24"
typescript-formatter@^7.2:
version "7.2.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/typescript-formatter/-/typescript-formatter-7.2.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-V7vfI9XArVhriOTYHPzMU2WUnm5IMdu9X/CPxs8mIMGxmTBFpDABlbkBka64PZJ9/xgQeRpK8KzzAG4MPzxBDQ==
dependencies:
commandpost "^1.0.0"
editorconfig "^0.15.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
typescript@^4.8.4:
version "4.8.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/typescript/-/typescript-4.8.4.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-QCh+85mCy+h0IGff8r5XWzOVSbBO+KfeYrMQh7NJ58QujwcE22u+NUSmUxqF+un70P9GXKxa2HCNiTTMJknyjQ==
A look at `PolicyList.update` (#454) This started out as just a way to find out why mjolnir was syncing with lists several times for each update to a policy list. The main changes are - Verbosity was irrelevant to the sync command but for some reason was an option. Unfortunately all this did was suppress whether to tell you when it had finished, meaning it wouldn't when verbose logging was disabled. Historically this was probably a parameter that got passed through to applyServerAcl/applyUserBans, which can be horribly verbose, but they access the config directly. - Stop emitting `'PolicyList.update'` when there are no changes. - Include a revision ID for the `'PolicyList.update'`method and event. - Use the revision ID in the `ProtectedRoomsSet` so that we don't unnecessarily resynchronize all rooms when the `'PolicyList.update'` event is received. Though not when the `sync` command is used. Since this is supposed to `sync` in the case when there is a state reset or otherwise or the user has changed some room settings. - insert an await lock around the `PolicyList.update` method to avoid a race condition where a call can be started and finished within the extent of an existing call (via another task, this can happen if the server is slow with handling one request). `PolicyList.udpate` now has a helper that is synchronous to be called directly after requesting the room state. The reason for this is to enforce that no one `await`s while updating the policy list's cache of rules. Which is important because it is one of the biggest methods that I tolerate and visually checking for `await` is impossible. - The revision ID uses a ULID, but this is unnecessary and could have just been a "dumb counter". closes https://github.com/matrix-org/mjolnir/issues/447
2022-12-08 16:09:55 +00:00
ulidx@^0.3.0:
version "0.3.0"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/ulidx/-/ulidx-0.3.0.tgz"
A look at `PolicyList.update` (#454) This started out as just a way to find out why mjolnir was syncing with lists several times for each update to a policy list. The main changes are - Verbosity was irrelevant to the sync command but for some reason was an option. Unfortunately all this did was suppress whether to tell you when it had finished, meaning it wouldn't when verbose logging was disabled. Historically this was probably a parameter that got passed through to applyServerAcl/applyUserBans, which can be horribly verbose, but they access the config directly. - Stop emitting `'PolicyList.update'` when there are no changes. - Include a revision ID for the `'PolicyList.update'`method and event. - Use the revision ID in the `ProtectedRoomsSet` so that we don't unnecessarily resynchronize all rooms when the `'PolicyList.update'` event is received. Though not when the `sync` command is used. Since this is supposed to `sync` in the case when there is a state reset or otherwise or the user has changed some room settings. - insert an await lock around the `PolicyList.update` method to avoid a race condition where a call can be started and finished within the extent of an existing call (via another task, this can happen if the server is slow with handling one request). `PolicyList.udpate` now has a helper that is synchronous to be called directly after requesting the room state. The reason for this is to enforce that no one `await`s while updating the policy list's cache of rules. Which is important because it is one of the biggest methods that I tolerate and visually checking for `await` is impossible. - The revision ID uses a ULID, but this is unnecessary and could have just been a "dumb counter". closes https://github.com/matrix-org/mjolnir/issues/447
2022-12-08 16:09:55 +00:00
integrity sha512-Qvpa2xAzS6fBUpiqHSHWvn6XiSLCAPyNDDz035vsEWmUoXRqC4c9JySLIfdBuK0N1xGBxng6GHDOZgyNQfxAHg==
dependencies:
layerr "^0.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
underscore@~1.4.4:
version "1.4.4"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/underscore/-/underscore-1.4.4.tgz"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
integrity sha512-ZqGrAgaqqZM7LGRzNjLnw5elevWb5M8LEoDMadxIW3OWbcv72wMMgKdwOKpd5Fqxe8choLD8HN3iSj3TUh/giQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
undici-types@~5.26.4:
version "5.26.5"
resolved "https://registry.yarnpkg.com/undici-types/-/undici-types-5.26.5.tgz#bcd539893d00b56e964fd2657a4866b221a65617"
integrity sha512-JlCMO+ehdEIKqlFxk6IfVoAUVmgz7cU7zD/h9XZ0qzeosSHmUJVOzSQvvYSYWXkFXC+IfLKSIffhv0sVZup6pA==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
universalify@^0.1.2:
version "0.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/universalify/-/universalify-0.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-rBJeI5CXAlmy1pV+617WB9J63U6XcazHHF2f2dbJix4XzpUF0RS3Zbj0FGIOCAva5P/d/GBOYaACQ1w+0azUkg==
unpipe@1.0.0, unpipe@~1.0.0:
version "1.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/unpipe/-/unpipe-1.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-pjy2bYhSsufwWlKwPc+l3cN7+wuJlK6uz0YdJEOlQDbl6jo/YlPi4mb8agUkVC8BF7V8NuzeyPNqRksA3hztKQ==
uri-js@^4.2.2:
version "4.4.1"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/uri-js/-/uri-js-4.4.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-7rKUyy33Q1yc98pQ1DAmLtwX109F7TIfWlW1Ydo8Wl1ii1SeHieeh0HHfPeL2fMXK6z0s8ecKs9frCuLJvndBg==
dependencies:
punycode "^2.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
util-deprecate@^1.0.1:
version "1.0.2"
resolved "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz"
integrity sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
utils-merge@1.0.1:
version "1.0.1"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/utils-merge/-/utils-merge-1.0.1.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-pMZTvIkT1d+TFGvDOqodOclx0QWkkgi6Tdoa8gC8ffGAAqz9pzPTZWAybbsHHoED/ztMtkv/VoYTYyShUn81hA==
uuid@^3.3.2:
version "3.4.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/uuid/-/uuid-3.4.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-HjSDRw6gZE5JMggctHBcjVak08+KEVhSIiDzFnT9S9aegmp85S/bReBVTb4QTFaRNptJ9kuYaNhnbNEOkbKb/A==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
uuid@^8.3.2:
version "8.3.2"
resolved "https://registry.npmjs.org/uuid/-/uuid-8.3.2.tgz"
integrity sha512-+NYs2QeMWy+GWFOEm9xnn6HCDp0l7QBD7ml8zLUmJ+93Q5NF0NocErnwkTkXVFNiX3/fpC6afS8Dhb/gz7R7eg==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
v8-compile-cache@^2.0.3:
version "2.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/v8-compile-cache/-/v8-compile-cache-2.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-l8lCEmLcLYZh4nbunNZvQCJc5pv7+RCwa8q/LdUx8u7lsWvPDKmpodJAJNwkAhJC//dFY48KuIEmjtd4RViDrA==
vary@~1.1.2:
version "1.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/vary/-/vary-1.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-BNGbWLfd0eUPabhkXUVm0j8uuvREyTh5ovRa/dyow/BqAbZJyC+5fU+IzQOzmAKzYqYRAISoRhdQr3eIZ/PXqg==
verror@1.10.0:
version "1.10.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/verror/-/verror-1.10.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ZZKSmDAEFOijERBLkmYfJ+vmk3w+7hOLYDNkRCuRuMJGEmqYNCNLyBBFwWKVMhfwaEF3WOd0Zlw86U/WC/+nYw==
dependencies:
assert-plus "^1.0.0"
core-util-is "1.0.2"
extsprintf "^1.2.0"
w3c-hr-time@^1.0.2:
version "1.0.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/w3c-hr-time/-/w3c-hr-time-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-z8P5DvDNjKDoFIHK7q8r8lackT6l+jo/Ye3HOle7l9nICP9lf1Ci25fy9vHd0JOWewkIFzXIEig3TdKT7JQ5fQ==
dependencies:
browser-process-hrtime "^1.0.0"
w3c-xmlserializer@^2.0.0:
version "2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/w3c-xmlserializer/-/w3c-xmlserializer-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-4tzD0mF8iSiMiNs30BiLO3EpfGLZUT2MSX/G+o7ZywDzliWQ3OPtTZ0PTC3B3ca1UAf4cJMHB+2Bf56EriJuRA==
dependencies:
xml-name-validator "^3.0.0"
webidl-conversions@^5.0.0:
version "5.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/webidl-conversions/-/webidl-conversions-5.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-VlZwKPCkYKxQgeSbH5EyngOmRp7Ww7I9rQLERETtf5ofd9pGeswWiOtogpEO850jziPRarreGxn5QIiTqpb2wA==
webidl-conversions@^6.1.0:
version "6.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/webidl-conversions/-/webidl-conversions-6.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-qBIvFLGiBpLjfwmYAaHPXsn+ho5xZnGvyGvsarywGNc8VyQJUMHJ8OBKGGrPER0okBeMDaan4mNBlgBROxuI8w==
whatwg-encoding@^1.0.5:
version "1.0.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/whatwg-encoding/-/whatwg-encoding-1.0.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-b5lim54JOPN9HtzvK9HFXvBma/rnfFeqsic0hSpjtDbVxR3dJKLc+KB4V6GgiGOvl7CY/KNh8rxSo9DKQrnUEw==
dependencies:
iconv-lite "0.4.24"
whatwg-mimetype@^2.3.0:
version "2.3.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/whatwg-mimetype/-/whatwg-mimetype-2.3.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-M4yMwr6mAnQz76TbJm914+gPpB/nCwvZbJU28cUD6dR004SAxDLOOSUaB1JDRqLtaOV/vi0IC5lEAGFgrjGv/g==
whatwg-url@^8.0.0, whatwg-url@^8.5.0:
version "8.7.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/whatwg-url/-/whatwg-url-8.7.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-gAojqb/m9Q8a5IV96E3fHJM70AzCkgt4uXYX2O7EmuyOnLrViCQlsEBmF9UQIu3/aeAIp2U17rtbpZWNntQqdg==
dependencies:
lodash "^4.7.0"
tr46 "^2.1.0"
webidl-conversions "^6.1.0"
which@2.0.2, which@^2.0.1:
version "2.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/which/-/which-2.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==
dependencies:
isexe "^2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
winston-daily-rotate-file@^4.5.1:
version "4.7.1"
resolved "https://registry.npmjs.org/winston-daily-rotate-file/-/winston-daily-rotate-file-4.7.1.tgz"
integrity sha512-7LGPiYGBPNyGHLn9z33i96zx/bd71pjBn9tqQzO3I4Tayv94WPmBNwKC7CO1wPHdP9uvu+Md/1nr6VSH9h0iaA==
dependencies:
file-stream-rotator "^0.6.1"
object-hash "^2.0.1"
triple-beam "^1.3.0"
winston-transport "^4.4.0"
winston-transport@^4.4.0, winston-transport@^4.5.0:
version "4.5.0"
resolved "https://registry.npmjs.org/winston-transport/-/winston-transport-4.5.0.tgz"
integrity sha512-YpZzcUzBedhlTAfJg6vJDlyEai/IFMIVcaEZZyl3UXIl4gmqRpU7AE89AHLkbzLUsv0NVmw7ts+iztqKxxPW1Q==
dependencies:
logform "^2.3.2"
readable-stream "^3.6.0"
triple-beam "^1.3.0"
winston@^3.3.3:
version "3.8.1"
resolved "https://registry.npmjs.org/winston/-/winston-3.8.1.tgz"
integrity sha512-r+6YAiCR4uI3N8eQNOg8k3P3PqwAm20cLKlzVD9E66Ch39+LZC+VH1UKf9JemQj2B3QoUHfKD7Poewn0Pr3Y1w==
dependencies:
"@dabh/diagnostics" "^2.0.2"
async "^3.2.3"
is-stream "^2.0.0"
logform "^2.4.0"
one-time "^1.0.0"
readable-stream "^3.4.0"
safe-stable-stringify "^2.3.1"
stack-trace "0.0.x"
triple-beam "^1.3.0"
winston-transport "^4.5.0"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
word-wrap@^1.2.3, word-wrap@~1.2.3:
version "1.2.4"
resolved "https://registry.yarnpkg.com/word-wrap/-/word-wrap-1.2.4.tgz#cb4b50ec9aca570abd1f52f33cd45b6c61739a9f"
integrity sha512-2V81OA4ugVo5pRo46hAoD2ivUJx8jXmWXfUkY4KFNw0hEptvN0QfH3K4nHiwzGeKl5rFKedV48QVoqYavy4YpA==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
workerpool@6.2.0:
version "6.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/workerpool/-/workerpool-6.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-Rsk5qQHJ9eowMH28Jwhe8HEbmdYDX4lwoMWshiCXugjtHqMD9ZbiqSDLxcsfdqsETPzVUtX5s1Z5kStiIM6l4A==
wrap-ansi@^7.0.0:
version "7.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==
dependencies:
ansi-styles "^4.0.0"
string-width "^4.1.0"
strip-ansi "^6.0.0"
wrappy@1:
version "1.0.2"
2023-04-03 20:03:02 +00:00
resolved "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==
ws@^7.4.6:
version "7.5.5"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/ws/-/ws-7.5.5.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-BAkMFcAzl8as1G/hArkxOxq3G7pjUqQ3gzYbLL0/5zNkph70e+lCoxBGnm6AW1+/aiNeV4fnKqZ8m4GZewmH2w==
xml-name-validator@^3.0.0:
version "3.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/xml-name-validator/-/xml-name-validator-3.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-A5CUptxDsvxKJEU3yO6DuWBSJz/qizqzJKOMIfUJHETbBw/sFaDxgd6fxm1ewUaM0jZ444Fc5vC5ROYurg/4Pw==
xmlchars@^2.2.0:
version "2.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/xmlchars/-/xmlchars-2.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-JZnDKK8B0RCDw84FNdDAIpZK+JuJw+s7Lz8nksI7SIuU3UXJJslUthsi+uWBUYOwPFwW7W7PRLRfUKpxjtjFCw==
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
xtend@^4.0.0:
version "4.0.2"
resolved "https://registry.npmjs.org/xtend/-/xtend-4.0.2.tgz"
integrity sha512-LKYU1iAXJXUgAXn9URjiu+MWhyUXHsvfp7mcuYm9dSUKK0/CjtrUwFAxD82/mCWbtLsGjFIad0wIsod4zrTAEQ==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
y18n@^5.0.5:
version "5.0.8"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/y18n/-/y18n-5.0.8.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-0pfFzegeDWJHJIAmTLRP2DwHjdF5s7jo9tuztdQxAhINCdvS+3nGINqPd00AphqJR/0LhANUS6/+7SCb98YOfA==
yallist@^2.1.2:
version "2.1.2"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/yallist/-/yallist-2.1.2.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-ncTzHV7NvsQZkYe1DW7cbDLm0YpzHmZF5r/iyP3ZnQtMiJ+pjzisCiMNI+Sj+xQF5pXhSHxSB3uDbsBTzY/c2A==
yallist@^4.0.0:
version "4.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/yallist/-/yallist-4.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==
yaml@^2.2.2:
version "2.2.2"
resolved "https://registry.yarnpkg.com/yaml/-/yaml-2.2.2.tgz#ec551ef37326e6d42872dad1970300f8eb83a073"
integrity sha512-CBKFWExMn46Foo4cldiChEzn7S7SRV+wqiluAb6xmueD/fGyRHIhX8m14vVGgeFWjN540nKCNVj6P21eQjgTuA==
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
2023-04-03 20:03:02 +00:00
yargs-parser@20.2.4, yargs-parser@^20.2.2:
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
version "20.2.4"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/yargs-parser/-/yargs-parser-20.2.4.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-WOkpgNhPTlE73h4VFAFsOnomJVaovO8VqLDzy5saChRBFQFBoMYirowyW+Q9HB4HFF4Z7VZTiG3iSzJJA29yRA==
yargs-unparser@2.0.0:
version "2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/yargs-unparser/-/yargs-unparser-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-7pRTIA9Qc1caZ0bZ6RYRGbHJthJWuakf+WmHK0rVeLkNrrGhfoabBNdue6kdINI6r4if7ocq9aD/n7xwKOdzOA==
dependencies:
camelcase "^6.0.0"
decamelize "^4.0.0"
flat "^5.0.2"
is-plain-obj "^2.1.0"
yargs@16.2.0:
version "16.2.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/yargs/-/yargs-16.2.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-D1mvvtDG0L5ft/jGWkLpG1+m0eQxOfaBvTNELraWj22wSVUMWxZUvYgJYcKh6jGGIkJFhH4IZPQhR4TKpc8mBw==
dependencies:
cliui "^7.0.2"
escalade "^3.1.1"
get-caller-file "^2.0.5"
require-directory "^2.1.1"
string-width "^4.2.0"
y18n "^5.0.5"
yargs-parser "^20.2.2"
yn@^2.0.0:
version "2.0.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/yn/-/yn-2.0.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-uTv8J/wiWTgUTg+9vLTi//leUl5vDQS6uii/emeTb2ssY7vl6QWf2fFbIIGjnhjvbdKlU0ed7QPgY1htTC86jQ==
yocto-queue@^0.1.0:
version "0.1.0"
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 18:03:06 +00:00
resolved "https://registry.npmjs.org/yocto-queue/-/yocto-queue-0.1.0.tgz"
audit yarn.lock (#356) ### Auditing the lock file ``` npm install --package-lock-only npm audit fix rm yarn.lock yarn import ``` ``` npm audit json-schema <0.4.0 Severity: critical json-schema is vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-896r-f27r-55mw fix available via `npm audit fix` node_modules/json-schema jsprim 0.3.0 - 1.4.1 || 2.0.0 - 2.0.1 Depends on vulnerable versions of json-schema node_modules/jsprim minimist <1.2.6 Severity: critical Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h fix available via `npm audit fix` node_modules/minimist nanoid 3.0.0 - 3.1.30 Severity: moderate Exposure of Sensitive Information to an Unauthorized Actor in nanoid - https://github.com/advisories/GHSA-qrpm-p2h7-hrv2 fix available via `npm audit fix` node_modules/nanoid node_modules/postcss/node_modules/nanoid mocha 8.2.0 - 9.1.4 Depends on vulnerable versions of nanoid node_modules/mocha 5 vulnerabilities (2 moderate, 3 critical) To address all issues, run: npm audit fix ``` ### minimist minimist@1.2.5 used by mocha, tslint and matrix-bot-sdk@0.5.19 via ``` MatrixClient::replyHtmlText MatrixClient::replyHtmlNotice MatrixClient::sendHtmlNotice MatrixClient::sendHtmlTex ``` none of which we use. ### nanoid As for nanoid this is used by mocha. It's also used by postcss vis the bot sdk ``` ├─┬ matrix-bot-sdk@0.5.19 │ └─┬ sanitize-html@2.7.1 │ └─┬ postcss@8.4.16 │ ├── nanoid@3.3.4 ``` though unless i'm missing something nanoid@3.3.4 doesn't fit into the vulnerable versions `3.0.0 - 3.1.30` ### json-schema As for json-schema, it is used by jsprim@1.4.2 within 'validateJsonObjectJS'. fortunately we depend on jsprim via the http-signatures@1.2.0 package which only use jsprim for rfc1123. (which request depends upon in the matrix-bot-sdk). ``` ├─┬ matrix-bot-sdk@0.5.19 │ ├─┬ request@2.88.2 │ │ ├─┬ http-signature@1.2.0 │ │ │ ├─┬ jsprim@1.4.2 │ │ │ │ ├── json-schema@0.4.0
2022-08-16 17:49:33 +00:00
integrity sha512-rVksvsnNCdJ/ohGc6xgPwyN8eheCxsiLM8mxuE/t/mOVqJewPuO1miLpTHQiRgTKCLexL4MeAFVagts7HmNZ2Q==