On Thu, 16 May 2013, Natanael Copa wrote: > On Wed, 15 May 2013 13:10:06 -0500 > Serge Hallyn <serge.hal...@ubuntu.com> wrote: > >> Quoting Kaarle Ritvanen (kaarle.ritva...@datakunkku.fi): >> ... >>> + wget="wget -O - $repository/x86" >> .. >>> + $wget/apk-tools-static-$apk_version.apk | \ >>> + tar -Oxz sbin/apk.static > $apk || return 1 >>> + chmod u+x $apk >>> + >>> + apk_opts="$apk_opts --allow-untrusted" >>> + fi >>> + >>> + $apk add -U --initdb --root $rootfs $apk_opts "$@" alpine-base >> >> Boy does that scare me though. > > We could inline the public key(s) in the script so we could remove the > '--allow-intrusted' above. But verifying the sig for the static binary > might be tricky without having apk-tools installed already.
Installing and executing unverified binaries is done by other templates as well. For example, the Fedora template downloads the mirror list using plain HTTP and installs packages with yum --nogpgcheck, which is equivalent to apk --allow-untrusted. The configure_* functions then execute some installed stuff, albeit this is done in chroot. Would the template be less scary if it ran the statically linked apk in chroot? This would add some complexity, as the template would need to install at least static busybox and resolv.conf to the container root prior to invoking apk. BR, Kaarle ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
