Fish: ssh key pass-phrase prompt use wrong encoding
While wanting to put files to a remote host using the fish protocol, it prompted as expected the passphrase for the ssh key I use. MY pass-phrase actually contains non ASCII characters encoded as utf8, but the dialog box seems to expect a latin1 string. Test to reproduce the error: Precondition: remote account password or ssh key passphrase is "ètr" Test 1: - Use fish to access a remote server using for example Dolphin - A dialog prompt for the password (or passphrase of the key) - Put "ètr" in the password field and confirm - The password is refused and fish ask again for the password Test 2: - Use fish to access a remote server using for example Dolphin - A dialog prompt for the password (or passphrase of the key) - Put "ètr" in the password field and confirm - The password is accepted and fish show files of the remote server The password is read as Unicode UTF-16 (using QString), then kio_fish convert it to latin1 and send it to ssh. When putting "ètr" in the password prompt, the "è" character is sent to ssh as byte 0xE8. ssh read 0xE8 and compare it to the pass-phrase which is encoded in utf8, and so fail because "è" in UTF-8 is encoded as bytes 0xC3 0xA8. When putting "ètr", "è" is sent to ssh as bytes 0xC3 0xA8. ssh read these two bytes and compare them to the passphrase and these bytes match to the the UTF-8 character "è" so ssh can use key on go on. In my case, I created the key using command line, and my system use UTF-8, so the passphrase I entered is encoded as UTF-8. ssh does not seems to do any character conversion, so the expect encoding is the one used at passphrase creation. I posted a bug report about that: https://bugs.kde.org/show_bug.cgi?id=332428 After more investigation, it seems that other text strings (username, account password, hostname) may be read by ssh as UTF-8 strings too. In comment 2 in the bug report, I say that ssh is started with LANG=C LC_ALL=C, but it's not the case (I confused ssh arguments with the command executed on the remote host when ssh start). To be sure I checked the environment variables of the ssh spawned by kio_fish, and there is LANG=fr_FR.UTF-8. So as I first thought, username, hostname and password (in case of login with password authentication) may also be read as UTF-8 strings by ssh but fish send them as latin1 strings. This issue seems to not be so easy to handle, so can someone confirm expected encodings and if username, hostname, password and pass-phrase should indeed be send using the local encoding (ie: use toLocal8Bits) instead of latin1 (toLatin1). Cheers, Alexis
Re: Kronometer now in KDE Review
Hi all, 2014-04-23 17:19 GMT+02:00 Elvis Angelaccio : > > 2014-04-23 14:28 GMT+02:00 Thomas Lübking : > > On Mittwoch, 23. April 2014 13:17:02 CEST, Elvis Angelaccio wrote: >> >> I don't understand. Since there are only numbers I think that your point >>> is >>> already accomplished. >>> >> Nope. >> To get monospace glyphs for sure, you must select a monospace font - >> otherwise you're going by luck. >> >> At least on my system >>> >> ;-) >> >> >> Have you found a particular font that doesn't look this way? >>> >> Hundreds - it's pretty common and the more "exotic" the fonts get >> (script), the more obvious this becomes, but you may try Fontin [1], >> Bitstream Handel Gothic [2], Adobe Jenson or Linotype Frutiger (latter are >> commercial fonts, no link - sorry. I can send you screenshots of the fonts >> though and some resellers will likely provide some as well) for some >> "reasonable" choices. >> In addition, the hinter and font size/weight can have impact. >> >> > Oh my god, using these fonts the stopwatch display is an eyesore. > Thanks for the explanation, this thing has to be fixed, sure as hell. I > will try with different labels for each digit. > The problem now should be fixed. I've replaced QLabel with a custom widget which uses a horizontal layout with a QLabel for each digit, adding proper padding. The padding space is computed on the current font width (using QFontMetrics). This should take into account most fonts, even if I've tried only the fonts suggested by Thomas. If you have many other "exotic" fonts in your systems, further tests are welcome. Probably the best solution was to use a custom QLabel which overrides its paintEvent() function, but I didn't know how to deal with it, since it's too low level. Screenshot for a quick feedback (HandelGothic font): http://abload.de/img/kronometer2a2k3a.png Cheers, Elvis
Review Request 117789: Optimize word count in PlainTextExtractor.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117789/ --- Review request for kdelibs and Vishesh Handa. Repository: kfilemetadata Description --- Optimize word count in PlainTextExtractor. Regular expressions are notoriously slow. Implementing a simple word-count directly in C++ is much faster, as shown by the benchmark: Before: 702.0 msecs per iteration (total: 7,020, iterations: 10) After: 125.5 msecs per iteration (total: 1,256, iterations: 10) Make the plaintext extractor benchmark more meaningful. It now operates on a larger file and uses QBENCHMARK to actually get some data. Diffs - autotests/indexerextractortests.cpp 1cb8e65da7d764eab1923054659ae5841104de2d src/extractors/plaintextextractor.cpp 536e02d843f24dbbc19035029896b9e696e8b302 Diff: https://git.reviewboard.kde.org/r/117789/diff/ Testing --- Thanks, Milian Wolff
