On Saturday 19 November 2011, Darrell Anderson wrote:

...

As far as I can tell, if a file contains a password (obfuscated) Konqueror doesn't recognize the file type. For example, on my system (Slackware 12.2 with KDE 3.5.10) Konqueror fails to recognize both kmailrc and kopeterc. If I make a copy of kmailrc and remove the password lines, then Konqueror recognizes the file as plain text.

Ah. As Inspector Clouseau would say, "A clue!"

Is this behavior necessary? Desired? The user's home profile directory usually is 700 permissions. Sure, if I walk away somembody could open such files but the passwords are not clear text.

Darrell

I don't know if this behaviour is intentional or not, but I suspect that it isn't. I think that Konqueror just gets confused if the file which it is examining contains any information which is not plain text.

Richard.

Le 19/11/2011 20:04, Laurent Dard a écrit :

$ file ~/.trinity/share/config/kmailrc --> UTF-8 Unicode text, with very long lines

In this folder, all files identified by 'file' as 'UTF-8 Unicode text, with very long lines' (and only those files) are identified by konqueror as unknown type.

On Saturday 19 November 2011, Laurent Dard wrote:

Le 19/11/2011 20:04, Laurent Dard a écrit :

...

$ file ~/.trinity/share/config/kmailrc --> UTF-8 Unicode text, with very long lines

In this folder, all files identified by 'file' as 'UTF-8 Unicode text, with very long lines' (and only those files) are identified by konqueror as unknown type.

As I mentioned before, if I make a copy of kmailrc and edit it to remove the lines which contain the password entries, Konqueror is then able to recognize the file as plain text. The 'file' command claims it to be "UTF-8 Unicode text, with very long lines" whether it contains the password or not.

Richard.

I believe the bug is here. There is a length limit that troubles konqueror: if a line contains more than 301 bytes, the file is wrongly identified.

kdelibs/kio/kio/kmimemagic.cpp:2O10: /* Now, look whether the file consists of lines of * "reasonable" length. */

for (i = 0; i < nbytes;) { cp = (unsigned char *) memchr(buf, '\n', nbytes - i); if (cp == NULL) { /* Don't fail if we hit the end of buffer. */ if (i + TEXT_MAXLINELEN >= nbytes) break; else return 0; } if (cp - buf > TEXT_MAXLINELEN) return 0; i += (cp - buf + 1); buf = cp + 1; }

An here is THE BUG: kdelibs/kio/kio/kmimemagic.cpp:1992: #define TEXT_MAXLINELEN 300

Now, what's the solution? Is it good to define a maximum length? Which one?

Le 19/11/2011 23:29, Darrell Anderson a écrit :

Would somebody provide me a good reason why line lengths should be involved in this process at all? I'll submit a bug report on that unless somebody offers a convincing reason.

Please, do so.

I'm also wondering if a bug report should be send to bugs.kde.org: the code is still there in KDE4.

If you are going to start a new discussion subject, please *don't* send your mail by using the "Reply" functionality: the mail you send will have references to the former unrelated mail and it will mess up the layout of the messages list for people who display it as a tree.

Le 19/11/2011 22:52, Laurent Dard a écrit :

Now, what's the solution? Is it good to define a maximum length? Which one?

I'm inclined to believe no limit is needed here.

Patch attached, for kdelibs. Must be reviewed: not yet tested!

Le 19/11/2011 23:48, Richard J.M. Hill a écrit :

The fact that a limit was placed on the maximum line-length suggests to me one of two things; either the person who wrote believed that it was necessary, or they were re-using code from somewhere else, and neglected to remove that restriction.

They took the code from the 'file' program where it's used to say "with very long lines". There is the following comment in the source: // This code is taken from the "file" command, where it is licensed // in the "beer-ware license" :-) // Original author: joerg@FreeBSD.ORG

The limit (TEXT_MAXLINELEN 300) is commented by: /* Maximal length of a line we consider "reasonable". */

And if there's such a line, they consider the file isn't a text file. That's not "reasonable", I think. ;-)

to be necessary, maybe we should try to imagine why it is there. The first thing that pops into my head (and again, remember my ignorance in the ways of programming) is that they wanted to avoid the possibility of buffer overflows or race conditions.

I don't think so. If a line is longer than 301 bytes, conf->resultBuf = MIME_TEXT_PLAIN is not executed, that's all. The code I modified is really only used to define if the file is plain text or not.

On Sunday 20 November 2011 15:58:44 Laurent Dard wrote:

There's a remaining bug here:

~$ file .{kde,trinity}/share/config/gtkrc* .kde/share/config/gtkrc:               UTF-8 Unicode C++ program text .kde/share/config/gtkrc-2.0:           UTF-8 Unicode C++ program text .kde/share/config/gtkrc-2.0Voe7Xb.new: UTF-8 Unicode C++ program text .trinity/share/config/gtkrc:           UTF-8 Unicode C++ program text .trinity/share/config/gtkrc-2.0:       UTF-8 Unicode C++ program text   but konqueror identifies them as Java source files.

that might be by intention: the direct competition is always associated with the most evil attributes ;-)

werner

Le 20/11/2011 18:30, Darrell Anderson a écrit :

I created Bug Report 656 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=656). Laurent, as you wrote and tested the patch you should submit/attach the patch to the bug report to receive credit. :)

Thanks. Done. (But deleting code is no glory...)

