Announcement

Collapse
No announcement yet.

KDE Lands More Crash Fixes, Activities Feature Working On Wayland

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by caligula View Post
    "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
    Last edited by Nth_man; 10 April 2021, 11:16 AM.

    Comment


    • #12
      Originally posted by skeevy420 View Post
      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

      Comment


      • #13
        Originally posted by Nth_man View Post

        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.

        Comment


        • #14
          Originally posted by caligula View Post

          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.

          Comment


          • #15
            Originally posted by caligula View Post
            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.

            Comment


            • #16
              Originally posted by Nocifer View Post

              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.

              Code:
              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;
                }
                ..
              }

              Comment


              • #17
                Originally posted by oiaohm View Post

                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.

                Comment


                • #18
                  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.

                  Comment


                  • #19
                    Originally posted by caligula View Post
                    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/...es/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.

                    Comment


                    • #20
                      Originally posted by ALRBP View Post

                      Maybe because it is easier to compare with 16:9
                      Then I'll start saying 12:9

                      Comment

                      Working...
                      X