I'm having a very wonky issue with trying to use base64 "encryption" for my
Windows OSes. I'm autogenerating my unattend.xml as part of a provisioning
template, and what I'm find out is that my password gets encoded twice. In
other words, when I go to decode the password that's written to
unattend.xml, it does not match my password, but rather a jumbled string.
When I base64 decode THAT string then I get my password.
Here's the really weird part: when I then go to the provisioning template,
the encoded password is now TRIPLE encoded.
Has anyone seen this same issue with base64 encoding being broken?
Looks like a bug in the host which calls the crypt method. It normally
checks for a regular crypt call if the password already has a $…$ type
form, but obviously, that won't work for plain base64 so it's calling
crypt each time the host is edited.
Please file it as a bug.
···
On 02/09/15 18:20, lawre wrote:
> I'm having a very wonky issue with trying to use base64 "encryption" for
> my Windows OSes. I'm autogenerating my unattend.xml as part of a
> provisioning template, and what I'm find out is that my password gets
> encoded twice. In other words, when I go to decode the password that's
> written to unattend.xml, it does not match my password, but rather a
> jumbled string. When I base64 decode THAT string then I get my password.
>
> Here's the really weird part: when I then go to the provisioning
> template, the encoded password is now TRIPLE encoded.
>
> Has anyone seen this same issue with base64 encoding being broken?
···
On 03/09/15 08:24, Dominic Cleal wrote:
> On 02/09/15 18:20, lawre wrote:
>> I'm having a very wonky issue with trying to use base64 "encryption" for
>> my Windows OSes. I'm autogenerating my unattend.xml as part of a
>> provisioning template, and what I'm find out is that my password gets
>> encoded twice. In other words, when I go to decode the password that's
>> written to unattend.xml, it does not match my password, but rather a
>> jumbled string. When I base64 decode THAT string then I get my password.
>>
>> Here's the really weird part: when I then go to the provisioning
>> template, the encoded password is now TRIPLE encoded.
>>
>> Has anyone seen this same issue with base64 encoding being broken?
>
> Looks like a bug in the host which calls the crypt method. It normally
> checks for a regular crypt call if the password already has a $..$ type
> form, but obviously, that won't work for plain base64 so it's calling
> crypt each time the host is edited.
>
> Please file it as a bug.