Description: unset the limit to line length in plain text files The 'TEXT_MAXLINELEN 300' constant is removed, as well as the test for long lines, in the 'textmagic' function, in kio/kio/kmimemagic.cpp. It made konqueror identify configuration files with long lines as files from unknown type. . The bug is still present in the KDE4 code. It has already been reported (http://bugs.kde.org/143100), but the report was closed. . This bugfix doesn't solve other errors in file detection (debian/rules files not detected as "make files", wrong reports of "Java code", "Objective-C code", "diff"...). (http://bugs.kde.org/116272) . Thanks to Darrell Anderson, Werner Joss and Richard J.M. Hill. [trinity-devel] kmailrc file type unknown [trinity-devel] Kmailrc File Type.

Everybody who participated in this discussion, please add additional comments as necessary to describe your own observations with these mimetype quirks. :)

The 'unknown type' problem is solved. For other problems, I'm opening another bug report: http://bugs.trinitydesktop.org/show_bug.cgi?id=661 where we can summarize all our discoveries.

Here is my summary: Konqueror wrongly recognizes some files as of type: * diff (as stated here: http://bugs.kde.org/116272 * Java code (the gtkrc file type which is 'UTF-8 Unicode C++ program text') * C++ header * Objective-C code (/etc/apt/apt.conf) * C source file (~/.gnome2/totem_config)

And it doesn't recognize other types * email files with extension .eml are recognized as plain text and or not associated with mail programs. * debian/rules files (debian source packages) are not always recognized as make files.

* Empty files without extension should be opened in text editors. * Empty files with known extensions should be opened like other files (db.sqlite, if empty, can't be opened in kexi from konqueror)

Concerning text files which contains passwords: * the string contains more than 301 characters: bug * it contains control characters: data file (but it's astonishing)

On Sunday 20 November 2011, Richard J.M. Hill wrote:

On Sunday 20 November 2011, Laurent Dard wrote:

...

Konqueror wrongly recognizes some files as of type:

• diff (as stated here: http://bugs.kde.org/116272
• Java code (the gtkrc file type which is 'UTF-8 Unicode C++ program text')

I have another non-technical observation... My gtkrc file contains two lines with the word class in them. Since I associate the word class with Java, I thought I would see what would happen if I deleted them from a copy of the gtkrc file. Surprise! Konqueror recognizes them as plain text! Even more interesting, is that if I delete only ONE line with the word class in it, it still works! Not only that, but it doesn't matter which of the two lines I delete!

Next, I thought I would add the word class to a file which Konqueror identified as plain text. If I added the word class to kpatrc twice Konqueror identified it as a Java file.

Richard.

Another observation in the same vein... There are two files in my .kde/share/config * directory which contain the string [Desktop Entry]. These are konsolerc and kpdfrc. In the case of kpdfrc, the first line in the file says [Desktop Entry] and that file appears as an executable file in Konqueror. The konsolerc file has [$Version] on the first line followed by version information. If I copy the first two lines from konsolerc into kpdfrc, and then edit konsole to read kpdf ;-) the file is now identified as plain text by Konqueror, and Kpdf still functions normally. I don't know why Konsole and Kpdf create config files which contain the string [Desktop Entry] though...

* I am running KDE 3.5.10, built from source, on Slackware 12.2

Richard

In article 201111202237.25278.cycledaemon@youmano.com, Richard J.M. Hill trinity-devel@lists.pearsoncomputing.net wrote:

I have another non-technical observation... My gtkrc file contains two lines with the word class in them. Since I associate the word class with Java, I thought I would see what would happen if I deleted them from a copy of the gtkrc file. Surprise! Konqueror recognizes them as plain text! Even more interesting, is that if I delete only ONE line with the word class in it, it still works! Not only that, but it doesn't matter which of the two lines I delete!

Next, I thought I would add the word class to a file which Konqueror identified as plain text. If I added the word class to kpatrc twice Konqueror identified it as a Java file.

I wonder if Konqueror for Trinity could be made to use libmagic for its file type detection ?

There are a number of places where KDE "does its own thing" although standard and more modern libraries have come along since KDE was developed. SSL certificate management is another one, and one that particularly concerns me in the light of the number of certificate revocations lately.

Nick

In article 201111202237.25278.cycledaemon@youmano.com, Richard J.M. Hill trinity-devel@lists.pearsoncomputing.net wrote:

...

I have another non-technical observation... My gtkrc file contains two lines with the word class in them. Since I associate the word class with Java, I thought I would see what would happen if I deleted them from a copy of the gtkrc file. Surprise! Konqueror recognizes them as plain text! Even more interesting, is that if I delete only ONE line with the word class in it, it still works! Not only that, but it doesn't matter which of the two lines I delete!

Next, I thought I would add the word class to a file which Konqueror identified as plain text. If I added the word class to kpatrc twice Konqueror identified it as a Java file.

I wonder if Konqueror for Trinity could be made to use libmagic for its file type detection ?

There are a number of places where KDE "does its own thing" although standard and more modern libraries have come along since KDE was developed. SSL certificate management is another one, and one that particularly concerns me in the light of the number of certificate revocations lately.

If a modern, widely-available and maintained library does a better job than an old (small) internal library in TDE, a bug report should be filed as a feature request to use the new library.

Note that these bug reports may take a long time to resolve, depending on the size of the library to be replaced.

Tim