Matrix-Mirrors/mjolnir
1
0
Fork 0
mirror of https://github.com/matrix-org/mjolnir.git synced 2024-10-01 01:36:06 -04:00
Code Issues Packages Projects Releases Wiki Activity
8bf628e5bd
mjolnir/yarn.lock

3623 lines
138 KiB
Plaintext
Raw Normal View History

Absolute bare minimum for a bot
2019-09-25 22:13:20 -04: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 13:03:06 -05: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==
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-Zt1yodBx1UcyiePMSkWnU4hPqhwq7hGi2nFL1LeA3EUl+q2LQx16MISgJ0+z7dnmgvP9QtIleuETGOiOH1RcIw==
load config yaml manually, remove more references to static config (#347)
2022-08-16 10:51:18 -04:00
dependencies:
"@babel/highlight" "^7.10.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-9pzDqyc6OLDaqe+zbACgFkb6fKMNG6CObKpnYXChRsvYGyEdc7CA2BaqeOM+vOtCS5ndmJicPJhKAwYRI6UfFw==
dependencies:
"@babel/highlight" "^7.14.5"
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-K4JvCtQqad9OY2+yTU8w+E82ywk/fe+ELNlt1G8z3bVGlZfn/hOcQQsUhGhW/N+tb3fxK800wLtKOE/aM0m72w==
Absolute bare minimum for a bot
2019-09-25 22:13:20 -04:00
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-qf9u2WFWVV0MppaL877j2dBtQIDgmidgjGk5VIMw3OadXvYaXn66U1BFlH2t4+t3i+8PhedppRv+i40ABzd+gg==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
dependencies:
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04:00
chalk "^2.0.0"
js-tokens "^4.0.0"
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05: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 13:03:06 -05: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"
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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"
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04:00
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-FagtKFz74XrTl7y6HCzQpwDfXP0yhxe9lHLD1UZxjvZIcbyRz8zTFF/yYNfSfzU414eDwZ1SrO0Qvtyf+wFMQg==
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04:00
dependencies:
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@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 13:49:33 -04:00
debug "^4.1.1"
minimatch "^3.0.4"
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04:00
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-wdppn25U8z/2yiaT6YGquE6X8sSv7hNMWSXYSSU1jGv/yd6XqjXgTDJ8KP4NgjTXfJ3GbRjeeb8RTV7a/VpM+w==
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-IDO2ezTxeMvQAHxzG/ZvEyA47q0aVfzT95rGFl7bZs/Go0aIucvfDbS2rmnoEdXxlLQhcolmoG/wvL/uKx4tKA==
Update packages
2020-04-14 18:17:05 -04:00
dependencies:
"@types/istanbul-lib-coverage" "^2.0.0"
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04:00
chalk "^4.0.0"
Update packages
2020-04-14 18:17:05 -04: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 13:03:06 -05:00
"@matrix-org/matrix-sdk-crypto-nodejs@^0.1.0-beta.1":
version "0.1.0-beta.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-jCSKrmNh6kaqnOwS/Pqgqkeb+CAvwGuS0oNEW3LaWKrJWFAfUrt+lXBCs7kAP79Qo5ZKBU06BekbZuwYhWbhkQ==
dependencies:
node-downloader-helper "^2.1.1"
Give the ability to moderators to react quickly to /report abuse reports. (#137)
2021-11-09 07:15:49 -05:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-J3jpy002TyBjd4N/p6s+s90eX42H2eRhK3SbsZuvTDv977/E8p2U3zikdiehyJja66do7FlxLomZLPlvl2/xaA==
Give the ability to moderators to react quickly to /report abuse reports. (#137)
2021-11-09 07:15:49 -05:00
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 13:49:33 -04:00
domhandler "^4.2.0"
selderee "^0.6.0"
Give the ability to moderators to react quickly to /report abuse reports. (#137)
2021-11-09 07:15:49 -05:00
Very basic support for Sentry. (#398) The Sentry package is very useful for monitoring runtime errors. With this PR, we simply add the necessary mechanism to: - log to sentry any uncaught error that reaches the toplevel, including startup errors.
2022-11-30 10:06:02 -05:00
"@sentry/core@7.22.0":
version "7.22.0"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/@sentry/core/-/core-7.22.0.tgz"
Very basic support for Sentry. (#398) The Sentry package is very useful for monitoring runtime errors. With this PR, we simply add the necessary mechanism to: - log to sentry any uncaught error that reaches the toplevel, including startup errors.
2022-11-30 10:06:02 -05:00
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"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/@sentry/node/-/node-7.22.0.tgz"
Very basic support for Sentry. (#398) The Sentry package is very useful for monitoring runtime errors. With this PR, we simply add the necessary mechanism to: - log to sentry any uncaught error that reaches the toplevel, including startup errors.
2022-11-30 10:06:02 -05:00
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"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/@sentry/tracing/-/tracing-7.22.0.tgz"
Very basic support for Sentry. (#398) The Sentry package is very useful for monitoring runtime errors. With this PR, we simply add the necessary mechanism to: - log to sentry any uncaught error that reaches the toplevel, including startup errors.
2022-11-30 10:06:02 -05:00
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"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/@sentry/types/-/types-7.22.0.tgz"
Very basic support for Sentry. (#398) The Sentry package is very useful for monitoring runtime errors. With this PR, we simply add the necessary mechanism to: - log to sentry any uncaught error that reaches the toplevel, including startup errors.
2022-11-30 10:06:02 -05:00
integrity sha512-LhCL+wb1Jch+OesB2CIt6xpfO1Ab6CRvoNYRRzVumWPLns1T3ZJkarYfhbLaOEIb38EIbPgREdxn2AJT560U4Q==
"@sentry/utils@7.22.0":
version "7.22.0"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/@sentry/utils/-/utils-7.22.0.tgz"
Very basic support for Sentry. (#398) The Sentry package is very useful for monitoring runtime errors. With this PR, we simply add the necessary mechanism to: - log to sentry any uncaught error that reaches the toplevel, including startup errors.
2022-11-30 10:06:02 -05:00
integrity sha512-1GiNw1opIngxg0nktCTc9wibh4/LV12kclrnB9dAOHrqazZXHXZRAkjqrhQphKcMpT+3By91W6EofjaDt5a/hg==
dependencies:
"@sentry/types" "7.22.0"
tslib "^1.9.3"
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@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 13:49:33 -04:00
version "1.1.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-RbzJvlNzmRq5c3O09UipeuXno4tA1FE6ikOjxZK0tuxVv3412l64l5t1W5pj4+rJq9vpkm/kwiR07aZXnsKPxw==
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04:00
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
"@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 13:03:06 -05:00
version "1.19.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-ALYone6pm6QmwZoAgeyNksccT9Q4AWZQ6PvfwR37GT6r6FWUPguq6sUmNGSMV2Wr761oQoBxwGGa6DR5o1DC9g==
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
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 13:03:06 -05:00
"@types/caseless@*":
version "0.12.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-6ckxMjBBD8URvjB6J3NcnuAn5Pkl7t3TizAg+xdlzzQGSPSmBcXf8KoIH0ua/i+tio+ZRUHEXp0HEmvaR4kt0w==
Config fixes (#432) * Use the npm package `config` to load the config. This is what was used prior to https://github.com/matrix-org/mjolnir/pull/347. It was a nice idea motivated to drop a dependency that was confusing. It was just never followed through and was underestimated how much disruption it would cause. It was also believed that the library would mean there could only ever be one global copy of the config, It was followed up by: https://github.com/matrix-org/mjolnir/pull/369 https://github.com/matrix-org/mjolnir/pull/357 https://github.com/matrix-org/mjolnir/pull/429 https://github.com/matrix-org/mjolnir/pull/397/files https://github.com/matrix-org/mjolnir/issues/365 For simplicity sake I am reinstating the library. The practice of loading default.yaml by default is also dangerous and has led to issues multiple times in #mjolnir:matrix.org. It is a sample and not a default. In a following commit I will be adding the ability to specify the config to use from the cli. * Allow config to be specified with an explicit cli argument. * Update doc to transition away from old config handling
2022-11-23 05:55:22 -05:00
"@types/config@^3.3.0":
version "3.3.0"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/@types/config/-/config-3.3.0.tgz"
Config fixes (#432) * Use the npm package `config` to load the config. This is what was used prior to https://github.com/matrix-org/mjolnir/pull/347. It was a nice idea motivated to drop a dependency that was confusing. It was just never followed through and was underestimated how much disruption it would cause. It was also believed that the library would mean there could only ever be one global copy of the config, It was followed up by: https://github.com/matrix-org/mjolnir/pull/369 https://github.com/matrix-org/mjolnir/pull/357 https://github.com/matrix-org/mjolnir/pull/429 https://github.com/matrix-org/mjolnir/pull/397/files https://github.com/matrix-org/mjolnir/issues/365 For simplicity sake I am reinstating the library. The practice of loading default.yaml by default is also dangerous and has led to issues multiple times in #mjolnir:matrix.org. It is a sample and not a default. In a following commit I will be adding the ability to specify the config to use from the cli. * Allow config to be specified with an explicit cli argument. * Update doc to transition away from old config handling
2022-11-23 05:55:22 -05:00
integrity sha512-9kZSbl3/X3TVNowLCu5HFQdQmD+4287Om55avknEYkuo6R2dDrsp/EXEHUFvfYeG7m1eJ0WYGj+cbcUIhARJAQ==
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-cdeYyv4KWoEgpBISTxWvqYsVy444DOqehiF3fM3ne10AmJ62RSyNkUnxMJXHQWRQQX2eR94m5y1IZyDwBjV9FQ==
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
dependencies:
"@types/node" "*"
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-sCVniU+h3GcGqxOmng11BRvf9TfN9yIs8KKjB8C8d75W69cpTfZG80gau9yTx5SxF3gvHGbJhdESzzvnjtf3Og==
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04:00
Update packages
2021-07-01 15:45:28 -04: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 13:03:06 -05:00
version "4.17.30"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-gstzbTWro2/nFed1WXtf+TtrpwxH7Ggs4RLYTLbeVgIkUQOI3WG/JKjgeOU1zXDvezllupjrf8OPIdvTbIaVOQ==
Update packages
2021-07-01 15:45:28 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-6bSZTPaTIACxn48l50SR+axgrqm6qXFIxrdAKaG6PaJk3+zuUr35hBlgT7vOmJcum+OEaIBLtHV/qloEAFITeA==
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
dependencies:
"@types/body-parser" "*"
Update packages
2021-07-01 15:45:28 -04:00
"@types/express-serve-static-core" "^4.17.18"
"@types/qs" "*"
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
"@types/serve-static" "*"
A room Protection designed to measure lag in a room (#217)
2022-02-24 07:43:31 -05:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-0B/OifmJYmk5r9z9+KJtGWOF0LEjbTN4D2QeCh+mAw81JkJwC83NvNWUZFEqRT5PpnjX7vX0ab1SMGcwCs3Lag==
A room Protection designed to measure lag in a room (#217)
2022-02-24 07:43:31 -05:00
New command `!mjolnir since <date or duration> <kick | ban | show> <limit> [reason] [...rooms]` (#238) A new command `since` to affect all users who have joined a protected room since a given date.
2022-03-21 05:39:15 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-K3e+NZlpCKd6Bd/EIdqjFJRFHbrq5TzPPLwREk5Iv/YoIjQrs6ljdAUCo+Lb2xFlGNOjGSE0dqsVD19cZL137w==
New command `!mjolnir since <date or duration> <kick | ban | show> <limit> [reason] [...rooms]` (#238) A new command `since` to affect all users who have joined a protected room since a given date.
2022-03-21 05:39:15 -04:00
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-sz7iLqvVUg1gIedBOvlkxPlc8/uVzyS5OwGz1cKjXzkl3FpL3al0crU8YGU1WoHkxn0Wxbw5tyi6hvzJKNzFsw==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-plGgXAPfVKFoYfa9NpYDAkseG+g6Jr294RqeqcqDixSbU34MZVJRi/P+7Y8GDpzkEwLaGZZOpKIEmeVZNtKsrg==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
dependencies:
"@types/istanbul-lib-coverage" "*"
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-c3mAZEuK0lvBp8tmuL74XRKn1+y2dcwOUpH7x4WrF6gk1GIgiluDRgMYQtw2OFcBvAJWlt6ASU3tSqxp0Uu0Aw==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
dependencies:
"@types/istanbul-lib-report" "*"
load config yaml manually, remove more references to static config (#347)
2022-08-16 10:51:18 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-FhpRzf927MNQdRZP0J5DLIdTXhjLYzeUTmLAu69mnVksLH9CJY3IuSeEgbKUki7GQZm0WqDkGzyxju2EZGD2wA==
load config yaml manually, remove more references to static config (#347)
2022-08-16 10:51:18 -04:00
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-8JQCjdeAidptSsOcRWk2iTm9wCcwn9l+kRG6k5bzUacrnm1ezV4forq0kWjUih/tumAeoG+OspOvQEbbRucBTw==
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
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 13:49:33 -04:00
"@types/parse5" "*"
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@types/tough-cookie" "*"
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-dRLjCWHYg4oaA77cxO64oO+7JwCwnIzkZPdrrC71jQmQtlhM556pwKo5bUzqvZndkVbeFLIIi+9TC40JNF5hNQ==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-YATxVxgRqNH6nHEIsvg6k2Boc1JHI9ZbH5iWFFv/MTkchz3b1ieGDa5T0a9RznNdI0KhVbdbWSN+KWWrQZRxTw==
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
Replace shutdown_room API with DELETE /_synapse/admin/v1/rooms/<room_id> - Resolves #76, closes #96 As per https://github.com/matrix-org/synapse/issues/9052, shutdown_room is going away, to be replaced with DELETE /_synapse/admin/v1/rooms/<room_id>.
2021-07-28 04:56:50 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-scN0hAWyLVAvLR9AyW7HoFF5sJZglyBsbPuHO4fv7JRvfmPBMfp1ozWqOf/e4wwPNxezBZXRfWzMb6iFLgEVRA==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05: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 13:03:06 -05: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" "*"
Bump node version to 18 (#496) * try win dns res * add dns hack to application service tests * fix unused import * update types * add note about why dns resolution order is necessary
2023-11-14 15:52:53 -05:00
"@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 13:49:33 -04:00
version "16.10.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-zCclL4/rx+W5SQTzFs9wyvvyCwoK9QtBpratqz2IYJ3O8Umrn0m3nsTv0wQBk9sRGpvUe9CwPDrQFB10f1FIjQ==
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
Bump node version to 18 (#496) * try win dns res * add dns hack to application service tests * fix unused import * update types * add note about why dns resolution order is necessary
2023-11-14 15:52:53 -05:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-ARATsLdrGPUnaBvxLhUlnltcMgn7pQG312S8ccdYlnyijabrX9RN/KN/iGj9Am96CoW8e/K9628BA7Bv4XHdrA==
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04: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 13:03:06 -05:00
"@types/pg@^8.6.5":
version "8.6.5"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-tOkGtAqRVkHa/PVZicq67zuujI4Oorfglsr2IbKofDwBSysnaqSx7W1mDqFqdkGE6Fbgh+PZAl0r/BWON/mozw==
dependencies:
"@types/node" "*"
pg-protocol "*"
pg-types "^2.2.0"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
"@types/pkginfo@^0.4.0":
version "0.4.0"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/@types/pkginfo/-/pkginfo-0.4.0.tgz"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
integrity sha512-4DGKkOlWkMuVDZQvytWzzWWAjyqDmlLKRYE4lzeA8t0s7fK0aF25uPbX9eBVermUjLJdeLHu9k1WmNiAssqCcg==
dependencies:
"@types/node" "*"
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-FGa1F62FT09qcrueBA6qYTrJPVDzah9a+493+o2PCXsesWHIn27G98TsSMs3WPNbZIEj4+VJf6saSFpvD+3Zsw==
Update packages
2021-07-01 15:45:28 -04:00
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-EEhsLsD6UsDM1yFhAvy0Cjr6VwmpMWqFBCb9w07wVugF7w9nfajxLuVmngTIpgS6svCnm6Vaw+MZhoDCKnOfsw==
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05: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 13:03:06 -05:00
"@types/request@^2.48.8":
version "2.48.8"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-whjk1EDJPcAR2kYHRbFl/lKeeKYTi05A15K9bnLInCVroNDCtXce57xKdI0/rQaA3K+6q0eFyUBPmqfSndUZdQ==
dependencies:
"@types/caseless" "*"
"@types/node" "*"
"@types/tough-cookie" "*"
form-data "^2.5.0"
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-nCkHGI4w7ZgAdNkrEu0bv+4xNV/XDqW+DydknebMOQwkpDGx8G+HTlj7R7ABI8i8nKxVw0wtKPi1D+lPOkh4YQ==
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
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 13:49:33 -04:00
"@types/mime" "^1"
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@types/node" "*"
Upgrade to bot-sdk beta 13 for dependency problem
2019-11-06 21:29:17 -05:00
Bump minimist from 1.2.5 to 1.2.6 (#260) Bumps [minimist](https://github.com/substack/minimist) from 1.2.5 to 1.2.6. - [Release notes](https://github.com/substack/minimist/releases) - [Commits](https://github.com/substack/minimist/compare/1.2.5...1.2.6) --- updated-dependencies: - dependency-name: minimist dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2022-03-25 06:05:23 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-SWZ2Nom1pkyXCDohRSrkSKvDh8QOG9RfAsrt5/NsPQC4UQJ55eG0qClA40I+Gkez4KTQ0uDUT8ELRXThf3J5jw==
New command `!mjolnir since <date or duration> <kick | ban | show> <limit> [reason] [...rooms]` (#238) A new command `since` to affect all users who have joined a protected room since a given date.
2022-03-21 05:39:15 -04:00
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-Hl219/BT5fLAaz6NDkSuhzasy49dwQS/DSdu4MdggFB8zcXv7vflBI3xp7FEmkmdDkBUI2bPUNeMttp2knYdxw==
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-Y0K95ThC3esLEYD6ZuqNek29lNX2EM1qxV8y2FTLUB0ff5wWrk7az+mLrnNFUnaXcgKye22+sFBRXOgpPILZNg==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
"@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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-7tFImggNeNBVMsn0vLrpn1H1uPrUBdnARPTpZoitY37ZrdJREzf7I16tMrlK3hen349gr1NYh8CmZQa7CTG6Aw==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-T8Yc9wt/5LbJyCaLiHPReJa0kApcIgJ7Bn735GjItUfh08Z1pJvu8QZqb9s+mMvKV6WUQRV7K2R46YbjMXTTJw==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
dependencies:
"@types/yargs-parser" "*"
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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==
Bump express from 4.17.1 to 4.17.3 (#455) Bumps [express](https://github.com/expressjs/express) from 4.17.1 to 4.17.3. - [Release notes](https://github.com/expressjs/express/releases) - [Changelog](https://github.com/expressjs/express/blob/master/History.md) - [Commits](https://github.com/expressjs/express/compare/4.17.1...4.17.3) --- updated-dependencies: - dependency-name: express dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2022-12-08 11:19:00 -05:00
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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
version "8.11.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==
array-flatten@1.1.1:
version "1.1.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
version "0.2.6"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
dependencies:
safer-buffer "~2.1.0"
assert-plus@1.0.0, assert-plus@^1.0.0:
version "1.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-NfJ4UzBCcQGLDlQq7nHxH+tv3kyZ0hHQqF5BO6J7tNJeP5do1llPr8dZ8zHonfhAu0PHAdMkSo+8o0wxg9lZWw==
astral-regex@^2.0.0:
version "2.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
async-lock@^1.3.2:
version "1.3.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-phnXdS3RP7PPcmP6NWWzWMU0sLTeyvtZCxBPpZdkYE3seGLKSQZs9FrmVO/qwypq98FUtWWUEYxziLkdGk5nnA==
async@0.2.10:
version "0.2.10"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-eAkdoKxU6/LkKDBzLpT+t6Ff5EtfSF4wx1WfJiPEEV7WNLnDaRXk0oVysiEPm262roaachGexwUv94WhSgN5TQ==
async@^3.2.3:
version "3.2.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
asynckit@^0.4.0:
version "0.4.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-Oei9OH4tRh0YqU3GxhX79dM/mwVgvbZJaSNaRk+bshkj0S5cfHcgYakreBjrHwatXKbz+IoIdYLxrKim2MjW0Q==
Factor out protected rooms config management from Mjolnir. The combination of `resyncJoinedRooms`, `unprotectedWatchedListRooms`, `explicitlyProtectedRoomIds`, `protectedJoinedRoomIds` was incomprehensible. https://github.com/matrix-org/mjolnir/issues/370 Separating out the management of `explicitlyProtectedRoomIds`, then making sure all policy lists have to be explicitly protected (in either setting of `config.protectAllJoinedRooms`) will make this code much much simpler. We will later change the `status` command to explicitly show which lists are watched and which are watched and protected.
2022-10-13 12:19:32 -04:00
await-lock@^2.2.2:
version "2.2.2"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/await-lock/-/await-lock-2.2.2.tgz"
Factor out protected rooms config management from Mjolnir. The combination of `resyncJoinedRooms`, `unprotectedWatchedListRooms`, `explicitlyProtectedRoomIds`, `protectedJoinedRoomIds` was incomprehensible. https://github.com/matrix-org/mjolnir/issues/370 Separating out the management of `explicitlyProtectedRoomIds`, then making sure all policy lists have to be explicitly protected (in either setting of `config.protectAllJoinedRooms`) will make this code much much simpler. We will later change the `status` command to explicitly show which lists are watched and which are watched and protected.
2022-10-13 12:19:32 -04:00
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 13:49:33 -04:00
aws-sign2@~0.7.0:
version "0.7.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-08kcGqnYf/YmjoRhfxyu+CLxBjUtHLXLXX/vUfx9l2LYzG3c1m61nrpyFUZI6zeS+Li/wWMMidD9KgrqtGq3mA==
aws4@^1.8.0:
version "1.11.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
axios@^0.27.2:
version "0.27.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
balanced-match@^1.0.0:
version "1.0.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==
basic-auth@~2.0.1:
version "2.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-NF+epuEdnUYVlGuhaxbbq+dvJttwLnGY+YixlXlME5KpQ5W3CnXA5cVTneY3SPbPDRkcjMbifrwmFYcClgOZeg==
dependencies:
safe-buffer "5.1.2"
bcrypt-pbkdf@^1.0.0:
version "1.0.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-XpNj6GDQzdfW+r2Wnn7xiSAd7TM3jzkxGXBGTtWKuSXv1xUV+azxAm8jdWZN06QTQk+2N2XB9jRDkvbmQmcRtg==
Bump express from 4.17.1 to 4.17.3 (#455) Bumps [express](https://github.com/expressjs/express) from 4.17.1 to 4.17.3. - [Release notes](https://github.com/expressjs/express/releases) - [Changelog](https://github.com/expressjs/express/blob/master/History.md) - [Commits](https://github.com/expressjs/express/compare/4.17.1...4.17.3) --- updated-dependencies: - dependency-name: express dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2022-12-08 11:19:00 -05:00
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 13:03:06 -05:00
version "1.20.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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"
Bump express from 4.17.1 to 4.17.3 (#455) Bumps [express](https://github.com/expressjs/express) from 4.17.1 to 4.17.3. - [Release notes](https://github.com/expressjs/express/releases) - [Changelog](https://github.com/expressjs/express/blob/master/History.md) - [Commits](https://github.com/expressjs/express/compare/4.17.1...4.17.3) --- updated-dependencies: - dependency-name: express dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2022-12-08 11:19:00 -05:00
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 13:03:06 -05:00
version "1.20.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
brace-expansion@^1.1.7:
version "1.1.11"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-9o5UecI3GhkpM6DrXr69PblIuWxPKk9Y0jHBRhdocZ2y7YECBFCsHm79Pr3OyR2AvjhDkabFJaDJMYRazHgsow==
browser-stdout@1.3.1:
version "1.3.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
buffer-writer@2.0.0:
version "2.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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"
Update packages
2020-04-14 18:17:05 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-aE2Y4MTFJ870NuB/+2z1cXBhSBBzRydVVjzhFC4gtenEhpnj15yu0qptWGJsO9YGrcPZ3ezX8AWb1VA391MKpQ==
concat-map@0.0.1:
version "0.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-/Srv4dswyQNBfohGpz9o6Yb3Gz3SrUDqBH5rTuhGR7ahtlbYKnVxw2bCFMRljaA7EXHaXZ8wsHdodFvbkhKmqg==
Config fixes (#432) * Use the npm package `config` to load the config. This is what was used prior to https://github.com/matrix-org/mjolnir/pull/347. It was a nice idea motivated to drop a dependency that was confusing. It was just never followed through and was underestimated how much disruption it would cause. It was also believed that the library would mean there could only ever be one global copy of the config, It was followed up by: https://github.com/matrix-org/mjolnir/pull/369 https://github.com/matrix-org/mjolnir/pull/357 https://github.com/matrix-org/mjolnir/pull/429 https://github.com/matrix-org/mjolnir/pull/397/files https://github.com/matrix-org/mjolnir/issues/365 For simplicity sake I am reinstating the library. The practice of loading default.yaml by default is also dangerous and has led to issues multiple times in #mjolnir:matrix.org. It is a sample and not a default. In a following commit I will be adding the ability to specify the config to use from the cli. * Allow config to be specified with an explicit cli argument. * Update doc to transition away from old config handling
2022-11-23 05:55:22 -05:00
config@^3.3.8:
version "3.3.8"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/config/-/config-3.3.8.tgz"
Config fixes (#432) * Use the npm package `config` to load the config. This is what was used prior to https://github.com/matrix-org/mjolnir/pull/347. It was a nice idea motivated to drop a dependency that was confusing. It was just never followed through and was underestimated how much disruption it would cause. It was also believed that the library would mean there could only ever be one global copy of the config, It was followed up by: https://github.com/matrix-org/mjolnir/pull/369 https://github.com/matrix-org/mjolnir/pull/357 https://github.com/matrix-org/mjolnir/pull/429 https://github.com/matrix-org/mjolnir/pull/397/files https://github.com/matrix-org/mjolnir/issues/365 For simplicity sake I am reinstating the library. The practice of loading default.yaml by default is also dangerous and has led to issues multiple times in #mjolnir:matrix.org. It is a sample and not a default. In a following commit I will be adding the ability to specify the config to use from the cli. * Allow config to be specified with an explicit cli argument. * Update doc to transition away from old config handling
2022-11-23 05:55:22 -05:00
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 13:03:06 -05:00
content-disposition@0.5.4:
version "0.5.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
content-type@~1.0.4:
version "1.0.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-hIP3EEPs8tB9AT1L+NUqtwOAps4mk2Zob89MWXMHjHWg9milF/j4osnnQLXBCBFBk/tvIG/tUc9mOUJiPBhPXA==
cookie-signature@1.0.6:
version "1.0.6"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
cookie@0.5.0:
version "0.5.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-YZ3GUyn/o8gfKJlnlX7g7xq4gyO6OSuhGPKaaGssGB2qgDUS0gPgtTvoyZLTt9Ab6dC4hfc9dV5arkvc/OCmrw==
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
core-util-is@1.0.2:
version "1.0.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-3lqz5YjWTYnW6dlDa5TLaTCcShfar1e40rmcJVwCBJC6mWlFuj0eCHIElmG1g5kyuJ/GD+8Wn4FFCcz4gJPfaQ==
cross-spawn@^7.0.2:
version "7.0.3"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-AZL67abkUzIuvcHqk7c09cezpGNcxUxU4Ioi/05xHk4DQeTkWmGYftIE6ctU6AEt+Gn4n1lDStOtj7FKycP71A==
dependencies:
cssom "~0.3.6"
dashdash@^1.12.0:
version "1.14.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-/zxw5+vh1Tfv+4Qn7a5nsbcJKPaSvCDhojn6FEl9vupwK2VCSDtEiEtqr8DFtzYFOdz63LBkxec7DYuc2jon6Q==
dependencies:
ms "2.1.2"
decamelize@^4.0.0:
version "4.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-V0pfhfr8suzyPGOx3nmq4aHqabehUZn6Ch9kyFpV79TGDTWFmHqUqXdabR7QHqxzrYolF4+tVmJhUG4OURg5dQ==
deep-is@^0.1.3, deep-is@~0.1.3:
version "0.1.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-oIPzksmTg4/MriiaYGO+okXDT7ztn/w3Eptv/+gSIdMdKsJo0u4CfYNFJPy+4SKMuCqGw2wxnA+URMg3t8a/bQ==
deepmerge@^4.2.2:
version "4.2.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-FJ3UgI4gIl+PHZm53knsuSFpE+nESMr7M4v9QcgB7S63Kj/6WqMiFQJpBBYz1Pt+66bZpP3Q7Lye0Oo9MPKEdg==
delayed-stream@~1.0.0:
version "1.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
depd@2.0.0, depd@~2.0.0:
version "2.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-g7nH6P6dyDioJogAAGprGpCtVImJhpPk/roCzdb3fIh61/s/nPsfR6onyMwkCAR/OlC3yBC0lESvUoQEAssIrw==
destroy@1.2.0:
version "1.2.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
version "27.5.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
diff@5.0.0:
version "5.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-/VTCrvm5Z0JGty/BWHljh+BAiw3IK+2j87NGMu8Nwc/f48WoDAC395uomO9ZD117ZOBaHmkX1oyLvkVM/aIT3w==
diff@^3.1.0:
version "3.5.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-A46qtFgd+g7pDZinpnwiRJtxbC1hpgf0uzP3iG89scHk0AUC7A1TGxf5OiiOUv/JMZR8GOt8hL900hV0bOy5xA==
diff@^4.0.1:
version "4.0.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-58lmxKSA4BNyLz+HHMUzlOEpg09FV+ev6ZMe3vJihgdxzgcwZ8VoEEPmALCZG9LmqfVoNMMKpttIYTVG6uDY7A==
discontinuous-range@1.0.0:
version "1.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-c68LpLbO+7kP/b1Hr1qs8/BJ09F5khZGTxqxZuhzxpmwJKOgRFHJWIb9/KmqnqHhLdO55aOxFH/EGBvUQbL/RQ==
doctrine@^3.0.0:
version "3.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
version "2.3.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
version "4.3.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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"
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04: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 13:49:33 -04:00
source-map "~0.6.1"
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-2NxwbF/hZ0KpepYN0cNbo+FN6XoK7GaHlQhgx/hIZl6Va0bF45RQOOwhLIy8lQDbuCiadSLCBnH2CFYquit5bw==
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
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 13:49:33 -04:00
esrecurse "^4.3.0"
estraverse "^4.1.1"
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-w94dQYoauyvlDc43XnGB8lU3Zt713vNChgt4EWwhXAP2XkBvndfxF0AgIqKOOasjPIPzj9JqgwkwbCYD0/V3Zg==
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
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 13:49:33 -04:00
eslint-visitor-keys "^1.1.0"
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-6J72N8UNa462wa/KFODt/PJ3IU60SDpC3QXC1Hjc1BXXpfL2C9R5+AU7jhe0F6GREqVMh4Juu+NY7xn+6dipUQ==
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-0rSmRBzXgDzIsD6mGdJgevzgezI534Cer5L/vyMX0kHzT/jiB43jRhd9YUlMGYLQy2zprNmoT8qasCGtY+QaKw==
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-VHZ8gX+EDfz+97jGcgyGCyRia/dPOd6Xh9yPv8Bl1+SoaIwD+a/vlrOmGRUyOYu7MwUhc7CxqeaDZU13S4+EpA==
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-kVscqXk4OCp68SZ0dkgEKVi6/8ij300KBWTJq32P/dYeWTSwK41WyTxalN1eRmA5Z9UU/LX9D7FWSmV9SAYx6g==
etag@~1.8.1:
version "1.8.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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"
Bump matrix-appservice-bridge from 8.0.0 to 8.1.2 Bumps [matrix-appservice-bridge](https://github.com/matrix-org/matrix-appservice-bridge) from 8.0.0 to 8.1.2. - [Release notes](https://github.com/matrix-org/matrix-appservice-bridge/releases) - [Changelog](https://github.com/matrix-org/matrix-appservice-bridge/blob/8.1.2/CHANGELOG.md) - [Commits](https://github.com/matrix-org/matrix-appservice-bridge/compare/8.0.0...8.1.2) --- updated-dependencies: - dependency-name: matrix-appservice-bridge dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
2023-08-04 13:27:31 -04:00
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 13:03:06 -05:00
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
version "4.18.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
version "1.3.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==
fast-json-stable-stringify@^2.0.0:
version "2.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==
fast-levenshtein@^2.0.6, fast-levenshtein@~2.0.6:
version "2.0.6"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
fecha@^4.2.0:
version "4.2.3"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
file-entry-cache@^6.0.1:
version "6.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
finalhandler@1.2.0:
version "1.2.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-dm9s5Pw7Jc0GvMYbshN6zchCA9RgQlzzEZX3vylR9IqFfS8XciblUXOKfW6SiuJ0e13eDYZoZV5wdrev7P3Nwg==
dependencies:
flatted "^3.1.0"
rimraf "^3.0.2"
flat@^5.0.2:
version "5.0.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
version "3.2.7"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-5nqDSxl8nn5BSNxyR3n4I6eDmbolI6WT+QqR547RwxQapgjQBmtktdP+HTBb/a/zLsbzERTONyUB5pefh5TtjQ==
fn.name@1.x.x:
version "1.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-GRnmB5gPyJpAhTQdSZTSp9uaPSvl09KoYcMQtsB9rQoOmzs9dH6ffeccH+Z+cv6P68Hu5bC6JjRh4Ah/mHSNRw==
follow-redirects@^1.14.9:
version "1.15.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
forever-agent@~0.6.1:
version "0.6.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
form-data@^2.5.0:
version "2.5.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
form-data@^3.0.0:
version "3.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
form-data@^4.0.0:
version "4.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
form-data@~2.3.2:
version "2.3.3"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow==
fresh@0.5.2:
version "0.5.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==
fs.realpath@^1.0.0:
version "1.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-yIovAzMX49sF8Yl58fSCWJ5svSLuaibPxXQJFLmBObTuCr0Mf1KiPopGM9NiFjiYBCbfaa2Fh6breQ6ANVTI0A==
functional-red-black-tree@^1.0.1:
version "1.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
generate-function@^2.0.0:
version "2.3.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
get-intrinsic@^1.0.2:
version "1.1.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
getpass@^0.1.1:
version "0.1.7"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-lkX1HJXwyMcprw/5YUZc2s7DrpAiHB21/V+E1rHUrVNokkvB6bqMzT0VfV6/86ZNabt1k14YOIaT7nDvOX3Iiw==
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-08/xrJ7wQjK9kkkRoI3OFUBbLx4f+6x3SGwcPvQ0QH6goFDrOU2oyAWrmh3dJezu65buo+HBMzAMQy6rovVC3g==
dependencies:
type-fest "^0.20.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
version "4.2.8"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-qkIilPUYcNhJpd33n0GBXTB1MMPp14TxEsEs0pTrsSVucApsYzW5V+Q8Qxhik6KU3evy+qkAAowTByymK0avdg==
growl@1.10.5:
version "1.10.5"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-qBr4OuELkhPenW6goKVXiv47US3clb3/IbuWF9KNKEijAy9oeHxU9IgzjvJhHkUzhaj7rOUD7+YGWqUjLp5oSA==
har-schema@^2.0.0:
version "2.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-Oqluz6zhGX8cyRaTQlFMPw80bSJVG2x/cFb8ZPhUILGgHka9SsokCCOQgpveePerqidZOrT14ipqfJb7ILcW5Q==
har-validator@~5.1.3:
version "5.1.5"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-nmT2T0lljbxdQZfspsno9hgrG3Uir6Ks5afism62poxqBM6sDnMEuPmzTq8XN0OEwqKLLdh1jQI3qyE66Nzb3w==
dependencies:
ajv "^6.12.3"
har-schema "^2.0.0"
has-flag@^3.0.0:
version "3.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
has-flag@^4.0.0:
version "4.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
has-symbols@^1.0.3:
version "1.0.3"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
has@^1.0.3:
version "1.0.3"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-f2dvO0VU6Oej7RkWJGrehjbzMAjFp5/VKPp5tTpWIV4JHHZK1/BxbFRtf/siA2SWTe09caDmVtYYzWEIbBS4zw==
dependencies:
function-bind "^1.1.1"
hash.js@^1.1.7:
version "1.1.7"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-F/1DnUGPopORZi0ni+CvrCgHQ5FyEAHRLSApuYWMmrbSwoN2Mn/7k+Gl38gJnR7yyDZk6WLXwiGod1JOWNDKGw==
html-encoding-sniffer@^2.0.1:
version "2.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-D5JbOMBIR/TVZkubHT+OyT2705QvogUW4IBn6nHd756OwieSF9aDYFj4dv6HHEVGYbHaLETa3WggZYWWMyy3ZQ==
dependencies:
whatwg-encoding "^1.0.5"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
version "8.2.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
htmlencode@^0.0.4:
version "0.0.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-0uDvNVpzj/E2TfvLLyyXhKBRvF1y84aZsyRxRXFsQobnHaL4pcaXk+Y9cnFlvnxrBLeXDNq/VJBD+ngdBgQG1w==
htmlparser2@^6.0.0, htmlparser2@^6.1.0:
version "6.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-k0zdNgqWTGA6aeIRVpvfVob4fL52dTfaehylg0Y4UvSySvOq/Y+BOyPrgpUrA7HylqvU8vIZGsRuXmspskV0Tg==
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
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 13:49:33 -04:00
agent-base "6"
debug "4"
http-signature@~1.2.0:
version "1.2.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-JmXMZ6wuvDmLiHEml9ykzqO6lwFbof0GG4IkcGaENdCRDDmMVnny7s5HsIgHCbaq0w2MyPhDqkhTUgS2LU2PHA==
inflight@^1.0.4:
version "1.0.6"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
ip-address@^7.1.0:
version "7.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-ByY+tjCciCr+9nLryBYcSD50EOGWt95c7tIsKTG1J2ixKKXPvF7Ej3AVd+UfDydAJom3biBGDBALaO79ktwgEQ==
dependencies:
has "^1.0.3"
is-extglob@^2.1.1:
version "2.1.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==
is-plain-obj@^2.1.0:
version "2.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-YWnfyRwxL/+SsrWYfOpUtz5b3YD+nyfkHvjbcanzk8zgyO4ASD67uVMRt8k5bM4lLMDnXfriRhOpemw+NfT1eA==
is-plain-object@^5.0.0:
version "5.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-VRSzKkbMm5jMDoKLbltAkFQ5Qr7VDiTFGXxYFXXowVj387GeGNOCsOH6Msy00SGZ3Fp84b1Naa1psqgcCIEP5Q==
is-potential-custom-element-name@^1.0.1:
version "1.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-bCYeRA2rVibKZd+s2625gGnGF/t7DSqDs4dP7CrLA1m7jKWz6pps0LpYLJN8Q64HtmPKJ1hrN3nzPNKFEKOUiQ==
is-promise@^2.1.0:
version "2.2.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
is-typedarray@~1.0.0:
version "1.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-cyA56iCMHAh5CdzjJIa4aohJyeO1YbwLi3Jc35MmRU6poroFjIGZzUzupGiRPOjgHg9TLu43xbpwXk523fMxKA==
is-unicode-supported@^0.1.0:
version "0.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-knxG2q4UC3u8stRGyAVJCOdxFmv5DZiRcdlIaAQXAbSfJya+OhopNotLQrstBhququ4ZpuKbDc/8S6mgXgPFPw==
isexe@^2.0.0:
version "2.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
isstream@~0.1.2:
version "0.1.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-Yljz7ffyPbrLpLngrMtZ7NduUgVvi6wG9RJ9IUcyCd59YQ911PBJphODUcbOVbqYfxe1wuYf/LJ8PauMRwsM/g==
jest-diff@^27.2.4:
version "27.2.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-wbKT/BNGnBVB9nzi+IoaLkXt6fbSvqUxx+IYY66YFh96J3goY33BAaNG3uPqaw/Sh/FR9YpXGVDfd5DJdbh4nA==
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04:00
"@jest/types" "^27.2.4"
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
jsbn@~0.1.0:
version "0.1.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==
json-schema-traverse@^1.0.0:
version "1.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==
json-schema@0.4.0:
version "0.4.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-Bdboy+l7tA3OGW6FjyFHWkP5LuByj1Tk33Ljyq0axyzdk9//JSi2u3fP1QSmd1KNwq6VOKYGlAu87CisVir6Pw==
json-stringify-safe@~5.0.1:
version "5.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-ZClg6AaYvamvYEE82d3Iyd3vSSIjQ+odgjaTzRuO3s7toCdFKczob2i0zCh7JE8kWn17yvAWhUVxvqGwUalsRA==
json5@^1.0.1:
Bump json5 from 1.0.1 to 1.0.2 (#464) Bumps [json5](https://github.com/json5/json5) from 1.0.1 to 1.0.2. - [Release notes](https://github.com/json5/json5/releases) - [Changelog](https://github.com/json5/json5/blob/main/CHANGELOG.md) - [Commits](https://github.com/json5/json5/compare/v1.0.1...v1.0.2) --- updated-dependencies: - dependency-name: json5 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2023-01-05 05:37:02 -05:00
version "1.0.2"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/json5/-/json5-1.0.2.tgz"
Bump json5 from 1.0.1 to 1.0.2 (#464) Bumps [json5](https://github.com/json5/json5) from 1.0.1 to 1.0.2. - [Release notes](https://github.com/json5/json5/releases) - [Changelog](https://github.com/json5/json5/blob/main/CHANGELOG.md) - [Commits](https://github.com/json5/json5/compare/v1.0.1...v1.0.2) --- updated-dependencies: - dependency-name: json5 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2023-01-05 05:37:02 -05:00
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 13:49:33 -04:00
dependencies:
minimist "^1.2.0"
Config fixes (#432) * Use the npm package `config` to load the config. This is what was used prior to https://github.com/matrix-org/mjolnir/pull/347. It was a nice idea motivated to drop a dependency that was confusing. It was just never followed through and was underestimated how much disruption it would cause. It was also believed that the library would mean there could only ever be one global copy of the config, It was followed up by: https://github.com/matrix-org/mjolnir/pull/369 https://github.com/matrix-org/mjolnir/pull/357 https://github.com/matrix-org/mjolnir/pull/429 https://github.com/matrix-org/mjolnir/pull/397/files https://github.com/matrix-org/mjolnir/issues/365 For simplicity sake I am reinstating the library. The practice of loading default.yaml by default is also dangerous and has led to issues multiple times in #mjolnir:matrix.org. It is a sample and not a default. In a following commit I will be adding the ability to specify the config to use from the cli. * Allow config to be specified with an explicit cli argument. * Update doc to transition away from old config handling
2022-11-23 05:55:22 -05:00
json5@^2.2.1:
version "2.2.1"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/json5/-/json5-2.2.1.tgz"
Config fixes (#432) * Use the npm package `config` to load the config. This is what was used prior to https://github.com/matrix-org/mjolnir/pull/347. It was a nice idea motivated to drop a dependency that was confusing. It was just never followed through and was underestimated how much disruption it would cause. It was also believed that the library would mean there could only ever be one global copy of the config, It was followed up by: https://github.com/matrix-org/mjolnir/pull/369 https://github.com/matrix-org/mjolnir/pull/357 https://github.com/matrix-org/mjolnir/pull/429 https://github.com/matrix-org/mjolnir/pull/397/files https://github.com/matrix-org/mjolnir/issues/365 For simplicity sake I am reinstating the library. The practice of loading default.yaml by default is also dangerous and has led to issues multiple times in #mjolnir:matrix.org. It is a sample and not a default. In a following commit I will be adding the ability to specify the config to use from the cli. * Allow config to be specified with an explicit cli argument. * Update doc to transition away from old config handling
2022-11-23 05:55:22 -05:00
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 13:03:06 -05:00
jsonpointer@^5.0.0:
version "5.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
jsprim@^1.2.2:
version "1.4.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 11:09:55 -05:00
layerr@^0.1.2:
version "0.1.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 11:09:55 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-iPZK6eYjbxRu3uB4/WZ3EsEIMJFMqAoopl3R+zuq0UjcAm/MO6KCweDgPfP3elTztoKP3KtnVHxTn2NHBSDVUw==
dependencies:
p-locate "^5.0.0"
lodash.clonedeep@^4.5.0:
version "4.5.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==
lodash.truncate@^4.4.2:
version "4.4.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
version "1.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
lru-cache@^7.10.1:
version "7.13.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-CHqbAq7NFlW3RSnoWXLJBxCWaZVBrfa9UEHId2M3AW8iEBurbqduNexEUCGc3SHc6iCYXNJCDi903LajSVAEPQ==
Very basic support for Sentry. (#398) The Sentry package is very useful for monitoring runtime errors. With this PR, we simply add the necessary mechanism to: - log to sentry any uncaught error that reaches the toplevel, including startup errors.
2022-11-30 10:06:02 -05:00
lru_map@^0.3.3:
version "0.3.3"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/lru_map/-/lru_map-0.3.3.tgz"
Very basic support for Sentry. (#398) The Sentry package is very useful for monitoring runtime errors. With this PR, we simply add the necessary mechanism to: - log to sentry any uncaught error that reaches the toplevel, including startup errors.
2022-11-30 10:06:02 -05:00
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 13:49:33 -04:00
make-error@^1.1.1:
version "1.3.6"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-s8UhlNe7vPKomQhC1qFelMokr/Sc3AgNbso3n74mVPA5LTZwkB9NlXf4XPamLxJE8h0gh73rM94xvwRT2CVInw==
Bump matrix-appservice-bridge from 8.0.0 to 8.1.2 Bumps [matrix-appservice-bridge](https://github.com/matrix-org/matrix-appservice-bridge) from 8.0.0 to 8.1.2. - [Release notes](https://github.com/matrix-org/matrix-appservice-bridge/releases) - [Changelog](https://github.com/matrix-org/matrix-appservice-bridge/blob/8.1.2/CHANGELOG.md) - [Commits](https://github.com/matrix-org/matrix-appservice-bridge/compare/8.0.0...8.1.2) --- updated-dependencies: - dependency-name: matrix-appservice-bridge dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
2023-08-04 13:27:31 -04:00
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==
Absolute bare minimum for a bot
2019-09-25 22:13:20 -04: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 13:03:06 -05:00
"@alloc/quick-lru" "^5.2.0"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
"@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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
express "^4.18.1"
Bump matrix-appservice-bridge from 8.0.0 to 8.1.2 Bumps [matrix-appservice-bridge](https://github.com/matrix-org/matrix-appservice-bridge) from 8.0.0 to 8.1.2. - [Release notes](https://github.com/matrix-org/matrix-appservice-bridge/releases) - [Changelog](https://github.com/matrix-org/matrix-appservice-bridge/blob/8.1.2/CHANGELOG.md) - [Commits](https://github.com/matrix-org/matrix-appservice-bridge/compare/8.0.0...8.1.2) --- updated-dependencies: - dependency-name: matrix-appservice-bridge dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
2023-08-04 13:27:31 -04:00
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 13:03:06 -05:00
extend "^3.0.2"
ip-cidr "^3.0.4"
is-my-json-valid "^2.20.5"
js-yaml "^4.0.0"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
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 13:03:06 -05:00
nedb "^1.8.0"
nopt "^5.0.0"
p-queue "^6.6.2"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
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 13:03:06 -05:00
uuid "^8.3.2"
winston "^3.3.3"
winston-daily-rotate-file "^4.5.1"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
matrix-appservice@^1.1.0:
version "1.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/matrix-appservice/-/matrix-appservice-1.1.0.tgz"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
js-yaml "^4.1.0"
morgan "^1.10.0"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
matrix-bot-sdk@^0.6.2:
version "0.6.2"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/matrix-bot-sdk/-/matrix-bot-sdk-0.6.2.tgz"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
media-typer@0.3.0:
version "0.3.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-dq+qelQ9akHpcOl/gUVRTxVIOkAJ1wR3QAvb4RsVjS8oVoFjDGTc679wJYmUmknUF5HwMLOgb5O+a3KxfWapPQ==
merge-descriptors@1.0.1:
version "1.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-cCi6g3/Zr1iqQi6ySbseM1Xvooa98N0w31jzUYrXPX2xqObmFGHJ0tQ5u74H3mVh7wLouTseZyYIq39g8cNp1w==
methods@~1.1.2:
version "1.1.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
mime-db@1.52.0:
version "1.52.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-9Uq1ChtSZO+Mxa/CL1eGizn2vRn3MlLgzhT0Iz8zaY8NdvxvB0d5QdPFmCKf7JKA9Lerx5vRrnwO03jsSfGG9g==
dependencies:
brace-expansion "^1.1.7"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
version "3.1.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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:
Bump json5 from 1.0.1 to 1.0.2 (#464) Bumps [json5](https://github.com/json5/json5) from 1.0.1 to 1.0.2. - [Release notes](https://github.com/json5/json5/releases) - [Changelog](https://github.com/json5/json5/blob/main/CHANGELOG.md) - [Commits](https://github.com/json5/json5/compare/v1.0.1...v1.0.2) --- updated-dependencies: - dependency-name: json5 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2023-01-05 05:37:02 -05:00
version "1.2.7"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/minimist/-/minimist-1.2.7.tgz"
Bump json5 from 1.0.1 to 1.0.2 (#464) Bumps [json5](https://github.com/json5/json5) from 1.0.1 to 1.0.2. - [Release notes](https://github.com/json5/json5/releases) - [Changelog](https://github.com/json5/json5/blob/main/CHANGELOG.md) - [Commits](https://github.com/json5/json5/compare/v1.0.1...v1.0.2) --- updated-dependencies: - dependency-name: json5 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2023-01-05 05:37:02 -05:00
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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-L6XC3EdwT6YrIk0yXpavvLkn8h+EU+Y5UcCHKECyMbdUIxyMuZj4bX4U9e1nvnvUUvQVsV2VHQr5zLdcUkhW/g==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
dependencies:
Update packages
2021-07-01 15:45:28 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-+EUsqGPLsM+j/zdChZjsnX51g4XrHFOIXwfnCVPGlQk/k5giakcKsuxCObBRu6DSm9opw/O6slWbJdghQM4bBg==
node-downloader-helper@^2.1.1:
version "2.1.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
on-finished@~2.3.0:
version "2.3.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-rhIwUycgwwKcP9yTOOFK/AKsAopjjCakVqLHePO3CC6Mir1Z99xT+R63jZxAT5lFZLa2inS5h+ZS2GvR99/FBg==
dependencies:
p-finally "^1.0.0"
packet-reader@1.0.0:
version "1.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-Dg27N6mfok+ow1a2rj/nRjtCfaKrHUZV2SJpEn/s8GaVUSlf4GGRCRP1c13Hj+wfPKVMrFDqLMLITkYKgKxyyg==
parse-srcset@^1.0.2:
version "1.0.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==
path-is-absolute@^1.0.0:
version "1.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-AVbw3UJ2e9bq64vSaS9Am0fje1Pa8pbGqTTsmXfaIiMpnr5DlDhfJOuLj9Sf95ZPVDAUerDfEk88MPmPe7UCQg==
path-key@^3.1.0:
version "3.1.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==
path-parse@^1.0.6:
version "1.0.7"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==
path-to-regexp@0.1.7:
version "0.1.7"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-5DFkuoqlv1uYQKxy8omFBeJPQcdoE07Kv2sferDCrAq1ohOU+MSDswDIbnx3YAM60qIOnYa53wBhXW0EbMonrQ==
performance-now@^2.1.0:
version "2.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
pg-connection-string@^2.5.0:
version "2.5.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-r5o/V/ORTA6TmUnyWZR9nCj1klXCO2CEKNRlVuJptZe85QuhFayC7WeMic7ndayT5IRIR0S0xFxFi2ousartlQ==
pg-int8@1.0.1:
version "1.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-WCtabS6t3c8SkpDBUlb1kjOs7l66xsGdKpIPZsg4wR+B3+u9UAum2odSsF9tnvxg80h4ZxLWMy4pRjOsFIqQpw==
pg-pool@^3.5.2:
version "3.5.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-His3Fh17Z4eg7oANLob6ZvH8xIVen3phEZh2QuyrIl4dQSDVEabNducv6ysROKpDNPSD+12tONZVWfSgMvDD9w==
pg-protocol@*, pg-protocol@^1.5.0:
version "1.5.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-muRttij7H8TqRNu/DxrAJQITO4Ac7RmX3Klyr/9mJEOBeIpgnF8f9jAfRz5d3XwQZl5qBjF9gLsUtMPJE0vezQ==
pg-types@^2.1.0, pg-types@^2.2.0:
version "2.2.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-lY1Q/PiJGC2zOv/z391WOTD+Z02bCgsFfvxoXXf6h7kv9o+WmsmzYqrAwY63sNgOxE4xEdq0WyUnXfKeBrSvYw==
pify@^3.0.0:
version "3.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-C3FsVNH1udSEX48gGX1xfvwTWfsYWj5U+8/uK15BGzIGrKoUpghX8hWZwa/OFnakBiiVNmBvemTJR5mcy7iPcg==
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
pkginfo@^0.4.1:
version "0.4.1"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/pkginfo/-/pkginfo-0.4.1.tgz"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-VpZrUqU5A69eQyW2c5CA1jtLecCsN2U/bD6VilrFDWq5+5UIEVO7nazS3TEcHf1zuPYO/sqGvUvW62g86RXZuA==
postgres-bytea@~1.0.0:
version "1.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-xy3pmLuQqRBZBXDULy7KbaitYqLcmxigw14Q5sj8QBVLqEwXfeybIKVWiqAXTlcvdvb0+xkOtDbfQMOf4lST1w==
postgres-date@~1.0.4:
version "1.0.7"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-suDmjLVQg78nMK2UZ454hAG+OAW+HQPZ6n++TNDUX+L0+uUlLywnoxJKDou51Zm+zTCjrCl0Nq6J9C5hP9vK/Q==
postgres-interval@^1.1.0:
version "1.2.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
postgres@^3.3.1:
version "3.3.2"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/postgres/-/postgres-3.3.2.tgz"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-7PiHtLll5LdnKIMw100I+8xJXR5gW2QwWYkT6iJva0bXitZKa/XMrSbdmg3r2Xnaidz9Qumd0VPaMrZlF9V9sA==
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
prom-client@^14.1.0:
version "14.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04:00
resolved "https://registry.npmjs.org/prom-client/-/prom-client-14.1.0.tgz"
Gnuxie/appservice logging (#441) * upgrade to matrix-appservice-bridge 8.0.0 this is so we can use their new logger * Configure and use matrix-appservice-bridge's `Logger` https://github.com/matrix-org/mjolnir/issues/422 Haven't changed all of the mjolnir components to use this, just the appservice. The fact that we've configured this properly means we get logging from matrix-appservice-bridge components too (we didn't before). * use try/catch instead
2022-11-30 08:30:38 -05:00
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 13:03:06 -05:00
dependencies:
tdigest "^0.1.1"
Bump express from 4.17.1 to 4.17.3 (#455) Bumps [express](https://github.com/expressjs/express) from 4.17.1 to 4.17.3. - [Release notes](https://github.com/expressjs/express/releases) - [Changelog](https://github.com/expressjs/express/blob/master/History.md) - [Commits](https://github.com/expressjs/express/compare/4.17.1...4.17.3) --- updated-dependencies: - dependency-name: express dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2022-12-08 11:19:00 -05:00
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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-b/YwNhb8lk1Zz2+bXXpS/LK9OisiZZ1SNsSLxN1x2OXVEhW2Ckr/7mWE5vrC1ZTiJlD9g19jWszTmJsB+oEpFQ==
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
version "1.8.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
version "6.5.3"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
require-from-string@^2.0.2:
version "2.0.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-Xf0nWe6RseziFMu+Ap9biiUbmplq6S9/p+7w7YXP/JBHhrUDDUhwa+vANyubuqfZWTveU//DYVGsDG7RKL/vEw==
resolve-from@^4.0.0:
version "4.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-pb/MYmXstAkysRFx8piNI1tGFNQIFA3vkE3Gq4EuA1dF6gHp/+vgZqsCGJapvy8N3Q+4o7FwvquPJcnZ7RYy4g==
resolve@^1.3.2:
version "1.20.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-TTlYpa+OL+vMMNG24xSlQGEJ3B/RzEfUlLct7b5G/ytav+wPrplCpVMFuwzXbkecJrb6IYo1iFb0S9v37754mg==
rimraf@^3.0.2:
version "3.0.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
sanitize-html@^2.7.0:
version "2.7.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-ibqWGV5aChDvfVdqNYuaJP/HnVBhlRGSRrlbttmlMpHcLuTqqbMH36QkSs9GEgj5M88JDYLI8eyP94JaQ8xRlg==
dependencies:
parseley "^0.7.0"
semver@^5.3.0, semver@^5.6.0:
Bump semver from 5.7.1 to 5.7.2 Bumps [semver](https://github.com/npm/node-semver) from 5.7.1 to 5.7.2. - [Release notes](https://github.com/npm/node-semver/releases) - [Changelog](https://github.com/npm/node-semver/blob/v5.7.2/CHANGELOG.md) - [Commits](https://github.com/npm/node-semver/compare/v5.7.1...v5.7.2) --- updated-dependencies: - dependency-name: semver dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
2023-07-12 10:45:11 -04:00
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 13:49:33 -04:00
semver@^7.2.1:
Bump semver from 5.7.1 to 5.7.2 Bumps [semver](https://github.com/npm/node-semver) from 5.7.1 to 5.7.2. - [Release notes](https://github.com/npm/node-semver/releases) - [Changelog](https://github.com/npm/node-semver/blob/v5.7.2/CHANGELOG.md) - [Commits](https://github.com/npm/node-semver/compare/v5.7.1...v5.7.2) --- updated-dependencies: - dependency-name: semver dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
2023-07-12 10:45:11 -04:00
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 13:49:33 -04: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 13:03:06 -05:00
send@0.18.0:
version "0.18.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
serve-static@1.15.0:
version "1.15.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
shebang-command@^2.0.0:
version "2.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==
dependencies:
shebang-regex "^3.0.0"
shebang-regex@^3.0.0:
version "3.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
side-channel@^1.0.4:
version "1.0.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-g9Q1haeby36OSStwb4ntCGGGaKsaVSjQ68fBxoQcutl5fS1vuY18H3wSt3jFyFtrkx+Kz0V1G85A4MyAdDMi2Q==
slice-ansi@^4.0.0:
version "4.0.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
split2@^4.1.0:
version "4.1.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05:00
integrity sha512-VBiJxFkxiXRlUIeyMQi8s4hgvKCSjtknJv/LVYbrgALPwf5zSKmEwV9Lst25AkvMDnvxODugjdl6KZgwKM1WYQ==
sprintf-js@1.1.2:
version "1.1.2"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
sprintf-js@~1.0.2:
version "1.0.3"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05:00
version "1.17.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
statuses@2.0.1:
version "2.0.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
stealthy-require@^1.1.1:
version "1.1.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-ZnWpYnYugiOVEY5GkcuJK1io5V8QmNYChG62gSit9pQVGErXtrKuPC55ITaVSukmMta5qpMU7vqLt2Lnni4f/g==
steno@^0.4.1:
version "0.4.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==
dependencies:
has-flag "^4.0.0"
symbol-tree@^3.2.4:
version "3.2.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-9QNk5KwDF+Bvz+PyObkmSYjI5ksVUYtjW7AU22r2NKcfLJcXp96hkDWU3+XndOsUb+AQ9QhfzfCT2O+CNWT5Tw==
table@^6.0.9:
version "6.7.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-tHdtEpQCMrc1YLrMaqXXcj6AxhYi/xgit6mZu1+EDWUn+qhUf8wMQoFIy9NXuq23zAwtcB0t/MjACGR18pcRbg==
dependencies:
psl "^1.1.33"
punycode "^2.1.1"
universalify "^0.1.2"
load config yaml manually, remove more references to static config (#347)
2022-08-16 10:51:18 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-15Ih7phfcdP5YxqiB+iDtLoaTz4Nd35+IiAv0kQ5FNKHzXgdWqPoTIqEDDJmXceQt4JZk6lVPT8lnDlPpGDppw==
dependencies:
punycode "^2.1.1"
load config yaml manually, remove more references to static config (#347)
2022-08-16 10:51:18 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-WyQjvnzwrrubl0JT7EC1yWmNpcsU3fOuBFfdps30zbmFBgKniSaSOyZMZx+Wq7kytUs5CY+pEbSYEbGfIKnXTw==
dependencies:
ts-node "7.0.1"
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-7ecdYDnIdmv639mmDwslG6KQg1Z9STTz1j7Gcz0xa+nshh/gKDAHcPxRbWOsA3SPp0tXP2leTcY9Kw+NAkfZzA==
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
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 13:49:33 -04:00
json5 "^1.0.1"
minimist "^1.2.0"
strip-bom "^3.0.0"
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
Very basic support for Sentry. (#398) The Sentry package is very useful for monitoring runtime errors. With this PR, we simply add the necessary mechanism to: - log to sentry any uncaught error that reaches the toplevel, including startup errors.
2022-11-30 10:06:02 -05:00
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 13:49:33 -04:00
version "1.14.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04:00
integrity sha512-Xni35NKzjgMrwevysHTCArtLDpPvye8zV/0E4EyYn43P7/7qvQwPh9BGkHewbMulVntbigmcT7rdX3BNo9wRJg==
Update packages
2020-04-14 18:17:05 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-IbR4nkT96EQOvKE2PW/djGz8iGNeJ4rF2mBfiYaR/nvUWYKJhLwimoJKgjIFEIDibBtOevj7BqCRL4oHeWWUCg==
Absolute bare minimum for a bot
2019-09-25 22:13:20 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-g5JVHCIJwzfISaXpXE1qvNalca5Jwob6FjI4AoPlqMusJ6ftFE7IkkFoMhVLRgK+4Kx3gkzb8UZK5t5yTTvEmA==
dependencies:
tslib "^1.8.1"
tunnel-agent@^0.6.0:
version "0.6.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-Ne+eE4r0/iWnpAxD852z3A+N0Bt5RN//NjJwRd2VFHEmrywxf5vsZlh4R6lixl6B+wz/8d+maTSAkN1FIkI3LQ==
Bump express from 4.17.1 to 4.17.3 (#455) Bumps [express](https://github.com/expressjs/express) from 4.17.1 to 4.17.3. - [Release notes](https://github.com/expressjs/express/releases) - [Changelog](https://github.com/expressjs/express/blob/master/History.md) - [Commits](https://github.com/expressjs/express/compare/4.17.1...4.17.3) --- updated-dependencies: - dependency-name: express dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2022-12-08 11:19:00 -05:00
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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05:00
typescript@^4.8.4:
version "4.8.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 11:09:55 -05:00
ulidx@^0.3.0:
version "0.3.0"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 11:09:55 -05: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 13:03:06 -05:00
underscore@~1.4.4:
version "1.4.4"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:03:06 -05: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 13:49:33 -04:00
Bump node version to 18 (#496) * try win dns res * add dns hack to application service tests * fix unused import * update types * add note about why dns resolution order is necessary
2023-11-14 15:52:53 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-pjy2bYhSsufwWlKwPc+l3cN7+wuJlK6uz0YdJEOlQDbl6jo/YlPi4mb8agUkVC8BF7V8NuzeyPNqRksA3hztKQ==
uri-js@^4.2.2:
version "4.4.1"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
word-wrap@^1.2.3, word-wrap@~1.2.3:
Bump word-wrap from 1.2.3 to 1.2.4 Bumps [word-wrap](https://github.com/jonschlinkert/word-wrap) from 1.2.3 to 1.2.4. - [Release notes](https://github.com/jonschlinkert/word-wrap/releases) - [Commits](https://github.com/jonschlinkert/word-wrap/compare/1.2.3...1.2.4) --- updated-dependencies: - dependency-name: word-wrap dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
2023-07-18 23:47:38 -04:00
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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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"
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==
Bump yaml from 2.1.1 to 2.2.2 Bumps [yaml](https://github.com/eemeli/yaml) from 2.1.1 to 2.2.2. - [Release notes](https://github.com/eemeli/yaml/releases) - [Commits](https://github.com/eemeli/yaml/compare/v2.1.1...v2.2.2) --- updated-dependencies: - dependency-name: yaml dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
2023-04-25 16:21:21 -04:00
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 13:49:33 -04:00
Update yarn lockfile
2023-04-03 16:03:02 -04: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04: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 13:03:06 -05: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 13:49:33 -04:00
integrity sha512-rVksvsnNCdJ/ohGc6xgPwyN8eheCxsiLM8mxuE/t/mOVqJewPuO1miLpTHQiRgTKCLexL4MeAFVagts7HmNZ2Q==
Reference in New Issue Copy Permalink