On 6/17/19 11:11 AM, Manuel Reimer wrote: > On 16.06.19 17:57, Eli Schwartz via arch-general wrote: >> As a matter of fact, if you use clean chroot builds >> then you possibly don't want to copy your private key to the chroot, and >> anyway there have IIRC been bugs with signing in a chroot, so the >> devtools scripts do not do signing in the chroot and the official upload >> scripts for core/extra/community will do gpg --detach--sign --no-armor >> by hand, so you are in good company! > > I don't do builds in "chroot" environment. TBH I never managed to get > this to build completely automatic. The problem is that the existing > scripts start off in a unprivileged context and then require me to enter > the root password when entering the chroot. > > My own concept does it the other way around. Main script runs as root > and it forks off unprivileged processes to do the build. After building > this forked process exits and the "root-privileged" host process takes > over again to prepare for the next package build. This includes required > dependency installs. > > https://github.com/M-Reimer/repo-make > > All this runs on a dedicated "Build VM" on Oracle Virtual Box. > > Yes, I get "clean" builds with this, as between every build step, all > unneeded dependency packages are uninstalled. This is a perfectly suitable implementation of a clean build, so if it works for you, great! That being said, it's possible to configure sudo to run makechrootpkg, but only makechrootpkg, as root. Or run SUDO_USER=... SUDO_UID=... makechrootpkg. > Maybe there are other fully automatic systems out there, but my script > served me well, so far. > > I was just wondering if there is any way to not have to have the private > key on this build VM at all. But I guess if something goes wrong on this > VM, then security is gone anyway. Yes -- do all signing locally, after the package leaves the build VM. If something goes wrong on the VM, you can remove the relevant packages without, say, revoking your key, so the security issue is less drastic. > But thanks for the information about how the signing works. I think I'll > move this out of the "unprivileged build process" and do the signing in > the root-privileged main process. This way the dedicated build user of > this build VM does not have access to the private key. -- Eli Schwartz Bug Wrangler and Trusted User
Attachment:
signature.asc
Description: OpenPGP digital signature
