qvm-create with non-ascii char in name causes unhandled exception in qubesd

[zander]

Qubes OS version:

4.0 (latest testing)

Steps to reproduce the behavior:

In dom0 type
qvm-create --template archlinux --label red fooßbar

Expected behavior:

A Qube is created and the name is assigned as a utf8 unicode string.

Alternatively, qubesd returns a user-readable error-message or error-code which qvm-create can handle so the user can understand whats going wrong.

Actual behavior:

I have to check the journal (assumes access to dom0) and see that an exception is thrown in cubesd.
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)

General notes:

UTF8 usage has been standard on unix systems for almost a decade, it would be a severe limitation for non-western cultures if qubes can not have anything but ascii characters.

---

Related issues:

May be related to #3341

[andrewdavidwong]

This appears to be a duplicate of #2751. If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

[andrewdavidwong]

This appears to be a duplicate of #2751. If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

[zander]

I don't think closing this (as a duplicate) was the best solution based on the fact that this bug has a simple one step way to reproduce it and the old bug 2751 doesn't have any way to reproduce it.

It would surprise me if its a duplicate, but this is mostly due to the fact that bug 2751 has not enough information to understand even which component has this issue.

I would hope you can reopen this one as developers will have a much easier time reproducing this issue (its a copy paste action). If you are right this is a duplicate (again, I really can't tell), then please close the 2751 issue based on that conclusion.

[zander]

I don't think closing this (as a duplicate) was the best solution based on the fact that this bug has a simple one step way to reproduce it and the old bug 2751 doesn't have any way to reproduce it.

It would surprise me if its a duplicate, but this is mostly due to the fact that bug 2751 has not enough information to understand even which component has this issue.

I would hope you can reopen this one as developers will have a much easier time reproducing this issue (its a copy paste action). If you are right this is a duplicate (again, I really can't tell), then please close the 2751 issue based on that conclusion.

[andrewdavidwong]

Reopening in case it's not really a duplicate. (If it's really a duplicate and your report has more useful information, the right thing to do is to add your more useful information as a comment on the existing report.)

[andrewdavidwong]

Reopening in case it's not really a duplicate. (If it's really a duplicate and your report has more useful information, the right thing to do is to add your more useful information as a comment on the existing report.)