From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 5524C138334 for ; Sun, 7 Oct 2018 13:25:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0B3FFE0A02; Sun, 7 Oct 2018 13:25:05 +0000 (UTC) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 661C8E09F1 for ; Sun, 7 Oct 2018 13:25:04 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id c26-v6so7643384edt.3 for ; Sun, 07 Oct 2018 06:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gSPD9CjnYXr+v1CU7mGZk3/voc0O9qymkT2QLCGvBy8=; b=jjjXAy7xEOw/zlJmJg8Ck8rmtgScy4zWjK8/UUL7GauMagUd3zyd0NK4wcCHKA+V9g mFBHN/WNvFVvNmVixqao/HWxD7lFRtqjn9FvweQEnkpOIG99zL0nZqqDL1X+Y015l33r 1hIkz19B9yce28M9Yd8iuxUjBkPjH+jCmVp7YobE4+6xeczWb0iI6c+gUY7I4gpcecpB 5DGRNiOUc5Xn4T/DqUm7okvWByytHPOgSciptpCWp653mSXAlpzxqdMWe38eMPG0hnEF WHY35wgsxpzY1oKZB9NfXcFCC6iS4gEzVPkhBIWxUqRep33hT7xxUmm74IWwcilZS3+h pxpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gSPD9CjnYXr+v1CU7mGZk3/voc0O9qymkT2QLCGvBy8=; b=hEmk845ezW3KZJUPkZ1lujLuHEnZ7gqfTxINBMMJWR+WaU00wvlbcb8kvAI1LJvsKl NMcM8xghXsmWEeWAevdLPLKps6qz7RtbrEQ1ZeOYwd/R1LI53clgvGJepqQ31KAJIpt/ 013Gf6X0a3uaOXLA3EruRfHLCXl7fAEyG1fUgrKWJ/UWxa58dSyRe9fUFQqstq797nxx oSG5mEHsNRtS1SOTe0q04uNU2ktpr4sVEi7qTbKIvI2nvgcEJFIxVKlMvv0VBamkDUIg PpYbeZ01/RnT5jX/fJ78g/i6BdOqxcZJoNEmw9zCHhegVFeSlyx0K0/1fuR2EiYsKz5k FF8Q== X-Gm-Message-State: ABuFfojehHDTS6aU1E7+/mqhC3i6qM3xwDuolnWPK8GflTCY02zyDd9M 5+4JUFpIU2YGzZMytoDP41Eo7iH+z+vXRmYjCNyEpQ== X-Google-Smtp-Source: ACcGV62wp46cp7IYrHWBglEzrY+DDd9oVKO2Z+jLZ4UaQ8ZI1KadRmLr2mJPcfFszRNNwqkjpQUIRVsQRWC+lPTdarA= X-Received: by 2002:a50:90d8:: with SMTP id d24-v6mr22735869eda.228.1538918702529; Sun, 07 Oct 2018 06:25:02 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 References: <20181006111750.34898-1-hilobakho@gmail.com> In-Reply-To: <20181006111750.34898-1-hilobakho@gmail.com> From: Bernd Waibel Date: Sun, 7 Oct 2018 15:24:50 +0200 Message-ID: Subject: Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass To: gentoo-dev@lists.gentoo.org Cc: Mykyta Holubakha Content-Type: multipart/alternative; boundary="0000000000009a41200577a36e16" X-Archives-Salt: d654cc95-84bc-4d98-b959-5d7a818bba5b X-Archives-Hash: 5134704c5648e19478d054c291e13f37 --0000000000009a41200577a36e16 Content-Type: text/plain; charset="UTF-8" Mykyta Holubakha schrieb am Sa., 6. Okt. 2018 um 13:18 Uhr: > Signed-off-by: Mykyta Holubakha > > I'm proposing to add a new eclass: appimage.eclass, to facilitate > extraction off AppImage bundles. The rationale is that some upstreams > have migrated to distributing their proprietary software exclusively as > AppImage bundles. (for instance dev-util/staruml-bin). > > An example ebuild can be seen at https://git.io/fx3Mg > > I was also thinking of something, too. This direction of development happens for a couple of years already, with more and more vendors / upstream jumping on it. It was also highly recommended by Linus Torvalds as a way of distributing packages easily along different linux flavors. I don't think we should easily deny the direction where this is going. Most appimages are distributed through central well-known servers. The files have a sha1 BuildID attached to them (can be seen via file command), which can possibly be used to verify them, so decreasing the possible vulnerability to such packages somewhat. There might also be additional ways to verify the integrity of them through the appimage API. They are statically linked packages with no external dependencies, and contain a squashfs filesystem in it. >From a users point of view, I think it'd be a good idea, to give users the possibility of installing appimages with the package manager, so they can be handled accordingly, instead of just let them download the files and move them into a separate folder in ${HOME} for execution. This would be especially useful for propietary bin-packages, as well as for some big packages, which are actually hard to maintain for proxy-maintainers, and therefore get removed from the tree (freecad comes to my mind as an example). 2. Are we OK with executing AppImage bundles downloaded from the > Internet (an alternative would be to implement a proper extractor > program, which would unpack the images without executing them, and add > it to DEPENDs). > It think, this has mostly the same attack vectors which apply for bin-packages. So there's not much new from my point of view. > +# @FUNCTION: appimage_src_unpack > +# @DESCRIPTION: > +# Unpack all the AppImage bundles from ${A} (with .appimage extension). > +# Other files are passed to regular unpack. > I'm not sure, if it makes sense to unpack them. Most of them are not built on gentoo systems, so the extracted binaries and libraries might not easily run without having the ebuild maintainer check every single one of them for run-time dependencies. For example, the freecad appimage contains a bin/mkdir program linked against libselinux.so.1 which is not available on non-selinux profiles by default, or its usr/lib/freecad/lib/DraftUtils.so, a freecad internal library, links against libboost_system.so.1.55.0 while we have libboost_system.so.1.65.0. I would propose to keep them packed and install them in /opt/AppImages or something like that, thus providing only a src_install function with the eclass. Ebuild maintainers could then just add a .desktop file or extract one from the image if it's present and add it to the files/ directory for desktop integration. --0000000000009a41200577a36e16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mykyta Hol= ubakha <hilobakho@gmail.com&g= t; schrieb am Sa., 6. Okt. 2018 um 13:18=C2=A0Uhr:
Signed-off-by: Mykyta Holubakha <hilobakho@gmail.com>

