| Issue 3312: | Generated patch is not a valid base64 | |
| 2 people starred this issue and may be notified of changes. | Back to list |
***************************************************************** ***** ***** ***** !!!! THIS BUG TRACKER IS FOR GERRIT CODE REVIEW !!!! ***** ***** ***** ***** DO NOT SUBMIT BUGS FOR CHROME, ANDROID, CYANOGENMOD, ***** ***** INTERNAL ISSUES WITH YOUR COMPANY'S GERRIT SETUP, ETC.***** ***** ***** ***** THOSE ISSUES BELONG IN DIFFERENT ISSUE TRACKERS ***** ***** ***** ***************************************************************** Affected Version: What steps will reproduce the problem? 1. Download a patch (base64) 2. Try to decode it using "openssl enc -base64 -d" or another strict RFC 3548 base64 decoder. What is the expected output? The file is correctly decoded What do you see instead? The file is not decoded because the padding is missing Please provide any additional information below. Base64 patch is not correctly padded, so it's not possible to decode it using a "strict" base64 decoder and using a "non-strict" decoded you still have errors. Please pad it correctly to 4 characters using = (RFC 3548)
Apr 17, 2015
Project Member
#1
david.pu...@sonymobile.com
Status:
AwaitingInformation
Apr 17, 2015
2.10.2 using digest authenticated REST API. drizzt@liara ~ % ssh -p 29418 $USER@$HOST gerrit version gerrit version 2.10.2 drizzt@liara ~ % curl -ks --digest https://$USER:$PASS@$HOST/a/changes/62900/revisions/1/patch | base64 -d > /dev/null base64: invalid input drizzt@liara ~ % curl -ks --digest https://$USER:$PASS@$HOST/a/changes/62900/revisions/1/patch | wc -c 3482
Apr 20, 2015
Unable to reproduce on the latest head of master (v2.11-359-gf3742d8), the version currently deployed on gerrit-review (2.11-rc2-339-ga01168c), or on my production server running 2.11. I currently don't have a 2.10 server to test against.
Apr 20, 2015
Sasa, can you reproduce this on your 2.10 installation?
Cc:
ziv...@gmail.com
Apr 20, 2015
timothy.redaelli have you looked at the output (i.e. remove "| base64 -d > /dev/null " from your command) and checked if it's even returning a base64-like string? When I started testing I piped the output directly into base64 and it was failing because I'd passed a wrong Change-Id and the endpoint was returning an error message, which of course couldn't be base64 decoded. Also, having looked at the code I can see that there is a path where the result is returned with zip compression rather than as a base64. You could try explicitly adding "?download" on the URL, i.e. curl -ks --digest https://$USER:$PASS@$HOST/a/changes/62900/revisions/1/patch?download
Apr 20, 2015
OK, I tried on another production server running 2.8.6.1 and it is reproducible there.
Apr 20, 2015
Reproduced on the head of stable-2.10
Status:
Accepted
Apr 20, 2015
After cherry-picking Stefan Beller's commits (which were found with coverity scan), the issue is fixed. https://gerrit-review.googlesource.com/#/c/67302/ https://gerrit-review.googlesource.com/#/c/67303/
Status:
ChangeUnderReview
Nov 6, 2015
(No comment was entered for this change.)
Status:
Released
Labels: FixedIn-2.10.4 |
|
| ► Sign in to add a comment |