Bump loader-utils from 1.4.0 to 1.4.2 - #2
Conversation
Bumps [loader-utils](https://github.com/webpack/loader-utils) from 1.4.0 to 1.4.2. - [Release notes](https://github.com/webpack/loader-utils/releases) - [Changelog](https://github.com/webpack/loader-utils/blob/v1.4.2/CHANGELOG.md) - [Commits](webpack/loader-utils@v1.4.0...v1.4.2) --- updated-dependencies: - dependency-name: loader-utils dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
|
@dependabot recreate |
|
Looks like this PR is closed. If you re-open it I'll rebase it as long as no-one else has edited it (you can use |
|
@dependabot reopen |
|
Dependabot tried to reopen this PR, but was told that it no longer has any history in common with the base branch (and therefore couldn't be reopened). |
|
@dependabot recreate |
|
Looks like this PR is closed. If you re-open it I'll rebase it as long as no-one else has edited it (you can use |
|
@dependabot rebase |
|
Looks like this PR is closed. If you re-open it, I'll rebase it, as long as no-one else has edited it. |
|
@dependabot reopen |
|
Dependabot tried to reopen this PR, but was told that it no longer has any history in common with the base branch (and therefore couldn't be reopened). |
|
@dependabot recreate |
|
Looks like this PR is closed. If you re-open it I'll rebase it as long as no-one else has edited it (you can use |
|
@dependabot reopen |
|
Dependabot tried to reopen this PR, but was told that it no longer has any history in common with the base branch (and therefore couldn't be reopened). |
|
@dependabot rebase |
|
Looks like this PR is closed. If you re-open it, I'll rebase it, as long as no-one else has edited it. |
The /api reference renders each endpoint's accepted credentials from a hardcoded map of security scheme name to prose, falling back to the raw scheme name on a miss. The engine is splitting the scope-blind `ApplicationAuth` scheme into `AdminApplicationKey` and `CIApplicationKey`, so every endpoint on the page would read as a camel-case identifier once that schema syncs here. Add both labels. `ApplicationAuth` stays: `public/api-schemas.json` is synced from the engine by a bot on its own schedule, so the shipped schema still names it until that lands. Verified against the regenerated schema rather than assumed: building the site with it renders 61 "Admin Application Key", 14 "CI Application Key" and 60 "GitHub Token" badges, and no raw scheme names. Related to MRGFY-8646 --- ## Left out on purpose Four things surfaced while verifying this. None are regressions from these lines. Flagging rather than widening the diff. 1. **Open, but a copy decision — `src/pages/api/index.astro:47`** hardcodes "All endpoints require a Bearer token. Two authentication methods are supported: Application Key, GitHub Token". Once the schema syncs, the badges read `Admin Application Key` / `CI Application Key`, so the intro introduces a name the badges never use. Worth being precise: unlike #2 this is **not factually wrong** — there really are two auth *methods*, one of which has two scopes — it is a naming mismatch, which makes it lower priority. The right rewording depends on the same scope answer as #2, so it is deliberately not in this PR. Separately, the "All endpoints require a Bearer token" half of that sentence is *already* false on `main`, independent of any of this: `GET /badges/{owner}/{repository}`, `.png` and `.svg` publish no `security` at all. Pre-existing, belongs in the same rewrite whenever someone takes it. 2. **Not a docs fix — `src/content/docs/api/usage.mdx:42`** says the `admin` scope grants "Full access to all API endpoints", which the new schema contradicts: `PUT` and `POST /repos/{owner}/{repository}/pulls/{number}/scopes` declare `CIApplicationKey` only, and `get_by_key_and_scopes` filters on strict scope membership with no superset, so an admin key really is refused. Deliberately **not** touched here: whether `admin` ought to subsume `ci` is a product question. If the intent is "admin can do everything" then the engine is wrong and this line is right. Being raised with Mehdi on the monorepo side. 3. **Fixed at the source, no action here.** Badge order was not deterministic: 45 operations emitted `(AdminApplicationKey, GitHubTokenBearerAuth)` and 4 the reverse, for the same OR-set. Now canonical for every operation in Mergifyio/monorepo#38586, plus the future and internal specs. My first guess at the cause was wrong — it is not set iteration in the new rewrite and it predates it: FastAPI emits requirements in dependency-resolution order, and the 4 outliers carry a delegation role whose injected guard takes the logged user before the application dependency. Fixed there rather than sorted here, so the live `openapi.json` and generated clients get it too. 4. **Noted, no action wanted.** The engine ships a `description` per scheme ("`admin` scope, reaches every endpoint" / "`ci` scope, reaches CI Insights endpoints only", both linking to the usage page). `Endpoint.astro` renders only the badge label, so it does not surface *on this page* — correcting my earlier phrasing, that copy is not dead: it reaches `api.mergify.com/v1/openapi.json`, generated clients, and Scalar/Swagger-style renderers. Not rendering it here is the intended state. I also skipped a test asserting every scheme in the shipped schema has a label. It would turn the schemas-sync bot PR red for a cosmetic label and block the config and CLI schema syncs riding along in it, in exchange for replacing a graceful fallback with a hard failure.
2 participants
Bumps loader-utils from 1.4.0 to 1.4.2.
Release notes
Sourced from loader-utils's releases.
Changelog
Sourced from loader-utils's changelog.
Commits
331ad50chore(release): 1.4.217cbf8ffix: ReDoS problem (#226)8f082b3chore(release): 1.4.14504e34fix: security problem (#220)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)@dependabot use these labelswill set the current labels as the default for future PRs for this repo and language@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language@dependabot use this milestonewill set the current milestone as the default for future PRs for this repo and languageYou can disable automated security fix PRs for this repo from the Security Alerts page.