1. 12 Aug, 2019 1 commit
  2. 01 Mar, 2019 2 commits
    • Allan McRae's avatar
      Release v5.1.3 · 1bf76723
      Allan McRae authored
      
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      1bf76723
    • Andrew Gregory's avatar
      Sanitize file name received from Content-Disposition header · 97027036
      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>
      (cherry picked from commit d197d8ab)
      97027036
  3. 25 Dec, 2018 2 commits
  4. 23 Dec, 2018 1 commit
  5. 12 Dec, 2018 1 commit
  6. 19 Nov, 2018 8 commits
  7. 27 Jul, 2018 7 commits
    • Allan McRae's avatar
      Release v5.1.1 · 7e081d2a
      Allan McRae authored
      
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      7e081d2a
    • Eli Schwartz's avatar
      makepkg: optimize and fix BUILDINFO generation's use of awk · 1a5f308d
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      
      
      The biggest issue is directly supplying the data within the format
      string which can result in misinterpreting formatter sequences if a
      printed variable contains an "%" in it. This character is currently
      permitted in the pkgver field, though not in the pkgname. Also
      pacman/libalpm itself has much looser limitations and this can appear
      anywhere at all if a package was created by some other program.
      
      For the package "iambroke-1%s-1-any.pkg.tar.xz", installed in the build
      environment, the result is:
      
        -> Generating .BUILDINFO file...
      awk: cmd. line:3: (FILENAME=- FNR=1085) fatal: not enough arguments to satisfy format string
      	`-1%s-1'
      	   ^ ran out for this one
      
      Followed by a .BUILDINFO which contains an LC_ALL=C sorted list of
      $pkgname-${epoch:+$epoch:}$pkgver-$pkgrel-$arch ending in:
      
      installed = iambroke
      
      Which is cut short, then fails to list the succeeding packages. The
      package itself successfully builds.
      
      It's also unnecessary to save the output of pacman -Qq in order to get the
      information for pacman -Qi, since the latter will, just like the former,
      return information for all installed packages if not given a package
      name(s).
      
      While I am at it, pipe this directly to awk rather than keeping a copy
      in an unnecessary local variable. This is slightly more efficient in
      addition to preventing the <<< herestring from re-interpreting the
      content of "$pkginfos" in ways that don't really matter for our usage.
      
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      1a5f308d
    • Jouke Witteveen's avatar
      alpm-hooks.5: include more information on hook files · 2d8a7519
      Jouke Witteveen authored and Allan McRae's avatar Allan McRae committed
      
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      2d8a7519
    • Allan McRae's avatar
      Pull updated translations from Transifex · 13fb2430
      Allan McRae authored
      
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      13fb2430
    • Allan McRae's avatar
      Handle root prefix in overwrite operations · 0827aff8
      Allan McRae authored
      
      
      The pacman --overwrite operation currently expects a path without
      the root prefix specified.  This is unexpected, particularly
      given our conflict error message reports the path with the root
      prefix included.
      
      This patch allows libalpm to overwrite files with the root prefix
      specified.
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      0827aff8
    • Eli Schwartz's avatar
      makepkg: reduce strictness of pkgver in depends linting · 316b031b
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      
      
      This change was introduced to prevent entries like depends=('foo>').
      However, it had the unintended side effect of causing a number of
      working PKGBUILDs to fail to build. This happened when a PKGBUILD
      defined one variable through calling a "complex" statement within the
      PKGBUILD's package function (e.g. a function or evaluating in a
      subshell), then used it to define the package metadata variable.
      
      extract_function_variable() cannot execute the package function in order
      to retrieve this information, so it performs a simple grep + eval instead
      and in the process misses the contextual awareness of running within the
      package function.
      
      While not catching these "issues" can result in incorrect SRCINFO, the
      resulting packages are fine. Stop aborting on the common case where the
      pkgver of a dependency is dynamically set during the package function
      until the large number of broken PKGBUILDs are fixed, and the
      restrictions of the PKGBUILD format are documented.
      
      "Fixes" FS#58776
      
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      316b031b
    • Michael Straube's avatar
      makepkg.conf: add missing sha224 sums · 757e85b2
      Michael Straube authored and Allan McRae's avatar Allan McRae committed
      
      
      Add missing sha224 sums to makepkg.conf and it's man page.
      
      Signed-off-by: default avatarMichael Straube <michael.straube@posteo.de>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      757e85b2
  8. 24 Jul, 2018 2 commits
  9. 19 Jul, 2018 3 commits
  10. 19 Jun, 2018 1 commit
  11. 18 Jun, 2018 12 commits