[pacman-dev] Setting HOME in build() breaks package signing
Hi, a while back I came across a PKGBUILD which changed $HOME in build() as a workaround for a bad installer [1]. For some reason this failed to build with `makepkg --sign`, claiming it could not find my gpg key, see snippet below. After some time debugging this, I found changing $HOME broke the check for the key because gpg would look for it's .gnupg dir in the "new" $HOME, not the $HOME makepkg was started with. I solved this by editing the PKGBUILD to restore $HOME before exiting build(). I had thought changing $HOME was only used in that single case and didn't think much of it, but today a PKGBUILD [3] posted in a question on aur-general [2] reminded me of this and it seems this workaround is considered by packagers more commonly than I thought... This made me wonder: Is this something makepkg should take care of (e.g.by restoring $HOME after build() or ensuring gpg will use $OLDHOME/.gnupg) or should such a PKGBUILD be considered broken / invalid? $ makepkg --sign ==> Making package: broken-home 1-1 (Tue May 5 21:35:57 2020) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> Extracting sources... ==> Removing existing $pkgdir/ directory... ==> Starting build()... ==> Entering fakeroot environment... ==> ERROR: The key 06ABC843BA90E65B does not exist in your keyring. $ gpg --list-key 06ABC843BA90E65B :( pub rsa4096 2019-03-05 [SC] 59EB8C1AF8CFEBF4A683760206ABC843BA90E65B uid [ultimate] package signing key <brainpower@mailbox.org> sub rsa4096 2019-03-05 [E] $ cat PKGBUILD pkgname=broken-home pkgver=1 pkgrel=1 arch=('any') build() { export HOME="${srcdir}/tmphome" } package() { true } [1]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mongodb-compass-isolated&id=a714f2bb3a564e8b1e1659b999d719cfaf535c24#n48 [2]: https://lists.archlinux.org/pipermail/aur-general/2020-May/035729.html [3]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=intel-opencl-sdk&id=a426e7bc370edea770037b6ed61e22701e8a0397#n38 -- regards, brainpower
On 5/5/20 4:11 PM, brainpower wrote: [...]
This made me wonder: Is this something makepkg should take care of (e.g.by restoring $HOME after build() or ensuring gpg will use $OLDHOME/.gnupg) or should such a PKGBUILD be considered broken / invalid?
[...]
$ cat PKGBUILD pkgname=broken-home pkgver=1 pkgrel=1 arch=('any')
build() { export HOME="${srcdir}/tmphome" } I would argue this should probably be a 'local' variable. e.g.
build() { local HOME="${srcdir}/tmphome" some-command-that-needs-fakehome } Since HOME is previously marked as exportable, it is still getting exported, and modifying an exported variable causes the changes to be picked up. So this is identical: export somevar somevar=foo vs. export somevar=foo vs. somevar=foo export somevar And the 'local' attribute coexists with the exported attribute: $ foo() { declare -p somevar; local somevar=foo; export somevar; env | \ grep somevar; declare -p somevar; }; foo bash: declare: somevar: not found somevar=foo declare -x somevar="foo" $ declare -p somevar bash: declare: somevar: not found -- Eli Schwartz Bug Wrangler and Trusted User
Am 05.05.20 um 22:40 schrieb Eli Schwartz:
On 5/5/20 4:11 PM, brainpower wrote: [...]
This made me wonder: Is this something makepkg should take care of (e.g.by restoring $HOME after build() or ensuring gpg will use $OLDHOME/.gnupg) or should such a PKGBUILD be considered broken / invalid?
[...]
$ cat PKGBUILD pkgname=broken-home pkgver=1 pkgrel=1 arch=('any')
build() { export HOME="${srcdir}/tmphome" } I would argue this should probably be a 'local' variable. e.g.
build() { local HOME="${srcdir}/tmphome" some-command-that-needs-fakehome }
Since HOME is previously marked as exportable, it is still getting exported, and modifying an exported variable causes the changes to be picked up.
This part I actually knew!
And the 'local' attribute coexists with the exported attribute:
But this I did not. Thanks for your answer! -- regards, brainpower
participants (2)
-
brainpower
-
Eli Schwartz