KDE Lands More Crash Fixes, Activities Feature Working On Wayland

[Nth_man]

"Ark now supports extracting Zip files that have Windows-style backslashes used as path separators."

Uh, how is it possible that this was fixed only now. Isn't zip extraction like one of the basic features since 1990?

Anyone can click on the link that was offered, which leads to more information:

Enable extracting of zip files with (technically invalid) windows style pathnames

https://bugs.kde.org/show_bug.cgi?id=176646

There's a file sample: https://invent.kde.org/utilities/ark...991b9b/foo.zip

[ALRBP]

Why not 7:3? 21:9 not using the lowest common denominator slightly irks me

Maybe because it is easier to compare with 16:9

[caligula]

Anyone can click on the link that was offered, which leads to more information:

There's a file sample: https://invent.kde.org/utilities/ark...991b9b/foo.zip

Yea, I can see that. The bug report is over 12 year old. That doesn't explain why this basic functionality (robust handling of file names) is not implemented.

[Nocifer]

Yea, I can see that. The bug report is over 12 year old. That doesn't explain why this basic functionality (robust handling of file names) is not implemented.

Well, just by reading that bug report, I can deduce that a) we're talking about zip files that are invalid because they do not follow the spec, b) Ark not being fixed was due to lack of support for invalid files in the underlying library, c) it was kind of fixed in 2015 because Ark switched to using p7zip which partially supports these invalid files, and d) it was properly fixed only when info-zip apparently developed a method that finally allowed for handling such invalid files, which method the KDE folks promptly copied over to their own library.

[oiaohm]

Yea, I can see that. The bug report is over 12 year old. That doesn't explain why this basic functionality (robust handling of file names) is not implemented.

Some bugs like that are a little tricker thinking by standard zip file like that is in fact invalid and if you follow zip standard you are not meant to open them. So the old behaviour of refusing to open zip files with filenames like that is in fact correct just as much as the new behaviour accepting the invalid filenames. Do note that neither response end up with exploit.

This is more of a question do you stick to standard or do you deal with broken garbage other parties are creating who are not following the standard.

[caligula]

Well, just by reading that bug report, I can deduce that a) we're talking about zip files that are invalid because they do not follow the spec, b) Ark not being fixed was due to lack of support for invalid files in the underlying library, c) it was kind of fixed in 2015 because Ark switched to using p7zip which partially supports these invalid files, and d) it was properly fixed only when info-zip apparently developed a method that finally allowed for handling such invalid files, which method the KDE folks promptly copied over to their own library.

Well, the problem with zip files is that file names are usually encoded in different ways and the reader has to guess anyways. Most files assume cp437, but modern Linux/BSD uses UTF-8. Linux archivers store names as UTF-8. So, you already need multiple checks to extract anything. It's not terrible hard to add this feature, e.g.

void parse_entry()
{
  ..
  switch(next_char}
  {
    case '\':
      printf("warning: %s appears to use backslashes as path separators\n", archive_file);
    case '/':
      path_separator_code();
      break;
  }
  ..
}

[caligula]

Some bugs like that are a little tricker thinking by standard zip file like that is in fact invalid and if you follow zip standard you are not meant to open them. So the old behaviour of refusing to open zip files with filenames like that is in fact correct just as much as the new behaviour accepting the invalid filenames. Do note that neither response end up with exploit.

This is more of a question do you stick to standard or do you deal with broken garbage other parties are creating who are not following the standard.

I think unless you toggle the 11th bit in the general purpose flags field, you can't assume anything about the encoding of file names.

[ATFx]

Wait around for an important Holiday they deem is to take making stable priority again briefly then fork it lol.
XFCE,Mate, LXQT I'm missing some for sure remain the most stable from Gnome or KDE.

[oiaohm]

I think unless you toggle the 11th bit in the general purpose flags field, you can't assume anything about the encoding of file names.

https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

D.2 If general purpose bit 11 is unset, the file name and comment SHOULD conform to the original ZIP character encoding.

Sorry no caligula there is a zip file character encoding. Yes that 12 year old bug the filename encoded without 11th bit set don't conform to ZIp file format requirements. So its a invalid file.

[tildearrow]

Maybe because it is easier to compare with 16:9

Then I'll start saying 12:9