Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On Saturday 25 January 2014 23:14:43 Kurt Pattyn wrote: When websockets becomes part of a Qt module you can consider using QObjectPrivate which makes the d pointer implementation slightly cleaner and removes the need for duplicate d pointers (one from qobject one for the class's own implementation. I tried to use QObjectPrivate, but then I cannot connect to slots within the QObjectPrivate derived class. Statements like 'connect(object, signal, THIS, slot)’ fail because THIS is not derived from QObject. Have you an idea how to solve this? Use QObjectPrivate::connect -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On Sunday 26 January 2014, Kurt Pattyn wrote: On 17 Jan 2014, at 19:46, Frederik Gladhorn frederik.gladh...@digia.com wrote: Just another remark which I'm not sure about: In section 5.2 of rfc 6455 randomness is mentioned. I didn't read up on the background but currently there is only a call to initialize qsrand with QDateTime::currentMSecsSinceEpoch() which is probably not quite according to: The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire. Date and time are quite predictable :-) Creating random numbers with a high entropy is quite expensive (if not cached beforehand). This can be problematic, as a new mask has to be calculated for every frame. What I do find strange though, is that the masking key is sent along unencrypted with the frame header and is thus readable by everyone (if not sent over secure websockets). The messages can thus be perfectly decoded, and as the server is not checking for the source, a malicious application can invent his own masking keys or intercept the message and repackage it (the server just takes whatever masking key that is in the header). I honestly don’t see how this mechanism can protect against malicious applications. So, I wonder if it is worth the effort. Depends. What is it used for? Is it just obfuscation or is it supposed to be real security? If the latter: is it the only way to generate security? (If so: in all likelyhood you are affixed by an inclined plane wrapped helicly around an axis. In laymans terms: screwed.) If the former: unless it is absolutely necessary for understanding the other side of the communication channel - don't bother implementing it. Obscurity is no security. I'd like others with more experience in this area to chime in though. Getting milliseconds since Epoch gives you less than one bit of random (entropy), if and only if nobody can predict precisely when you'll call for the current time. Calling it several times does not increase entropy unless there are sufficiently random intervals between calls and nobody can observe you calling (i.e. you are working on a perfectly secured system). Micro- and Nano-Seconds are slightly more random, but not much (fractions of bits). You need about 128 bits of entropy for good security. After you've got that you can stretch those with a secure random number generator. The q(s)rand functions can be safely assumed to be completely insecure on most operating systems and inadequate on all the others. Don't use them for security. I would not recommend trying to implement your own PRNG either - getting it right is horribly difficult. Getting the entropy gathering right in a cross- platform way is much worse effort... I wonder whether it would be possible to expose the low-level APIs of OpenSSL to Qt, it has quite a good random number generator and it is used for QSslSocket already. Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Prettier printing of Unicode strings
On Tuesday, 21 January 2014 01:05:07 CEST, Thiago Macieira wrote: Actual (s) : \u221212\u20A0\uD800\uDC00 Expected (s2): \u221212\u20AC\uD800\uDC00 [...] - all backslashes as \\ - the following characters as their escape sequences: \r, \n, \t, \b, \f - all other control characters (including 0x7f) as \u00XX - all other characters with \u, including text otherwise readable in the terminal in the locale The rules you describe appear to be out-of-sync with what the example above shows. Is there perhaps a rule English letters, punctuation and numbers are displayed as-is? If that is the case, then it looks like a good change. Should I also do the same for QByteArray? Reading hex dumps isn't very nice. Yes -- I have used QString::fromUtf8(bytearray) multiple times in my tests to produce an ugly workaround. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On 26 Jan 2014, at 11:31, Konrad Rosenbaum kon...@silmor.de wrote: Depends. What is it used for? Is it just obfuscation or is it supposed to be real security? Well, there are 2 places where random numbers are used: 1. During the handshake phase Client sends a handshake request containing a 128-bit random number converted to a string hex representation (Sec-WebSocket-Key). The server appends a well-known UUID (published in the RFC) to that number and calculates a SHA-1 hash. This hash in sent to the client, which in its turn appends the same UUID to the random number it sent before, and calculates a SHA-1 hash. If both the server-sent hash and the client calculated hash match, the handshake succeeds. 2. When sending data from client to server (not the other way) The client generates a 32-bit random number. This random number is stored in plain text in the header of each frame. The data is XOR-ed with that 32-bit random number. The server takes the 32-bit random number from the header and XORs it with the payload to get to the original data. I really fail to see what the intention is of this mechanism. I really fail to see what could make this communication ‘secure’. The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire.” Why should the masking key be unpredictable if it is send unencrypted along with the masked data? Why would a server/proxy predict the masking key if it can just fetch it from the header? To me it looks like having a locked door with the key in the keyhole. Why would a burglar use a crowbar if he has the key? If the latter: is it the only way to generate security? (If so: in all likelyhood you are affixed by an inclined plane wrapped helicly around an axis. In laymans terms: screwed.) If the former: unless it is absolutely necessary for understanding the other side of the communication channel - don't bother implementing it. Obscurity is no security. Well, the standard requires the frames that go from client to server to be masked. So yes, it is absolutely necessary, but in my opinion complete overkill. I'd like others with more experience in this area to chime in though. Getting milliseconds since Epoch gives you less than one bit of random (entropy), if and only if nobody can predict precisely when you'll call for the current time. Calling it several times does not increase entropy unless there are sufficiently random intervals between calls and nobody can observe you calling (i.e. you are working on a perfectly secured system). Micro- and Nano-Seconds are slightly more random, but not much (fractions of bits). You need about 128 bits of entropy for good security. After you've got that you can stretch those with a secure random number generator. The q(s)rand functions can be safely assumed to be completely insecure on most operating systems and inadequate on all the others. Don't use them for security. I would not recommend trying to implement your own PRNG either - getting it right is horribly difficult. Getting the entropy gathering right in a cross- platform way is much worse effort… I wouldn’t even dare :-) This is a research field on its own. I wonder whether it would be possible to expose the low-level APIs of OpenSSL to Qt, it has quite a good random number generator and it is used for QSslSocket already. Indeed, I planned to use the OpenSSL RNGs (the library has FIPS approved RNGs), but that library is not available on all platforms I think. Besides that, I am afraid this is a very expensive operation, certainly because another masking key has to be calculated for every frame. Konrad, reading the cases where random numbers are used, do you think it is worth the effort? I am even considering to calculate the masking key just once and use it for every frame (would speed up the communication). Cheers, Kurt Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Prettier printing of Unicode strings
On 21 Jan 2014, at 01:05, Thiago Macieira thiago.macie...@intel.com wrote: I was writing a test today and QtTest told me: Actual (s) : ?12??? Expected (s2): ?12??? So I went, duh, ok, it looks the same to me but what's behind those question marks. After a bit of changes [https://codereview.qt-project.org/76100], it now prints: Actual (s) : \u221212\u20A0\uD800\uDC00 Expected (s2): \u221212\u20AC\uD800\uDC00 Which tells me what I got wrong. Ok to submit this change then? It will make all toString(QString) print - all backslashes as \\ - the following characters as their escape sequences: \r, \n, \t, \b, \f - all other control characters (including 0x7f) as \u00XX - all other characters with \u, including text otherwise readable in the terminal in the locale But the number 12 is still displayed as 12. Shouldn’t that also be converted to the \u00XX format (\u0031\u0032)? One major advantage of this is that it does not depend on the locale codec being set up or even working, as the previous code did. So we get consistent results even if there's a bug in that. Is this ok? Yes, very okay. It makes QString contents ‘diagnosable'. Should I also print quotes as \ ? And should I surround the string with quotes? I would prefer to output everything in \u format and to surround the entire output with quotes (to distinguish strings from byte arrays). Should I also do the same for QByteArray? Reading hex dumps isn't very nice. Personally, I don’t have a problem with hex dumps. But, if the byte array contains text data, then it is worth considering. Cheers, Kurt -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt-creator] Gerrit disapproval messages
On 26 January 2014 09:06, Orgad Shaneh org...@gmail.com wrote: Hi, Following this discussion from about a year ago, gerrit has recently accepted a wording change for default -1 and -2 Code-Review labels. The scores are now: -1 - I would prefer this is not merged as is -2 - This shall not be merged I suggest configuring qt-project gerrit to something similar. Opinions? A big +1 from me. I know this might sound unimportant or even silly for people with some Gerrit experience, but the current wording really does put off newbies. I can definitely remember the rejection I felt when I've first seen a -1 for my patch ;) The thing is that in gerrit it's not so easy (especially when you see it for the first time) to actually notice that the text is just a standard template. One assumes it comes directly from the reviewer, and the lyrics used are not very nice :) sierdzio ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
Hi, [wow, I had a good laugh!] On Sunday 26 January 2014, Kurt Pattyn wrote: On 26 Jan 2014, at 11:31, Konrad Rosenbaum kon...@silmor.de wrote: Depends. What is it used for? Is it just obfuscation or is it supposed to be real security? Well, there are 2 places where random numbers are used: 1. During the handshake phase Client sends a handshake request containing a 128-bit random number converted to a string hex representation (Sec-WebSocket-Key). The server appends a well-known UUID (published in the RFC) to that number and calculates a SHA-1 hash. This hash in sent to the client, which in its turn appends the same UUID to the random number it sent before, and calculates a SHA-1 hash. If both the server-sent hash and the client calculated hash match, the handshake succeeds. And this is sent in the open? On an unsecured connection? This is the most elaborate scheme of a not-so-secret handshake that I've read so far! The only thing that is more hilarious is the Big Bang Theory scene in which Sheldon lectures his friends on the secret knock before Leonard's birthday party... My personal opinion on unencrypted connections: don't sweat it. Use whatever is available. qrand is as secure as the rest of the connection (i.e. not secure at all). Using secure random does not change a thing in this case (only CPU cycles wasted on the client). On encrypted (SSL) connections: if this covers several HTTP(S) requests and not a simple non-interrupted socket then this should better be some secure 128 bits. Although it is beyond me why you would hash them again and again - they could be used as a cookie... [See bottom of my response for some more elaborate argument on this.] 2. When sending data from client to server (not the other way) The client generates a 32-bit random number. This random number is stored in plain text in the header of each frame. The data is XOR-ed with that 32-bit random number. The server takes the 32-bit random number from the header and XORs it with the payload to get to the original data. I really fail to see what the intention is of this mechanism. I really fail to see what could make this communication ‘secure’. I seem to remember that a certain Julius Caesar had a similarly clever idea for securing his correspondence. Of course Julius had the excuse that advanced math-based cryptography was not available in his time... (https://en.wikipedia.org/wiki/Caesar_cipher) The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire.” My above statement about the handshake was wrong. Enormously so. This statement tops all the comedy in in my sizable DVD collection! Why should the masking key be unpredictable if it is send unencrypted along with the masked data? Why would a server/proxy predict the masking key if it can just fetch it from the header? To me it looks like having a locked door with the key in the keyhole. Why would a burglar use a crowbar if he has the key? Exactly. This toy-cipher and its description is equivalent to triple-ROT13 (triple for more security...) #-( If the latter: is it the only way to generate security? (If so: in all likelyhood you are affixed by an inclined plane wrapped helicly around an axis. In laymans terms: screwed.) If the former: unless it is absolutely necessary for understanding the other side of the communication channel - don't bother implementing it. Obscurity is no security. Well, the standard requires the frames that go from client to server to be masked. So yes, it is absolutely necessary, but in my opinion complete overkill. I agree with you. The only thing this defends against is absolutely clueless IT people (pointy haired boss types) who have read access to network logs, but whose 8 year old kids refuse to help with a simple script. Use any source of (weak) random (e.g. qrand) and ignore this bullshit about strong source of entropy. If anyone asks you why you are using insecure random: a) on unsecured connections it is pointless to get secure random and then transmit it in the open together with the data. Revealing secure random to the open makes it magically insecure. You might as well not try to conceal the data at all. b) on secured (SSL) connections it is pointless to implement a toy encryption when SSL is already doing an adequate job of doing real encryption designed by real cryptographers. c) Or the social argument: anyone clever enough to crack an SSL secured connection might fall off their chair laughing hard when after spending days or decades cracking the SSL-shell-of-encryption and they see secure random
Re: [Development] Remove OSX 10.6 Build?
In regards to users of Mac OS Qt applications: I’m am extremely confident that more Mac OS applications would be/have been written in Qt, if the priority for native looking widget support was higher. Mac OS users are notorious for their attention to detail and noticing a non-native LF. Forcing application developers to resort to Objective C/Cocoa/style sheet hacks/whatever in order to make the UI look and behave more native sort of defies the notion of a cross platform framework. Indeed. In terms of diverting resources away from supporting older versions of OS X this is probably going be much more compelling for Qt users than talk of being able to use C++11, ARC, newer naive APIs etc. inside Qt itself. As an aside, in a company with enough resources to have product designers, the designers are highly likely to be using Macs and their impressions of Qt apps there tend to carry over to discussions about what platforms to base other versions of a cross-platform app on. So if Digia want to sell commercial licenses to use Qt on iOS, Android etc. investment in Mac LF may be quite worthwhile. On 23 January 2014 21:35, Jan Farø jan.fa...@gmail.com wrote: On 24/01/2014, at 03.46, Alexis Menard men...@kde.org wrote: On Thu, Jan 23, 2014 at 5:16 PM, Jan Farø jan.fa...@gmail.com wrote: I don’t think anybody has mentioned the lack of ability to upgrade hardware - mostly because of financial issues, I suppose. 10.6 is as far as I know the last Mac OS to support 32 bit systems. Previous versions of my own software supported PPC and down to Mac OS 10.4, which gave me a considerable user base from that segment. Percentages aside, there’s still a LOT of people sitting with old hardware, simply because they cannot afford to upgrade. But is that a significant part of the Mac OS X users or users of Mac OS X Qt applications? I seriously doubt so. Let's be realistic, less and less software are supporting PPC nowadays, the best you can get is a 32/64 bits binary for Mac OS. Last machines from Apple with 32 bits only processor : 2006. One other point is that Qt5 is about QML and is pushing towards its usage on the desktop with better components for it with a modern GL scene graph. Running on outdated graphic cards with outdated graphic drivers is also not something people want to bother testing and fixing. I completely agree in regards to PPC support. In regards to users of Mac OS Qt applications: I’m am extremely confident that more Mac OS applications would be/have been written in Qt, if the priority for native looking widget support was higher. Mac OS users are notorious for their attention to detail and noticing a non-native LF. Forcing application developers to resort to Objective C/Cocoa/style sheet hacks/whatever in order to make the UI look and behave more native sort of defies the notion of a cross platform framework. Again let's balance the cost of the maintenance of the code of 10.6 vs supporting few users stuck in the past? If they must stick in the past for various reasons (financial or others) then they can just use Qt4, it works just fine for Mac OS 10.6 or even Qt5 released versions. Why such users would care of modern Qt5 applications? Qt4 looks suboptimal on Mac OS. It still has problems with some of the list widgets. Among other things. Qt5 has several showstopper issues on Mac OS, some of which seems to finally being taken seriously (5.2.1?). You can’t ship a quality application on Mac OS with Qt5.0 - Qt.5.2.0. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On 26 Jan 2014, at 19:12, Konrad Rosenbaum kon...@silmor.de wrote: Hi, [wow, I had a good laugh!] On Sunday 26 January 2014, Kurt Pattyn wrote: On 26 Jan 2014, at 11:31, Konrad Rosenbaum kon...@silmor.de wrote: Depends. What is it used for? Is it just obfuscation or is it supposed to be real security? Well, there are 2 places where random numbers are used: 1. During the handshake phase Client sends a handshake request containing a 128-bit random number converted to a string hex representation (Sec-WebSocket-Key). The server appends a well-known UUID (published in the RFC) to that number and calculates a SHA-1 hash. This hash in sent to the client, which in its turn appends the same UUID to the random number it sent before, and calculates a SHA-1 hash. If both the server-sent hash and the client calculated hash match, the handshake succeeds. And this is sent in the open? On an unsecured connection? This is sent in the header of an HTTP request, fully readable. Of course, WebSockets also supports SSL. This is the most elaborate scheme of a not-so-secret handshake that I've read so far! The only thing that is more hilarious is the Big Bang Theory scene in which Sheldon lectures his friends on the secret knock before Leonard's birthday party... My personal opinion on unencrypted connections: don't sweat it. Use whatever is available. qrand is as secure as the rest of the connection (i.e. not secure at all). Using secure random does not change a thing in this case (only CPU cycles wasted on the client). On encrypted (SSL) connections: if this covers several HTTP(S) requests and not a simple non-interrupted socket then this should better be some secure 128 bits. Although it is beyond me why you would hash them again and again - they could be used as a cookie… It is one request/response for the handshake and, if successful, the connection stays open. [See bottom of my response for some more elaborate argument on this.] 2. When sending data from client to server (not the other way) The client generates a 32-bit random number. This random number is stored in plain text in the header of each frame. The data is XOR-ed with that 32-bit random number. The server takes the 32-bit random number from the header and XORs it with the payload to get to the original data. I really fail to see what the intention is of this mechanism. I really fail to see what could make this communication ‘secure’. I seem to remember that a certain Julius Caesar had a similarly clever idea for securing his correspondence. Of course Julius had the excuse that advanced math-based cryptography was not available in his time... (https://en.wikipedia.org/wiki/Caesar_cipher) Given the time and the context, this was far better, because it least he didn’t specify how to decipher the text :-) The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire.” My above statement about the handshake was wrong. Enormously so. This statement tops all the comedy in in my sizable DVD collection! Why should the masking key be unpredictable if it is send unencrypted along with the masked data? Why would a server/proxy predict the masking key if it can just fetch it from the header? To me it looks like having a locked door with the key in the keyhole. Why would a burglar use a crowbar if he has the key? Exactly. This toy-cipher and its description is equivalent to triple-ROT13 (triple for more security…) I’m glad you mentioned ‘triple’... #-( If the latter: is it the only way to generate security? (If so: in all likelyhood you are affixed by an inclined plane wrapped helicly around an axis. In laymans terms: screwed.) If the former: unless it is absolutely necessary for understanding the other side of the communication channel - don't bother implementing it. Obscurity is no security. Well, the standard requires the frames that go from client to server to be masked. So yes, it is absolutely necessary, but in my opinion complete overkill. I agree with you. The only thing this defends against is absolutely clueless IT people (pointy haired boss types) who have read access to network logs, but whose 8 year old kids refuse to help with a simple script. Use any source of (weak) random (e.g. qrand) and ignore this bullshit about strong source of entropy. If anyone asks you why you are using insecure random: a) on unsecured connections it is pointless to get secure random and then transmit it in the open together
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On sábado, 25 de janeiro de 2014 23:14:43, Kurt Pattyn wrote: When websockets becomes part of a Qt module you can consider using QObjectPrivate which makes the d pointer implementation slightly cleaner and removes the need for duplicate d pointers (one from qobject one for the class's own implementation. I tried to use QObjectPrivate, but then I cannot connect to slots within the QObjectPrivate derived class. Statements like 'connect(object, signal, THIS, slot)’ fail because THIS is not derived from QObject. Have you an idea how to solve this? Replace this with q and move the slot to the public class, as a Q_PRIVATE_SLOT. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OS X bundle detection
On sábado, 25 de janeiro de 2014 22:33:36, Samuel Gaist wrote: On 24 janv. 2014, at 18:05, Thiago Macieira thiago.macie...@intel.com wrote: On sexta-feira, 24 de janeiro de 2014 09:25:35, Samuel Gaist wrote: Extending this list would make the current test (if else if) getting a bit long and not necessarily the good thing to do (™) so once the list of extension is decided I would like to know what would be the Qtish way to store it: A static QVector inside the function ? A static QVector outside the function with an intializing function ? Other container/algorithm best suited ? An indexed string table, generated with generate_string_table.pl which you can find in the kdesdk repository. You can see examples of it in qsimd.cpp and in qdbuserror.cpp. It's also what moc generates behind the scenes. Marc has some code to be able to generate them with macros but he hasn't yet fixed the issues we pointed out. They'll miss 5.3. Nice, thank you ! Is the macro version already viewable somewhere ? https://codereview.qt-project.org/66624 One more thing, what's the best way to provide the original data ? In a comment above the generated table or a text file ? If it's long, keep it in a separate file. Otherwise, just keep it in a comment next to the generated data like qsimd.cpp and qdbuserror.cpp. In either case, always keep the instructions on how to regenerate next to the generated code. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt-creator] Gerrit disapproval messages
On domingo, 26 de janeiro de 2014 18:31:18, Tomasz Siekierda wrote: The scores are now: -1 - I would prefer this is not merged as is -2 - This shall not be merged I suggest configuring qt-project gerrit to something similar. Opinions? A big +1 from me. I know this might sound unimportant or even silly for people with some Gerrit experience, but the current wording really does put off newbies. I can definitely remember the rejection I felt when I've first seen a -1 for my patch The thing is that in gerrit it's not so easy (especially when you see it for the first time) to actually notice that the text is just a standard template. One assumes it comes directly from the reviewer, and the lyrics used are not very nice -1 actually means I think this needs change, but if someone else approves it, I'm not against it -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Prettier printing of Unicode strings
On domingo, 26 de janeiro de 2014 12:36:27, Jan Kundrát wrote: On Tuesday, 21 January 2014 01:05:07 CEST, Thiago Macieira wrote: Actual (s) : \u221212\u20A0\uD800\uDC00 Expected (s2): \u221212\u20AC\uD800\uDC00 [...] - all backslashes as \\ - the following characters as their escape sequences: \r, \n, \t, \b, \f - all other control characters (including 0x7f) as \u00XX - all other characters with \u, including text otherwise readable in the terminal in the locale The rules you describe appear to be out-of-sync with what the example above shows. Is there perhaps a rule English letters, punctuation and numbers are displayed as-is? I failed to exclude ASCII 0x20 to 0x7f (except the backslash) in all other characters If that is the case, then it looks like a good change. Should I also do the same for QByteArray? Reading hex dumps isn't very nice. Yes -- I have used QString::fromUtf8(bytearray) multiple times in my tests to produce an ugly workaround. Done. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Prettier printing of Unicode strings
On 26/01/14 20:39, Thiago Macieira thiago.macie...@intel.com wrote: On domingo, 26 de janeiro de 2014 12:36:27, Jan Kundrát wrote: On Tuesday, 21 January 2014 01:05:07 CEST, Thiago Macieira wrote: Actual (s) : \u221212\u20A0\uD800\uDC00 Expected (s2): \u221212\u20AC\uD800\uDC00 [...] - all backslashes as \\ - the following characters as their escape sequences: \r, \n, \t, \b, \f - all other control characters (including 0x7f) as \u00XX - all other characters with \u, including text otherwise I usually prefer the output in utf8, as it gives readable strings (at least on Mac and Linux as long as you don¹t mess with the locale). Escaped strings are much more tedious to debug for me in most cases. So I¹d like to ask for at least an option to get utf8 strings as output, and only escape non printable chars. Cheers, Lars readable in the terminal in the locale The rules you describe appear to be out-of-sync with what the example above shows. Is there perhaps a rule English letters, punctuation and numbers are displayed as-is? I failed to exclude ASCII 0x20 to 0x7f (except the backslash) in all other characters If that is the case, then it looks like a good change. Should I also do the same for QByteArray? Reading hex dumps isn't very nice. Yes -- I have used QString::fromUtf8(bytearray) multiple times in my tests to produce an ugly workaround. Done. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt-creator] Gerrit disapproval messages
On 26 January 2014 20:41, Thiago Macieira thiago.macie...@intel.com wrote: On domingo, 26 de janeiro de 2014 18:31:18, Tomasz Siekierda wrote: The scores are now: -1 - I would prefer this is not merged as is -2 - This shall not be merged I suggest configuring qt-project gerrit to something similar. Opinions? A big +1 from me. I know this might sound unimportant or even silly for people with some Gerrit experience, but the current wording really does put off newbies. I can definitely remember the rejection I felt when I've first seen a -1 for my patch The thing is that in gerrit it's not so easy (especially when you see it for the first time) to actually notice that the text is just a standard template. One assumes it comes directly from the reviewer, and the lyrics used are not very nice -1 actually means I think this needs change, but if someone else approves it, I'm not against it Sure, I know that now, and with that knowledge I don't really mind the current text (or any other one: when I see -1, I simply know what it means). That is why I say it's about newcomers. Getting one's head around all the bureaucracy required to submit a patch to Qt (making sure the patch is sent correctly to Gerrit is especially scary) is pretty hard already. If one then sees the current text for -1 and -2, one can really get discouraged enough to abandon the idea of sending more patches. I know that from my own experience, and from several hints I got from some users of our forums. I do think we should get back to the actual question in the topic, though :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On 26 January 2014 19:23, Kurt Pattyn pattyn.k...@gmail.com wrote: 2. When sending data from client to server (not the other way) The client generates a 32-bit random number. This random number is stored in plain text in the header of each frame. The data is XOR-ed with that 32-bit random number. The server takes the 32-bit random number from the header and XORs it with the payload to get to the original data. I really fail to see what the intention is of this mechanism. I really fail to see what could make this communication ‘secure’. The aim of the masking is to prevent request splitting and smuggling attacks when going through proxies. It prevents an application from being to trick proxies into beginning a new request that does something different to the one intended. https://www.owasp.org/index.php/HTTP_Request_Smuggling Cheers Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Prettier printing of Unicode strings
On domingo, 26 de janeiro de 2014 20:17:20, Knoll Lars wrote: I usually prefer the output in utf8, as it gives readable strings (at least on Mac and Linux as long as you don¹t mess with the locale). Escaped strings are much more tedious to debug for me in most cases. So I¹d like to ask for at least an option to get utf8 strings as output, and only escape non printable chars. The problem is that Unicode can trick your eyes: Actual (s1): Thiago José Macieira / Lars Knoll Expected (s2): Thiago José Macieira ∕ Lаrs Knoll Can you tell the difference with your eyes? There's a reason that IDNA requires lengthy transformations in the NamePrep stage and requires registrars to apply anti-homographic rules. With my change as it is, you'd see: Actual (s1): Thiago Jos\u00E9 Macieira / Lars Knoll Expected (s2): Thiago Jose\u0301 Macieira \u2215 L\u0430rs Knoll -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
