1. 22 Feb, 2021 1 commit
  2. 22 Oct, 2020 1 commit
  3. 27 Sep, 2020 1 commit
  4. 25 Sep, 2020 1 commit
  5. 29 Jul, 2020 1 commit
    • Elvis Angelaccio's avatar
      Fix vulnerability to path traversal attacks · 0df59252
      Elvis Angelaccio authored
      Ark was vulnerable to directory traversal attacks because of
      missing validation of file paths in the archive.
      More details about this attack are available at:
      Job::onEntry() is the only place where we can safely check the path of
      every entry in the archive. There shouldn't be a valid reason
      to have a "../" in an archive path, so we can just play safe and abort
      the LoadJob if we detect such an entry. This makes impossibile to
      extract this kind of malicious archives and perform the attack.
      Thanks to Albert Astals Cid for suggesting to use QDir::cleanPath()
      so that we can still allow loading of legitimate archives that
      contain "../" in their paths but still resolve inside the extraction folder.
  6. 12 Apr, 2020 2 commits
  7. 08 Dec, 2019 1 commit
  8. 13 Sep, 2019 1 commit
  9. 04 Sep, 2019 1 commit
  10. 09 Jun, 2019 1 commit
  11. 02 Jun, 2019 1 commit
    • Elvis Angelaccio's avatar
      Simplify kill logic · 3dbdac81
      Elvis Angelaccio authored
      Evolution of b1a251eb. We no longer want to distinguish between
      libarchive and libzip. If there are crashes in libarchive because of
      this new kill logic, we need to fix them.
  12. 01 Jun, 2019 1 commit
  13. 27 Mar, 2019 1 commit
    • Ragnar Thomsen's avatar
      Fix progress info for CreateJob · ce2f7f66
      Ragnar Thomsen authored
      Progress info is currently broken when creating archives using
      CreateJob. This happens e.g. when the user creates an archive
      through the KFileItemAction in Dolphin.
      This is caused by CreateJob using a nested AddJob and the percent
      signal of the AddJob was not forwarded to CreateJob.
      It was encessary to use QOverload since KJob has both a signal and a
      member function called percent.
      BUG: 382599
      FIXED-IN: 19.04.0
      Differential Revision: D19953
  14. 25 Nov, 2018 1 commit
  15. 25 Feb, 2018 4 commits
    • Elvis Angelaccio's avatar
      LoadJob: check result in onFinished() · ef5c38a3
      Elvis Angelaccio authored
      It doesn't make sense to set these properties if loading the archive
      failed. This also allows to fix the expected values of a testcase.
    • Elvis Angelaccio's avatar
      Rework kill logic · b1a251eb
      Elvis Angelaccio authored
      The libzip plugin sometimes cannot react to `QThread::requestInterruption()`
      because there is a blocking `zip_close()` which writes to disk (e.g. with AddJobs).
      This means we have to manually abort the thread (by passing a timeout to
      `QThread::wait()` in `Job::doKill()`. We cannot do this uconditionally
      because we would end up with crashes in libarchive. Since the libarchive
      plugin is not affected by this problem, we rework the logic in
      `Job::doKill()` by assuming that the interface will tell us whether it
      needs to be brutally killed. This way we can distinguish between the
      libarchive and the libzip plugins (the ones that use a worker thread).
      The mutex in this patch is needed because in theory `m_operationMode` could be
      read and written by different threads at the same time, even though that's unlikely.
      BUG: 389290
      FIXED-IN: 18.03.80
      Task: T7824
    • Elvis Angelaccio's avatar
      Stop emitting result() after doKill() · 79219339
      Elvis Angelaccio authored
      Whether the job emits the `result()` signal should depend on the
      argument passed to `KJob::killed()`. From the Ark side we always call
      `kill()` which uses the default argument `Quietly`.
      However, KUiServerJobTracker (called from the plasma systrat applet)
      calls `kill(KJob::EmitResult)`. This means that the result signal will
      be emitted twice: one from `KJob::finishJob()` and another one when the
      Ark jobs return and we go to `Job::onFinished()`.
      This means that from the Ark side we need to emit `result()` only when
      we didn't kill the job quietly, i.e. when we didn't call `doKill()`
      (which sends the request interruption to the secondary threads).
      This patch does that but it's quite an hack. A better long-term solution
      would be to refactor the interface functions so that they return an enum
      rather than a boolean (see T8084).
      Task: T8081
    • Elvis Angelaccio's avatar
      Mark canceled extractions as killed jobs · 92fe1c13
      Elvis Angelaccio authored
      If the user canceled an OverwriteQuery dialog, we should not claim the
      extraction finished. By emitting the canceled() signal, the extraction
      jobs will set the KilledJobError error and the plasma applet will not
      show the "Finished" string in the notification.
      BUG: 382601
      FIXED-IN: 17.12.3
      Task: T6707
  16. 03 Jan, 2018 1 commit
    • Elvis Angelaccio's avatar
      Fix threading issue · d5fdd114
      Elvis Angelaccio authored
      `CreateJob::doWork()` might be executed in another thread (if we are
      using the libarchive or libzip plugin), so any QObject created there
      cannot use `this` as parent (since the CreateJob had been created
      in the main thread).
      We don't actually need to create an Entry object here, since all the
      interfaces have checks for null destination entries.
      Fixes T7206
  17. 18 Nov, 2017 1 commit
    • Elvis Angelaccio's avatar
      ExtractJob: set destination URL in the job description · 52cbbd80
      Elvis Angelaccio authored
      The plasma notification applet looks for it for the "Open" button within
      the notification. If it doesn't find it, it falls back to the archive
      URL which is not what one would expect.
      BUG: 385043
      FIXED-IN: 17.11.90
      Differential Revision: D8861
  18. 08 Nov, 2017 1 commit
  19. 19 Apr, 2017 1 commit
    • Xuetian Weng's avatar
      Fix a I18n problem caused by using i18n and i18np in two places. · 29f9fc8d
      Xuetian Weng authored
      There are two entries with "Extracting one file". The one is called with
      i18n and the other is called with i18np. Thus it confuses the translation
      to use "Extracting %1 files" in i18n() version which is a problem for
      languages with "Plural-Forms: nplurals=1; plural=0;". The actual result
      before this fix will be using the "%1" without arguments.
      Test Plan: Manually tested.
      Reviewers: rthomsen, elvisangelaccio
      Reviewed By: elvisangelaccio
      Subscribers: kde-utils-devel, #ark
      Tags: #ark
      Differential Revision: https://phabricator.kde.org/D5511
  20. 19 Mar, 2017 4 commits
  21. 13 Mar, 2017 1 commit
    • Elvis Angelaccio's avatar
      Improve AddJob description · 957cb17f
      Elvis Angelaccio authored
      'Adding a file' is too generic, 'Compressing a file' is what is actually
      going on.
      CCBUG: 377471
      Differential Revision: D5027
  22. 08 Jan, 2017 1 commit
    • Elvis Angelaccio's avatar
      Properly kill AddToArchive jobs · e777831f
      Elvis Angelaccio authored
      Both AddToArchive and CreateJob are wrapper jobs, they need to implement
      doKill() and call kill() on the actual jobs that are doing the work.
      BUG: 374433
      FIXED-IN: 16.12.1
      Differential Revision: D4000
  23. 22 Dec, 2016 1 commit
  24. 27 Nov, 2016 2 commits
    • Elvis Angelaccio's avatar
      Properly kill BatchExtract jobs · 864d77f1
      Elvis Angelaccio authored
      We need to reimplement `KJob::doKill()` both in `BatchExtract` and
      `BatchExtractJob`. In the latter class we use an enum to keep track of which
      sub-job we are running and kill it when necessary.
      Differential Revision: https://phabricator.kde.org/D3521
    • Elvis Angelaccio's avatar
      Don't show two progress bars with batch extractions · 660076c4
      Elvis Angelaccio authored
      BatchExtractJob runs a LoadJob first and an ExtractJob after, which results in two
      different progress bars in the notification tray. This patch changes how the
      percentage is computed: the first 50% is from the LoadJob, the 2nd 50% from the
      ExtractJob. This ensures that only one progress bar shows up while the wrapper job
      is running. This will only work if the interface is able to report progress for
      both LoadJobs and ExtractJobs (currently only libarchive and clirar).
      Differential Revision: D3518
  25. 26 Nov, 2016 1 commit
    • Elvis Angelaccio's avatar
      Fix percentage progress in batch extractions · 32439e4d
      Elvis Angelaccio authored
      The new BatchExtractJob needs to forward the progress() signal (emitted
      when the underlying ExtractJob runs) to its own onProgress() slot. This
      works because the archiveInterface() instance is the same for both jobs.
  26. 15 Nov, 2016 1 commit
  27. 05 Nov, 2016 1 commit
    • Elvis Angelaccio's avatar
      Simplify Query usage in CLI plugins · 9f3e8511
      Elvis Angelaccio authored
      The Query was still assuming that all plugins run from a secondary
      Since CliInterface-based plugins run from the main thread, there is no need to
      emit the `userQuery` signal and then call `Query::waitForResponse()`.
      They can directly call `Query::execute()` instead.
      Differential Revision: D3217
  28. 20 Oct, 2016 2 commits
    • Elvis Angelaccio's avatar
      Fix race condition in LoadJob · 1121db92
      Elvis Angelaccio authored
      Currently `extracttest` has random failures when we check properties
      with the libarchive plugin.
      This happens because there is a race condition between
      `LoadJob::onFinished()` (where we read some `LoadJob` members) and
      `LoadJob::onNewEntry()` (where we write those members).
      `onFinished()` is called when `list()` returns, in `LoadJob::doWork()`.
      But that might happen before `onNewEntry()` is called, since they are executed
      in two different threads.
      This patch puts the `onFinished()` call in the event queue, just like the
      single-thread case does (where we emit the `finished` signal from `CliInterface`).
      Differential Revision: D3111
    • Elvis Angelaccio's avatar
      GIT_SILENT Fix debug messages · 5b7544ba
      Elvis Angelaccio authored
      Jobs are not started when created.
  29. 17 Oct, 2016 3 commits
    • Elvis Angelaccio's avatar
      Move entryRemoved signal to the read-write interface · 768117e6
      Elvis Angelaccio authored
      Read-only interfaces cannot remove entries, so they should never emit this signal.
      Differential Revision: D3090
    • Ragnar Thomsen's avatar
      Show progress in percentage for all job types in LibarchivePlugin · ef1753b4
      Ragnar Thomsen authored
      Progress is now also shown in percentage for Addjob, CopyJob, DeleteJob
      and MoveJob for archives handled by LibarchivePlugin. This was a bit
      tricky due to libarchive always iterating the whole archive and means
      that the plugin needs to know the total number of existing archive
      A new member variable m_numberOfEntries was added to
      ReadOnlyArchiveInterface, which holds the total number of entries in the
      archive. The variable is kept up-to-date by incrementing/decrementing it
      whenever the entry and entryRemoved signals are emitted by a plugin.
      This necessitated a slight rework of the handling of MoveJob and CopyJob
      by LibarchivePlugin because these emitted entry when iterating over the
      old entries. The new approach should also be more efficient.
      The two Archive members m_numberOfFiles and m_numberOfFolders were
      ReadOnlyArchiveInterface::addFiles() got an additional argument of type
      uint that holds the number of entries to be added.
      Differential Revision: D3072
    • Elvis Angelaccio's avatar
      Add missing Q_OBJECT macros · 8aaf9693
      Elvis Angelaccio authored