[RFC] Technical proposal for fakeroot removal
by Max Rees
Hello,
As work towards the minimal viable product of APK Foundry nears
completion, I have been thinking of large scale trybuilds that can be
done in order to fully test its functionality. I think one such trybuild
that would also serve a functional purpose would be to begin work on
removing fakeroot(1) from the packaging process.
Most of the utility of using fakeroot in abuild currently is in order to
assign arbitrary user or group ownership to files before they are added
to the final .apk file. It does so by using an LD_PRELOAD hack to shadow
the libc's relevant functions, and uses a daemon to keep track of the
fake ownership of files.
As of this writing, there appears to be:
* 24 packages that use the $pkgusers and $pkggroups directives.
* 3 packages that only use the $pkggroups directive.
* 0 packages that only use the $pkgusers directive.
* 12 packages that use chown(1) or chgrp(1) in the APKBUILD, 8 of which
are not included in any of the above.
And an unknown amount of packages that perform their own chown or chgrp
during the vendor's installation process (this may later be estimated by
examining all available apks and checking for user, group != root).
In regards to a replacement, I think in absence of fakeroot we can
instead declaratively specify which files need special ownership
requirements through the use of libarchive's mtree(5) functionality. The
mtree file format is a BSD invention that describes the contents of a
tar file and allows for arbitrary specification of user and group
ownership as well as permissions, file type, etc.
By generating a de facto mtree for the package contents with
--uname root --gname root and allowing the packager to override this
mtree where necessary, I think the need for fakeroot can be mostly
eliminated.
This of course would have the side effect of tying abuild to the
libarchive implementation of bsdtar at runtime, unless we were to ship
our own utilities (built from libarchive I presume) to handle the
mtrees.
abuild would have an opaque shell function or similar that allows
specifying the file type, user ownership, group ownership, and
permissions for a file in the package. This function would then write to
a file in the control directory that contains the generated mtree
override(s), and merges that with the default root:root mtree before
using the merged mtree to build the data.tar.gz file.
For example, system/abuild itself needs to install /var/cache/distfiles
with abuild group ownership. The APKBUILD would have something like the
following instead of a chgrp:
> amtree -g abuild "$pkgdir"/var/cache/distfiles
The amtree function would translate this into an mtree entry and add it
to the $controldir/.mtree override file:
> var/cache/distfiles gname=abuild uname=root mode=775 type=dir
After merging the overrides with the default root:root mtree, libarchive
then supports reading an mtree file as a description from which to build
a tar file, like so:
> tar -cf data.tar.gz --uname=root --gname=root @$controldir/.mtree
I specifically think that the mtrees would have to be built on the fly
(not statically / version controlled) because some packages will of
course have filenames that differ between architectures. Thus if you
need an mtree for each (architecture + subpackage) combination, things
can quickly balloon.
To make this a gradual process we can also add some option to $options
if necessary.
Thoughts?
Max
10 months, 3 weeks
[RFC] Switching upstreams for system/nvi and system/unzip to Debian
by Max Rees
Hello,
I am proposing we switch upstreams for two packages in the system
repository to Debian due to our current upstreams having dried up.
Please leave your comments on this list or on the individual merge
requests.
Thanks,
Max Rees
===== system/unzip =====
The last release from Info-ZIP was 6.0 on 20 April 2009. Since that
time, the following nine CVEs have been issued and no upstream fixes
have been released:
> CVE-2014-8139: Heap-based buffer overflow in the CRC32 verification in
> Info-ZIP UnZip 6.0 and earlier allows remote attackers to execute
> arbitrary code via a crafted zip file in the -t command argument to the
> unzip command.
> CVE-2014-8140: Heap-based buffer overflow in the test_compr_eb function
> in Info-ZIP UnZip 6.0 and earlier allows remote attackers to execute
> arbitrary code via a crafted zip file in the -t command argument to the
> unzip command.
> CVE-2014-8141: Heap-based buffer overflow in the getZip64Data function
> in Info-ZIP UnZip 6.0 and earlier allows remote attackers to execute
> arbitrary code via a crafted zip file in the -t command argument to the
> unzip command.
> CVE-2014-9636: unzip 6.0 allows remote attackers to cause a denial of
> service (out-of-bounds read or write and crash) via an extra field with
> an uncompressed size smaller than the compressed field size in a zip
> archive that advertises STORED method compression.
> CVE-2014-9913: Buffer overflow in the list_files function in list.c in
> Info-Zip UnZip 6.0 allows remote attackers to cause a denial of service
> (crash) via vectors related to the compression method.
> CVE-2016-9844: Buffer overflow in the zi_short function in zipinfo.c in
> Info-Zip UnZip 6.0 allows remote attackers to cause a denial of service
> (crash) via a large compression method value in the central directory
> file header.
> CVE-2018-18384: Info-ZIP UnZip 6.0 has a buffer overflow in list.c, when
> a ZIP archive has a crafted relationship between the compressed-size
> value and the uncompressed-size value, because a buffer size is 10 and
> is supposed to be 12.
> CVE-2018-1000035: A heap-based buffer overflow exists in Info-Zip UnZip
> version <= 6.00 in the processing of password-protected archives that
> allows an attacker to perform a denial of service or to possibly achieve
> code execution.
> CVE-2019-13232: Info-ZIP UnZip 6.0 mishandles the overlapping of files
> inside a ZIP container, leading to denial of service (resource
> consumption), aka a "better zip bomb" issue.
Merge request URL: https://code.foxkit.us/adelie/packages/merge_requests/413
===== system/nvi =====
The last release from repo.or.cz was 1.81.6 on 18 November 2007. The
following CVE appears to have never been addressed (except by individual
distros):
> CVE-2001-1562: Format string vulnerability in nvi allows local users to
> gain privileges via format string specifiers in a filename.
(this one is relatively minor, despite the scary description, since as
far as I know the format string is only used in a status message and not
for the final save location of the file)
Additionally, Debian also patched a few other bugs that our nvi
currently exhibits, such as:
* nvi issues a warning on startup due to an incompatibility with
system/db~4:
BDB0635 DB_CREATE must be specified to create databases.
* nvi segfaults if a trailing tab is pushed to a new line by inserting
characters before it if 'set number' is in effect
Merge request URL: https://code.foxkit.us/adelie/packages/merge_requests/414
10 months, 3 weeks