Repository navigation
feat: Guard against nil response in code security attach methods - #4696
LemonCondor wants to merge 1 commit into
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
Hi @LemonCondor - thank you for your PR. Unfortunately, this PR has two committers to it:
and since anthropic is never going to sign the CLA, you have two options:
Sorry for the inconvenience. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #4696 +/- ##
==========================================
+ Coverage 98.63% 98.64% +0.01%
==========================================
Files 201 203 +2
Lines 18912 19027 +115
==========================================
+ Hits 18653 18769 +116
+ Misses 259 258 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
EnterpriseService.AttachCodeSecurityConfigurationToRepositories and OrganizationsService.AttachCodeSecurityConfigurationToRepositories dereference resp.StatusCode when Do returns an error. Client.Do can return a nil *Response together with a non-nil error (e.g. a transport error or a canceled context), which makes these methods panic with a nil pointer dereference instead of returning the error. Add the `resp == nil ||` guard already used by the canonical form of this pattern elsewhere in the package (e.g. AppsService.DeleteInstallation in apps.go), and add regression tests that drive the Do-failure path with a canceled context.
22a1fcc to
e08f70d
Compare
nil response in code security attach methods
EnterpriseService.AttachCodeSecurityConfigurationToRepositoriesandOrganizationsService.AttachCodeSecurityConfigurationToRepositoriesdereferenceresp.StatusCodeas soon asDoreturns an error:Client.Docan return a nil*Responsetogether with a non-nil error — for example on a transport error, or when the request context is canceled (bareDoreturns(nil, ctx.Err())). In those cases the check above panics with a nil pointer dereference instead of returning the error to the caller.The intent of the check is only to swallow the expected
202 Acceptedfor these async "attach" endpoints. The canonical, nil-safe form of exactly this pattern is already used elsewhere in the package, e.g.AppsService.DeleteInstallationinapps.go:This PR adds the missing
resp == nil ||guard to both code-security methods and adds regression tests that drive theDo-failure path with a canceled context (the existing tests only reach theDo-failure path via aNewRequestfailure, which returns before the buggy line, so the crash was uncovered).Disclosure
This was found and prepared during LLM-assisted code review using GitHub Security Researcher, an open-source code-analysis tool I maintain. I reviewed the change myself, confirmed the nil-return paths in
bareDo/Do, and verifiedgo vetand the affected tests pass locally.