On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote: > > The thing you have to rememeber is that the escape character never needs > > to be typed by the user. > > In QRexec you are defining an API, applications like qvm-run are using > > that API. What the user passes into qvm-run and what is actually sent > > to dom0 does not have to be identical. > > In theory yes, but this would introduce more complexity to this code > (taking care where which encoding is used etc).
I read the code, there is no encoding. You correctly used the POSIX Portable Character Set for text. So no need for encoding. When you use the qrexec API you just sent a struct with some arrays of bytes for VM names. In your qrexec code you use an array of unsigned chars. Also, no encoding. The point is that you use encodings only when you have **text** with characters > 127. Which you don't allow. The problem you fear doesn't exist. The reason is because when accepting user-input you use encodings. When your app starts talking to qrexec/qubsed there is no longer any encoding. Just an 8-bit bytearray. The text has been standardized. On the 'other' side of qrexec (on dom0) you have perfect control over the situation and you also don't have any need for recoding or encodings or anything like that. It still is just 8 bits data, not encoded. > > I guess you do the translation currently as well; '$' turns into '@' in > > your new code. > > > > The consequence of this is that you don't have to limit yourself to the > > posix list. > > Using the portable characters set for a non-character simply isn't > > needed. > > > > So, knowing that your API is actually based on 8-bit characters and not > > 7 > > bits which you are limiting yourself to, my suggestion is to take > > something above 127 and below 256 as a special char. > > Most fun one would be “ÿ” which is a normal character you can pass on a > > shell script if you must, its actual byte-value is 0xFF > > Until some helpful application (shell or else) will try to interpret it > as UTF-8. Ehm, how would “some helpful application” manage to get in your qrexec policy-frameowork? If you fear that you have bigger issues as they could replace anything with anything... Anyway, to answer your fear. No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken. (see attached example file) Or, more likely, it will just switch off utf-8. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/2513384.SI2geNoQLk%40strawberry. For more options, visit https://groups.google.com/d/optout.
�b
