Bug 1154724 - Load and mark restricted bugs with an api key - #92
Open
rvandermeulen wants to merge 3 commits into
Open
Bug 1154724 - Load and mark restricted bugs with an api key#92rvandermeulen wants to merge 3 commits into
rvandermeulen wants to merge 3 commits into
Conversation
rvandermeulen
force-pushed
the
restricted-bugs
branch
from
August 13, 2026 21:33
5e5bee7 to
678a6ac
Compare
bz.js appended the key to the request URL, putting it into Bugzilla's access logs on every privileged request. BMO accepts X-BUGZILLA-API-KEY and allows it via CORS on both the GET and PUT preflights, so send it there instead. Invalid keys still come back as the same error 306 message the submit path already matches on.
…pi key Bugherder loads bug data anonymously, so bugs restricted to a Bugzilla group are silently dropped and can only be reported at the end for someone to mark by hand afterwards. Offer to load them with an api key instead, then rerun the usual flow over just those bugs. The key is reused for the submission, so it is only asked for once, and the sheriff pass is unaffected: without a key nothing loads and the push is presented exactly as before. Loading also skips pushes that reached backedOut without a bug number of their own, and stops the same bug being requested twice, so that the count of bugs that could not be loaded is accurate rather than counting an absent bug number as a restricted bug.
A security bug is filed in one of the core-security groups and moves to core-security-release once the fix has landed, so that it is tracked for the release advisories. Offer that move as a checkbox alongside the resolution, ticked by default and following the resolve flag, since it is the landing that makes it due. Only the core-security groups are moved out of. A bug can be restricted for reasons that have nothing to do with the fix shipping, and those restrictions are left as they are. The group list comes from the Bugzilla configuration that is already loaded, so a group that gets renamed away leaves the checkbox switched off rather than failing every submission.
rvandermeulen
force-pushed
the
restricted-bugs
branch
from
August 13, 2026 21:34
678a6ac to
e2162b3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bugherder loads bug data anonymously, so bugs restricted to a Bugzilla group can't be loaded
and can't be marked. Sheriffs generally can't see them either, so today they're reported at the
end of the run as a table of changesets for someone in Release Management to work through by
hand: copying the hg URL into each bug, setting the flags, and moving the security group.
This adds an optional pass for that. When a push contains bugs that couldn't be loaded, bugherder
offers to load them with an api key. Supply one belonging to an account that can see them and it
reruns the normal flow with everything except those bugs filtered out, so they get the same
commenting, resolving and flag setting as anything else. The key is reused for the submission, so
it's only asked for once.
None of this changes the sheriff pass. Without a key nothing loads and the push is presented
exactly as before.
Commits
bz.jsappended thekey to the request URL, putting it in Bugzilla's access logs on every privileged request. BMO
accepts
X-BUGZILLA-API-KEYand allows it via CORS on both the GET and PUT preflights.needs no heuristic: bugherder always loads anonymously, so "requested but not returned" is
exactly "what the sheriff's run couldn't touch".
resolution, ticked where the push puts the fix in the tree. Only the
core-securityandper-area
<area>-core-securitygroups are moved out of; a bug restricted for unrelated reasonskeeps that restriction.
Testing
Run against four live mozilla-central merges, submitting real changes each time. The first caught
a restricted bug that had been missed during an earlier manual pass. Also exercised the
groups-only update path, where the bugs were already resolved and commented by a previous run so
the group move is all that's left to send.
Not yet exercised live: a restricted bug sitting on a backed-out changeset. The group-move box
should render unticked there, alongside the offer to reopen.
npm testisn't included: karma can't capture a browser in the environment this was developed in,and the existing suite covers only
FlagLoaderandPushData.checkIfBackout, neither of which istouched here.