Open davidbpirie opened 2 years ago
Removing the .encode('utf-8')
"fixes" the issue as long as the username contains only ASCII characters, but leads to errors/problems if there are non-ASCII characters in the name. I'll need to experiment some more.
I've made (and minimally tested) a change that addresses the issue on Python 3. I have not yet tested to see if it breaks things under Python 2. (This machine is running macOS 12.3 and I don't have Python 2 available.)
...and these changes break on Python 2. As tempting as it might be to abandon Python 2 right now, I suspect a fair number of people are still using it.
OK. Latest push seems to work under both Python 2 and 3; tested under both with a username containing non-ASCII characters, and a password containing non-ASCII characters.
When building a package with python3 (tested with python 3.10.2 and munki-python 3.9.5) the string applied for the username is in the syntax "b'username'".
Python 3:
Python 2:
From my minimal testing, this appears to have no negative impact when the pkg target is not the boot volume (eg via bootstrappr), but does when target the boot volume (eg installr). Areas I identified as impacted in pkg_scripts/postinstall are inside lines 45-66 - the createuser binary (line 47) executes successfully as the contents of the plist are correct, but the subsequent lines using "$USERNAME" will have unexpected results.
I believe this ultimately is because
string.encode('utf-8')
results in a byte object, not a string, and the differences in how python2 and python3 handle byte objects. This is used in locallibs/userpkg.py.I could have a crack at a PR if you like, but I am not exactly sure where the need for UTF-8 encoding comes from, so might make a complete hash of it.
Thanks for all you do and share with the community.