mdroth <mdr...@linux.vnet.ibm.com> writes: > On Wed, Feb 06, 2013 at 09:14:12PM +0100, Markus Armbruster wrote: >> mdroth <mdr...@linux.vnet.ibm.com> writes: >> >> > On Wed, Feb 06, 2013 at 10:06:03AM +0100, Markus Armbruster wrote: [...] >> >> ---<test run>--- >> >> in : 1 >> >> out: >> >> b64: >> >> in : 1= >> >> out: >> >> b64: >> >> in : 1== >> >> out: >> >> b64: >> >> in : 1=== >> >> out: d4 >> >> b64: 1A== >> >> in : 12 >> >> out: >> >> b64: >> >> in : 123 >> >> out: >> >> b64: >> >> in : 1234 >> >> out: d7 6d f8 >> >> b64: 1234 >> >> in : =1234 >> >> out: 03 5d b7 >> >> b64: A123 >> >> in : 1=234 >> >> out: d4 0d b7 >> >> b64: 1A23 >> >> in : <>?,./watch this!@#$%^&*()_+ >> >> out: ff 06 ad 72 1b 61 >> >> b64: /watchth >> >> in : /watchthis+ >> >> out: ff 06 ad 72 1b 61 >> >> b64: /watchth >> > >> > Am I misinterpreting the output or is base64_encode() actually spitting >> > *out* invalid base64 strings for certain inputs? If so that seems pretty >> > bad for something like guest-file-read, where inputs to base64_encode() >> > are for all intents completely random. Addressing it in hard freeze may >> > not be reasonable, since qemu-ga users must already be prepared to receive >> > garbage from malicious/buggy agents, but I'd certainly pick up a fix for a >> > subsequent stable release. >> >> Which base64_encode() outputs in my test run do you suspect of being >> bad? >> > > My mistake. The last 2 caught my eye, but I didn't realize "/" was a valid > base64 character, and that characters were being truncated from the > original input due to padding restrictions, I thought it was just > fudging up the plaintext.
You're correct. And I'm glad we don't have yet another problem!
