the stat64 family of functions were provided as transitional functions,
but when building on glibc with _GNU_SOURCE, or any other supported system,
the stat functions are equivalent to their stat64 counterparts
musl implements support for malloc.h, but it is only a stub. we do not use
any of the GNU-specific malloc interfaces, so just use POSIX stdlib.h instead.
ref #10794
In most places where pointer can be an 'error' it cannot be null
pointer. Further, in those cases just calling PTR_ERR() is not enough
to handle the null case. Simplify code by removing this case.
If NULL case needs to be handled, it's better to add separate check
and return fixed error code in that case.
- apk_istream_splice usage is converted to apk_stream_copy which
is the newer variant. With caching enabled by default, this
makes more sense mmapping or using separate buffers.
- apk_istream_tee is reworked to write to apk_ostream, which simplifies
quite a bit of various things
- basic digesting and signing apis (subject still to fine tuning)
- update digest code, and adb signing for the thin wrapping layer
- old v1 package and database handling not updated
- default mkpkg file hash to sha256
ref #10744
Modify apk_resolve_[ug]id to take the user/groupname as a blob, so
proper length checking is done and honored.
==31584== Conditional jump or move depends on uninitialised value(s)
==31584== at 0x5C8CA5: strlen (strlen.c:17)
==31584== by 0x432575: APK_BLOB_STR (apk_blob.h:79)
==31584== by 0x4350EB: apk_resolve_uid (io.c:1112)
==31584== by 0x43696C: apk_tar_parse (io_archive.c:152)
==31584== by 0x4271BC: apk_pkg_read (package.c:929)
==31584== by 0x402D75: add_main (app_add.c:163)
==31584== by 0x40D5FF: main (apk-static.c:516)
Fixes a potential crash (DoS) on a crafted TAR file. CVE-2021-30139.
Reported-by: Sören Tempel <soeren+git@soeren-tempel.net>
Reviewed-by: Ariadne Conill <ariadne@dereferenced.org>
apk_dir_foreach_file and apk_resolve_[ug]id needs to free the fd in
case fdopen/fdopendir fails. Additionally this does not rely on fdopen
to fail if openat() returned -1, making sure that we don't call any
syscalls with invalid file handle.
While commit 18b0b45 (io: Handle long lines, Thu Jan 7 17:25:23 2021
+0100) did attempt to address this issue, the buffer really is still to
small when dealing with big-big dependency lists.
Lets make it sufficiently large for now, until the new APKINDEX format
can support multi-line dependencies, making this not needed any more.
[TT: Originally the buffer size was conservative to run on resource
constrained embedded platforms. But since the available memory on those
has also increased much, the adjustment to 128kB makes sense also to
increase performance a little bit. Removing also the iolimit test.]
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
As an APKINDEX can become arbitrarely long due to dependencies and
other parameters, increasing the buffer size make this less likely
to happens.
Closes#10731.
The new v3 applets don't use it, and eventually all applets will
use the new formats only.
This prepares the code for this, and moves trust, id_cache, and
root_fd to apk_ctx which is enough for v3 applets at this time.
The generic code is made to not initialize apk_database if it's
not needed.
This is a flat buffers inspired format that allows fast
mmaped access to the data with low overhead, signature support
and relatively good forward support.
This greatly helps with memory management on applications that
may want to daemonize and open/close database several times.
Also the lifetime and "owner" of memory for all data is now
explicitly bound to owning struct apk_database, which might
be helpful when writing language bindings. As side effect, the
interned "atoms" are unique only within what apk_database, so
comparing packages from different apk_database may not work
as expected.
Fixes#10697
Convert all implementations to do buffering. This is in preparation
to remove bstream interface as redundant.
istream_read() will return full reads unless end-of-file. The backends
can return short reads to optimize buffering or due to other reasons
like boundary change for gz.
This modifies apk cache for indexes to be automatically refreshed
periodically without explicit 'update' or '--update-cache' usage.
The default is to do if-modified-since request if the local copy
is older than 4 hours. This age can be changed with --cache-max-age.
Using --update-cache will change this age to 60 seconds to make
sure the cached copy is relatively new. The small age is in order
to try to avoid downloading indexes second time when apk-tools is
upgraded and apk re-execs after self-upgrade.
Accordingly using explicitly 'apk update' will now enforce
--force-refresh and request the very latest index by requesting
any potential http proxy to do refresh too.
Timo Teräs
Ariadne Conill