-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, Feb 20, 2018 at 06:57:34PM +0100, Tom Zander wrote: > 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.
And then, after policy evaluation, you pass that data to actual service to execute the operation (which may be in dom0 or another VM). > > > 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... I'm not sure if you've read the QSB carefully. The problem is how the thing executing the service handle arguments. Not policy evaluating part - - there '$' or other potentially shell special characters are handled correctly. Anyone can write a qrexec service, and we want to provide a framework that make it hard to shoot yourself in the foot. > 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. > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMa8cACgkQ24/THMrX 1yyE6gf+McyBJoK/NW4KAfYEL5xritven8tl35yXaWND674jddKz/WXMaaf9mdar 338xMDBLoeDMZvYVpujd2+lbbnwyMPOUvxGtDQ87R+mluWX5YkWcrzNgVWhrjbJu GTczmlkCT+PaW5cYonXCvFMzGyB3Afu2T7BMBD947RU2SUpiaooAfUUqpS1dCGG8 cQF8xe2Ab3vCBF1e1ocOEF5KRYgsC8NsTc1KDqlDp9AORqfLOINHv0ZNFS/Gaksn CLqvKO5VPr+oswHm8v5I4MLQPK5cQuFvn7oJOs3+pOzZqVk9y7xvjZ4xKiVNF4pB tK0B3Tpp3F0VzI9fhAoYHi4pI2PSUg== =mIGj -----END PGP SIGNATURE----- -- 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/20180220184119.GG2084%40mail-itl. For more options, visit https://groups.google.com/d/optout.
