[Solved] PKGBUILD user error prevention vs intrusive sanity checks.

milomouse · 2011-03-04 01:51:45

I read over the AUR packaging standards and am pretty familiar with creating PKGBUILDs but I'm uncertain on how to proceed when I need to check a system file so the user doesn't accidently install a package that may or may not mess up their system. I don't know how I feel about checking a user's system files from within a PKGBUILD. To be more specific; I'm maintaining "util-linux-aes" which is the util-linux package with loop-AES support (via patch). As brought to my attention by 'gemon' on the AUR page: http://aur.archlinux.org/packages.php?ID=47060 I should probably check if user has a kernel with loop-AES (loop.[k]o) patched as it may cause harm to their system if they use util-linux-aes and don't have a patched kernel. I'm somewhat torn about how to address the situation. Should a simple echo message suffice, giving warning about installing or should I insert code (as shown below) to check for proper kernel config options?

I thought about adding a kernel config check in a util-linux-aes.install file but if it returns or exits with 1 the package still installs. So I had to migrate the check to the PKGBUILD itself (which makes more sense I guess) and I'm not sure if this is considered an "intrusion" and/or unclean method of dealing with this. To make things more clear, here's my proposed PKGBUILD (current PKGBUILD doesn't have the config check):

# Maintainer: milomouse <vincent[at]fea.st>
# Contributor: judd <jvinet[at]zeroflux.org>

_basename=util-linux
pkgname=${_basename}-aes
pkgver=2.19
pkgrel=5
pkgdesc="Miscellaneous system utilities for Linux, with loop-AES support"
url="http://userweb.kernel.org/~kzak/util-linux-ng/"
license=('GPL2')
arch=('i686' 'x86_64')
groups=('base')
depends=('bash' 'ncurses>=5.7' 'zlib' 'filesystem')
optdepends=('perl: for chkdupexe support')
provides=('linux32' "util-linux=${pkgver}" "util-linux-ng=${pkgver}")
conflicts=('linux32' 'util-linux' 'util-linux-ng' 'e2fsprogs<1.41.8-2')
replaces=('linux32' 'util-linux' 'util-linux-ng')
options=('!libtool')
_loopaesdate=20110226
_loopaesvers=v3.6b
_loopaesdiff=${_basename}-${pkgver}.diff
source=(http://www.kernel.org/pub/linux/utils/${_basename}/v${pkgver}/${_basename}-${pkgver}.tar.bz2
        http://downloads.sourceforge.net/project/loop-aes/loop-aes/${_loopaesvers}/loop-AES-${_loopaesvers}.tar.bz2)

build() {
  cd "${srcdir}/${_basename}-${pkgver}"
  # check for compatability first
  warning "You must also have a loop-AES patched kernel (loop.ko) for this to work."
  warning "You may end up damaging your system otherwise. Checking now..."
  if [[ -f /proc/config.gz ]]; then
    if [[ $(zgrep CONFIG_BLK_DEV_LOOP= /proc/config.gz) == CONFIG_BLK_DEV_LOOP=[ym] && \
          $(zgrep CONFIG_BLK_DEV_LOOP_AES= /proc/config.gz) == CONFIG_BLK_DEV_LOOP_AES=y ]]; then
      msg "Everything looks OK."
    else
      error "CONFIG_BLK_DEV_LOOP / CONFIG_BLK_DEV_LOOP_AES are not correct, aborting!"
      return 1
    fi
  elif [[ -f /usr/src/linux-$(uname -r)/.config ]]; then
    if [[ $(zgrep CONFIG_BLK_DEV_LOOP= /usr/src/linux-$(uname -r)/.config) == CONFIG_BLK_DEV_LOOP=[ym] && \
          $(zgrep CONFIG_BLK_DEV_LOOP_AES= /usr/src/linux-$(uname -r)/.config) == CONFIG_BLK_DEV_LOOP_AES=y ]]; then
      msg "Everything looks OK."
    else
      error "CONFIG_BLK_DEV_LOOP / CONFIG_BLK_DEV_LOOP_AES are not correct, aborting!"
      return 1
    fi
  else
    error "Cannot find a kernel config to check options, aborting build!"
    error "If you're POSITIVE you have a patched kernel, edit PKGBUILD to remove this."
    return 1
  fi
  # if all went well; provide loop-aes support
  patch -Np1 -i "${srcdir}/loop-AES-${_loopaesvers}/${_loopaesdiff}"
  # hardware clock
  sed -e 's%etc/adjtime%var/lib/hwclock/adjtime%' -i hwclock/hwclock.c
  autoreconf
  automake
  ./configure --enable-arch --enable-write --enable-raw --disable-wall --enable-partx
  make
}

package() {
  cd "${srcdir}/${_basename}-${pkgver}"
  mkdir -p "${pkgdir}/var/lib/hwclock"
  make DESTDIR="${pkgdir}" install
}

md5sums=(
      '590ca71aad0b254e2631d84401f28255'  # util-linux-2.19.tar.bz2
      '247e5a909877577bdcd246f8caada689') # loop-AES-v3.6b.tar.bz2
sha384sums=(
  '05e8e3a2685ff47c57d56bf9d5bfc9cbe5c1fa85200f403c5ccc08676b9b713fc935b3b040d5d5dcd2c5aa14b631f1bd'  # util-linux-2.19.tar.bz2
  '48ee55e996464f613d68e04bc661997a846989fef4d8a21fb0647c126c64e5ecdb218a37c75f6d3baccfebb2d89503ea') # loop-AES-v3.6b.tar.bz2

Is it too much [attempting to help the user] by doing this sort of check, is it considered bad practice?

Even if it's ok, I don't know if I'm going about checking this correctly, although in my mind it makes sense. Checking against the kernel config, I mean.

Advice on any of these aspects is appreciated, as I'd hate to think I'd unwittingly let a user harm their computer somehow by not checking or at least warning. Again, my main concern is if this is considered bad practice and if it is what are my alternatives. (if this has been discussed before, I'm sorry, just point me in the right direction, thanks).

Thanks for reading.

Last edited by milomouse (2011-03-04 15:51:50)

ngoonee · 2011-03-04 01:54:16

Just warn them in a message in .install. Or depend on an AUR kernel with the patch.

I think its safe to assume that Arch users have the technical competency, especially those who will be using 'niche' PKGBUILDs such as this. Those who aren't and are simply looking for something to play with deserve any system corruption they get, IMO

milomouse · 2011-03-04 02:10:13

@ngoonee:
My first instincts told me as such (also noted on AUR page comments), that a user should well know what this package is and what it does and need not be checked against their system, and those without the knowledge shouldn't be messing with it in the first place. But with another user of the package bringing the attention that some poor user might install this without full knowledge of it's implementation and/or thinking this package by itself may provide loop-AES (unknowing of kernel patch) they might fall prey to unbeknownst side-effects.

I guess a warning message will suffice for sanity's sake [under pre_install(), I guess], as I don't think I should create depends on an AUR kernel with current loop-AES support that I don't maintain myself (otherwise I'd have to follow it's inclusion).

Thanks for the support, though, albeit a bit rough. But for future reference; is checking a user's system files considered OK or should the same rules as this package apply (user knowledge)? I can't imagine every package installing OK without at least one of them checking against a user's current setup.

ngoonee · 2011-03-04 05:51:03

milomouse wrote:

@ngoonee:
My first instincts told me as such (also noted on AUR page comments), that a user should well know what this package is and what it does and need not be checked against their system, and those without the knowledge shouldn't be messing with it in the first place. But with another user of the package bringing the attention that some poor user might install this without full knowledge of it's implementation and/or thinking this package by itself may provide loop-AES (unknowing of kernel patch) they might fall prey to unbeknownst side-effects.
I guess a warning message will suffice for sanity's sake [under pre_install(), I guess], as I don't think I should create depends on an AUR kernel with current loop-AES support that I don't maintain myself (otherwise I'd have to follow it's inclusion).
Thanks for the support, though, albeit a bit rough. But for future reference; is checking a user's system files considered OK or should the same rules as this package apply (user knowledge)? I can't imagine every package installing OK without at least one of them checking against a user's current setup.

In general I don't think checking the current system is 'okay'. PKGBUILDs are meant to create packages. There's no reason these need to be created on the same system as they will be installed on (perhaps a chroot would be used just for building, or a buildserver). Or maybe someone may have multiple machines which share packages or the cache.

A depends would be the best option in this case, followed by the warning (the former does not mean the latter is not needed). Your check would fail in the cases I outline in the previous paragraph.

milomouse · 2011-03-04 14:36:44

Ah, you're right. I forgot about build environments. Will keep this in mind if I ever encounter such a situation again. Thanks for all the information, by the way, I think I have what I need.

ngoonee · 2011-03-04 15:25:26

You're welcome, marking the thread [solved] would be good.

gemon · 2011-03-05 10:25:45

sorry for replying to a solved post, but I just wanted to thank milomouse for at least evaluating my suggestions.
I too agree that the best option is to just put a warning, expecially for what ngonee tells about building environments and that a package could be built in a box and installed elsewhere.

I do believe that best option would be to provide an aur package with patched kernel, but I guess that would be a harder maintenance - as for loop-aes, not only CONFIG_BLK_DEV_LOOP must not be set, but if you want root encryption you have to enable more config options builtin in the kernel. What would we do, an aur kernel-aes and an aur kernel-aes-root? that's not gonna be quite maintenable, imho...

however thanks everybody!
regards
Gemon

milomouse · 2011-03-05 19:11:30

@gemon: not a problem; this is how problems get solved. community!
and yeah, i think there are too many variables to consider in assuming what the user is or isn't using in relation to loop-AES. we could very well maintain a loop-AES patched kernel (or 2) in the AUR but the user could just as easily change settings when they compile so there's no telling. i still think it should be up to the user after a clear warning messege has been issued in the .install file. that's not saying you can't maintain a kernel in the AUR if you want; i guess i could put it as an opt-depends and add more info/warnings in the install file.

Arch Linux

#1 2011-03-04 01:51:45

[Solved] PKGBUILD user error prevention vs intrusive sanity checks.

#2 2011-03-04 01:54:16

Re: [Solved] PKGBUILD user error prevention vs intrusive sanity checks.

#3 2011-03-04 02:10:13

Re: [Solved] PKGBUILD user error prevention vs intrusive sanity checks.

#4 2011-03-04 05:51:03

Re: [Solved] PKGBUILD user error prevention vs intrusive sanity checks.

#5 2011-03-04 14:36:44

Re: [Solved] PKGBUILD user error prevention vs intrusive sanity checks.

#6 2011-03-04 15:25:26

Re: [Solved] PKGBUILD user error prevention vs intrusive sanity checks.

#7 2011-03-05 10:25:45

Re: [Solved] PKGBUILD user error prevention vs intrusive sanity checks.

#8 2011-03-05 19:11:30

Re: [Solved] PKGBUILD user error prevention vs intrusive sanity checks.

Board footer