I'm proposing to add a new eclass: appimage.eclass, to facilitate
extraction off AppImage bundles. The rationale is that some upstreams
have migrated to distributing their proprietary software exclusively as
AppImage bundles. (for instance dev-util/staruml-bin).

An example ebuild can be seen at https://git.io/fx3Mg

=C2=A0
I was also thinking of something, to= o. This direction of development happens for a couple of years already, wit= h more and more vendors / upstream jumping on it. It was also highly recomm= ended by Linus Torvalds as a way of distributing packages easily along diff= erent linux flavors. I don't think we should easily deny the direction = where this is going.

Most appimages are distribute= d through central well-known servers. The files have a sha1 BuildID attache= d to them (can be seen via file command), which can possibly be used to ver= ify them, so decreasing the possible vulnerability to such packages somewha= t. There might also be additional ways to verify the integrity of them thro= ugh the appimage API. They are statically linked packages with no external = dependencies, and contain a squashfs filesystem in it.

=
From a users point of view, I think it'd be a good idea, to give u= sers the possibility of installing appimages with the package manager, so t= hey can be handled accordingly, instead of just let them download the files= and move them into a separate folder in ${HOME} for execution. This would = be especially useful for propietary bin-packages, as well as for some big p= ackages, which are actually hard to maintain for proxy-maintainers, and the= refore get removed from the tree (freecad comes to my mind as an example).<= /div>

2. Are we OK with executing AppImage bundles downloaded from the
Internet (an alternative would be to implement a proper extractor
program, which would unpack the images without executing them, and add
it to DEPENDs).

It think, this has most= ly the same attack vectors which apply for bin-packages. So there's not= much new from my point of view.
=C2=A0
+# @FUNCTION: appimage_src_unpack
+# @DESCRIPTION:
+# Unpack all the AppImage bundles from ${A} (with .appimage extension). +# Other files are passed to regular unpack.

I'm not sure, if it makes sense to unpack them. Most of them are = not built on gentoo systems, so the extracted binaries and libraries might = not easily run without having the ebuild maintainer check every single one = of them for run-time dependencies.

For example, th= e freecad appimage contains a bin/mkdir program linked against libselinux.s= o.1 which is not available on non-selinux profiles by default, or its usr/l= ib/freecad/lib/DraftUtils.so, a freecad internal library, links against lib= boost_system.so.1.55.0 while we have libboost_system.so.1.65.0.
<= br>
I would propose to keep them packed and install them in /opt/= AppImages or something like that, thus providing only a src_install functio= n with the eclass. Ebuild maintainers could then just add a .desktop file o= r extract one from the image if it's present and add it to the files/ d= irectory for desktop integration.

--0000000000009a41200577a36e16--