4 ms·

Why especially upgrades? Upgrades are way easier to review than new installs. Most diffs I see are just these two lines: -pkgver=1.7.2 +pkgver=1.7.3 -sh

Why especially upgrades? Upgrades are way easier to review than new installs. Most diffs I see are just these two lines: -pkgver=1.7.2 +pkgver=1.7.3 -sha256sums=('aaaaaaaaaa') +sha256sums=('bbbbbbbbbb') It takes like 5 seconds to read and press Y.

dijit 3mo ago
Cool theory, but the same reason I pull my shoes off by standing on my heel and pulling, despite it saving me no time (I will have to untie them anyway when I put them on again). Humans are short sighted, want to solve the situation immediately and will do the laziest thing possible to accomplish a given task.
- 0gs 3mo ago
  pop each lace down one eyelet and you'll never have to untie them again if the heel is both sturdy and forgiving enough
  - inversepolymath 3mo ago
    yeah but then it doesn't feel 'right'
dwedge 3mo ago
Call me naive (I don't use arch) but if that's the only change then what's the point releasing the change? Unless pkgver refers to an external dependency or a binary, in which case you might as well say reading the changelog counts as reading the code
- embedding-shape 3mo ago
  Usually you concat them to form the GitHub tarball URL or similar, so on updates you only review the version/hash bumps, as on install you've validated the right GitHub organization/domain already. Babashka has this for example (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=babashka-bin https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=babas...): pkgname=babashka-bin pkgver=1.13.219 url='https://github.com/borkdude/babashka' source_x86_64=("${pkgname}-${pkgver}-linux-amd64-static.tar.gz::${url}/releases/download/v${pkgver}/${pkgname%-bin}-${pkgver}-linux-amd64-static.tar.gz") So on install, you review ideally everything, but at least the URL/organization/domain. Then on updates, you've already validated them, so the pkgver bump is the only thing of interest.
- OJFord 3mo ago
  AUR packages consist of packaging a third-party software (whether binary or source built as part of the package) for use on Arch. Most updates are just bumping the upstream software version and its checksum, as GP describes, and yes arguably you should be reviewing the change to that software too, but that's a separate threat. And it may be a proprietary binary, in which case on update you've already decided to trust the third-party, so the diff shows you that nothing has changed in that regard, the trusted party simply released a new opaque version.
- nvme0n1p1 3mo ago
  The version string is used to build an external URL. You're right, I don't audit every line of code in new versions of Firefox/Chrome/etc. I chose to trust the download URL when I first installed that package. Then on updates, I can check at a glance that the script hasn't changed to point to another URL or in other suspicious ways. There are two possible threats here: "random AUR user" and "Google". I'm protected from the former deciding to bundle malware, but not the latter.

dijit 3mo ago

Cool theory, but the same reason I pull my shoes off by standing on my heel and pulling, despite it saving me no time (I will have to untie them anyway when I put them on again). Humans are short sighted, want to solve the situation immediately and will do the laziest thing possible to accomplish a given task.

0gs 3mo ago
pop each lace down one eyelet and you'll never have to untie them again if the heel is both sturdy and forgiving enough
- inversepolymath 3mo ago
  yeah but then it doesn't feel 'right'

dwedge 3mo ago

Call me naive (I don't use arch) but if that's the only change then what's the point releasing the change? Unless pkgver refers to an external dependency or a binary, in which case you might as well say reading the changelog counts as reading the code

embedding-shape 3mo ago
Usually you concat them to form the GitHub tarball URL or similar, so on updates you only review the version/hash bumps, as on install you've validated the right GitHub organization/domain already. Babashka has this for example (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=babashka-bin https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=babas...): pkgname=babashka-bin pkgver=1.13.219 url='https://github.com/borkdude/babashka' source_x86_64=("${pkgname}-${pkgver}-linux-amd64-static.tar.gz::${url}/releases/download/v${pkgver}/${pkgname%-bin}-${pkgver}-linux-amd64-static.tar.gz") So on install, you review ideally everything, but at least the URL/organization/domain. Then on updates, you've already validated them, so the pkgver bump is the only thing of interest.
OJFord 3mo ago
AUR packages consist of packaging a third-party software (whether binary or source built as part of the package) for use on Arch. Most updates are just bumping the upstream software version and its checksum, as GP describes, and yes arguably you should be reviewing the change to that software too, but that's a separate threat. And it may be a proprietary binary, in which case on update you've already decided to trust the third-party, so the diff shows you that nothing has changed in that regard, the trusted party simply released a new opaque version.
nvme0n1p1 3mo ago
The version string is used to build an external URL. You're right, I don't audit every line of code in new versions of Firefox/Chrome/etc. I chose to trust the download URL when I first installed that package. Then on updates, I can check at a glance that the script hasn't changed to point to another URL or in other suspicious ways. There are two possible threats here: "random AUR user" and "Google". I'm protected from the former deciding to bundle malware, but not the latter.