1. 15 Nov, 2019 1 commit
    • Allan McRae's avatar
      Handle .part files that are the size of the correct package · e6a6d307
      Allan McRae authored
      
      
      In rare cases, likely due to a well timed Ctrl+C, but possibly due to a
      broken mirror, a ".part" file may have size at least that of the correct
      package size.
      
      When encountering this issue, currently pacman fails in different ways
      depending on where the package falls in the list to download.  If last,
      "wrong or NULL argument passed" error is reported, or a "invalid or
      corrupt package" issue if not.
      
      Capture these .part files, and remove the extension. This lets pacman
      either use the package if valid, or offer to remove it if it fails checksum
      or signature verification.
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      e6a6d307
  2. 23 Oct, 2019 1 commit
  3. 07 Oct, 2019 1 commit
    • Dave Reisner's avatar
      dload: never return NULL from get_filename · 0c4a8ae2
      Dave Reisner authored and Allan McRae's avatar Allan McRae committed
      Downloads with a Content-Disposition header will typically not include
      slashes. When they do, we should most certainly only take the basename,
      but when they don't, we should treat the header value as the filename.
      
      Crash introduced in d197d8ab
      
       when we started using get_filename
      in order to rightfully avoid an arbitrary file overwrite vulnerability.
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      0c4a8ae2
  4. 28 Jun, 2019 1 commit
  5. 01 Mar, 2019 1 commit
    • Andrew Gregory's avatar
      Sanitize file name received from Content-Disposition header · d197d8ab
      Andrew Gregory authored and Allan McRae's avatar Allan McRae committed
      
      
      When installing a remote package with "pacman -U <url>", pacman renames
      the downloaded package file to match the name given in the
      Content-Disposition header. However, pacman does not sanitize this name,
      which may contain slashes, before calling rename(). A malicious server (or
      a network MitM if downloading over HTTP) can send a content-disposition
      header to make pacman place the file anywhere in the filesystem,
      potentially leading to arbitrary root code execution. Notably, this
      bypasses pacman's package signature checking.
      
      For example, a malicious package-hosting server (or a network
      man-in-the-middle, if downloading over HTTP) could serve the following
      header:
      
      Content-Disposition: filename=../../../../../../usr/share/libalpm/hooks/evil.hook
      
      and pacman would move the downloaded file to
      /usr/share/libalpm/hooks/evil.hook. This invocation of "pacman -U" would
      later fail, unable to find the downloaded package in the cache directory,
      but the hook file would remain in place. The commands in the malicious
      hook would then be run (as root) the next time any package is installed.
      
      Discovered-by: default avatarAdam Suhl <asuhl@mit.edu>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      d197d8ab
  6. 06 Feb, 2019 1 commit
  7. 18 Oct, 2018 2 commits
  8. 10 Aug, 2018 1 commit
  9. 18 Jun, 2018 1 commit
  10. 13 May, 2018 1 commit
    • Eli Schwartz's avatar
      Remove all modelines from the project · 860e4c49
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      
      
      Many of these are pointless (e.g. there is no need to explicitly turn on
      spellchecking and language dictionaries for the manpages by default).
      
      The only useful modelines are the ones enforcing the project coding
      standards for indentation style (and "maybe" filetype/syntax, but
      everything except the asciidoc manpages and makepkg.conf is already
      autodetected), and indent style can be applied more easily with
      .editorconfig
      
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      860e4c49
  11. 14 Mar, 2018 1 commit
  12. 06 Jan, 2018 1 commit
    • Andrew Gregory's avatar
      dload: ensure callback is always initialized once · 59bb21fc
      Andrew Gregory authored and Allan McRae's avatar Allan McRae committed
      
      
      Frontends rely on an initialization call for setup between downloads.
      Checking for intialization after checking for a completed download can
      skip initialization in cases where files are small enough to be
      downloaded all at once (FS#56408).  Relying on previous download size
      can result in multiple initializations if there are multiple
      non-transfer events prior to the download starting (fS#56468).
      
      Introduce a new cb_initialized variable to the payload struct and use it
      to ensure that the callback is initialized exactly once prior to any
      actual events.
      
      Fixes FS#56408, FS#56468
      
      Signed-off-by: default avatarAndrew Gregory <andrew.gregory.8@gmail.com>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      59bb21fc
  13. 13 Jan, 2017 1 commit
  14. 04 Jan, 2017 3 commits
  15. 05 Dec, 2016 2 commits
    • Martin Kühne's avatar
      Parametrise the different ways in which the payload is reset · e83e868a
      Martin Kühne authored and Allan McRae's avatar Allan McRae committed
      
      
      In FS#43434, Downloads which fail and are restarted on a different server
      will resume and may display a negative download speed. The payload's progress
      in libalpm was not properly reset which ultimately caused terminal noise
      because the line width calculation assumes positive download speeds.
      
      This patch fixes the incomplete reset of the payload by mimicing what
      be_sync.c:alpm_db_update() does over in sync.c:download_single_file().
      The new dload.c:_alpm_dload_payload_reset_for_retry() extends beyond the
      current behavior by updating initial_size and prevprogress for this case.
      This makes pacman reset the progress properly in the next invocation of the
      callback and display positive download speeds.
      
      Fixes FS#43434.
      
      Signed-off-by: default avatarMartin Kühne <mysatyre@gmail.com>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      e83e868a
    • Dave Reisner's avatar
      dload: use curl's keepalive mechanism · 7114ca62
      Dave Reisner authored and Allan McRae's avatar Allan McRae committed
      
      
      This does exactly the same thing as it code it replaces, but punt to
      curl to do it for brevity. Requires curl 7.25.0, which we already cover.
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      7114ca62
  16. 22 Oct, 2016 1 commit
  17. 31 Aug, 2016 1 commit
  18. 30 Aug, 2016 1 commit
  19. 04 Jan, 2016 1 commit
  20. 11 Nov, 2015 1 commit
  21. 01 Feb, 2015 1 commit
  22. 24 Dec, 2014 1 commit
  23. 19 Oct, 2014 1 commit
  24. 16 Oct, 2014 2 commits
  25. 02 Oct, 2014 1 commit
    • Olivier Brunel's avatar
      alpm: Fix wrong xferred/total sizes when resuming downloads · 1e3c088c
      Olivier Brunel authored and Allan McRae's avatar Allan McRae committed
      When a package is already partially downloaded in the cache, its download
      size will only be of what's left to be downloaded. Since pkg->download_size
      is what's used when calculating the total download size for the totaldl
      callback, same thing apply.
      
      However, the download progress callback was including this initial size,
      which would thus lead to invalid values (and percentage) used in frontends.
      That is, the progress bar could e.g. go further than 100%
      
      In the case of pacman, there is a sanity check for different historical
      reason (44a57c89
      
      ), so before the possible "overflow" was noticed, the total
      download size/progress reported was wrong. Once caught, the TotalDownload
      option was ignored and it would use individual file download values as
      fallback instead.
      
      Signed-off-by: default avatarOlivier Brunel <jjk@jjacky.com>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      1e3c088c
  26. 04 Aug, 2014 1 commit
  27. 22 May, 2014 1 commit
  28. 28 Jan, 2014 1 commit
  29. 06 Jan, 2014 1 commit
  30. 19 Dec, 2013 1 commit
  31. 15 Nov, 2013 1 commit
  32. 07 Nov, 2013 1 commit
  33. 18 Sep, 2013 1 commit
    • Christian Hesse's avatar
      dload: avoid renaming files downloaded via sync operations · 3b3152fc
      Christian Hesse authored and Allan McRae's avatar Allan McRae committed
      
      
      If the server redirects from ${repo}.db to ${repo}.db.tar.gz pacman gets
      this wrong: It saves to new filename and fails when accessing
      ${repo}.db.
      
      We need the remote filename only when downloading remote files with
      pacman's -U operation. This introduces a new field 'trust_remote_name'
      to payload. If set pacman downloads to the filename given by the server.
      
      The field trust_remote_name is set in alpm_fetch_pkgurl().
      
      Fixes FS#36791 ([pacman] downloads to wrong filename with redirect).
      
      [dave: remove redundant assignment leading to memory leak]
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      3b3152fc
  34. 21 Aug, 2013 1 commit
  35. 22 Jul, 2013 1 commit