fix(blocks): stop base64 from wrapping the git auth header - #88
Conversation
base64 wraps at 76 cols by default, so a long enough token put a newline inside the AUTHORIZATION extraheader. Newer curl (in the updated runner image) rejects headers with embedded newlines, so git pull died with 'Failed sending HTTP request' before sending. Strip the newline with 'tr -d \n', matching the pattern already used in update-skills. No-op for short tokens (no wrap), so the currently-working App-token path is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📜 Recent review details⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
🔇 Additional comments (3)
📝 WalkthroughWalkthroughThree composite GitHub Actions used for version bumping and synchronization are updated to remove newlines from base64-encoded authentication tokens. The ChangesGitHub Actions authentication header newline cleanup
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
📄 README may need an updateThis PR introduces changes that might not be reflected in Reason:
|
There was a problem hiding this comment.
Pull request overview
This PR fixes intermittent git pull/git push failures in several GitHub Actions “blocks” by ensuring the Base64-encoded HTTP Authorization header value never contains embedded newlines (which can happen when base64 wraps output at 76 chars on some platforms and can be rejected by newer curl versions).
Changes:
- Strip newline characters from the Base64-encoded
x-access-token:${TOKEN}value via| tr -d '\n'. - Apply the same header-hardening already used in
update-skillsto the remaining affected blocks. - Update all occurrences of the
http.https://github.com/.extraheaderauth header construction in the targeted blocks.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| .github/blocks/bump-npm-version/action.yaml | Prevent wrapped Base64 output from injecting a newline into the GitHub auth header. |
| .github/blocks/bump-monorepo-versions/action.yaml | Prevent wrapped Base64 output from injecting a newline into the GitHub auth header during version bump/push. |
| .github/blocks/sync-crates-version/action.yaml | Prevent wrapped Base64 output from injecting a newline into the GitHub auth header for crate version sync workflows. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Hi — I was trying to work out why a release wouldn't publish, and I think I found a small thing. Writing down what I saw in case I got part of it wrong.
What I saw
A release failed at
git pullwith:The odd part: it failed in about 60 milliseconds. That felt too fast to be a network or GitHub problem — almost like the request never actually left the machine.
What I think is going on
These blocks build a git auth header like this:
AUTH=$(echo -n "x-access-token:${TOKEN}" | base64)I learned that
base64on Linux adds a line break every 76 characters by default. So if the token is long enough,$AUTHends up with a newline sitting in the middle of it. That newline goes straight into an HTTP header — and newer versions of curl refuse to send a header that has a newline in it. So the pull dies before it even tries to connect.That also seems to explain two things I was confused about:
base64never wraps it. The one that broke was falling back to a longer token, which tipped it past 76 characters.The fix
Just strip the newlines — which is what
update-skills/action.yamlalready does:AUTH=$(echo -n "x-access-token:${TOKEN}" | base64 | tr -d '\n')I copied that exact line since it's already in the repo, so this is just making the other blocks match.
Why I don't think this breaks anything
For short tokens,
base64doesn't add a newline at all, sotr -d '\n'does nothing and those releases behave exactly as before. It only changes the long-token case — which is the one that's currently broken. So I believe it's safe, but I'd appreciate a second pair of eyes.Changed the three blocks that were missing it:
bump-npm-versionbump-monorepo-versionssync-crates-version(
update-skillsalready had the fix.update-docsandswift-buildput the token in the URL instead of a base64 header, so they aren't affected.)Did I get this right?
🤖 Generated with Claude Code
Need help on this PR? Tag
/codesmithwith what you need. Autofix is disabled.Summary by CodeRabbit