Especially a newline can produce havoc in the database file as
the filename is written there as-is. This hardenes the extraction
to consider any control character as malicious. Additional
hardening is added to database loading to better detect corrupt
state and return proper error code about it.
Reported-by: Luca Weiss <luca@z3ntu.xyz>
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>
It turns out inflate() can output zero bytes, even if it consumed
data. This had the unfortunate side effect of returning zero bytes
(end-of-file) condition before calling the boundary callbacks. This
fixes the logic to not return zero reads on gzip boundary.
In practice this fixes the seldom seen issues of apk reporting
bad signature (when it was correct).
(De)initialization is deprecated under OpenSSL 1.0 and above.
[TT: Some simplifications, and additional edits.]
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Regression introduced by 0fb0d30 which makes parsing a description
a critical failure.
[TT: Minor stylistic change. Fix also missing final line change
from the earlier commit]
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.
On some systems the `/var/` dir is mounted in a tmpfs which is reseted
after each reboot. For that reason no post-install script can handle the
creation of the cache dir at `/var/cache/apk`.
Check on database opnening if the folder is available, if not create it.
Fixes#10715
Signed-off-by: Paul Spooren <mail@aparcar.org>
It used to be relative to the --root specified root, but that
causes issues with relative command line filenames and is unintuitive.
Update documentation accordingly. Fixes#10702.
This uses some macro trickery to make sure that there's one-to-one
mapping with the option index enum and the descriptor. The down
side is that enum's are generated via #define's and editors might
not pick them up for auto completion, but the benefits are more:
it's no longer possible have mismatching enum value and descriptor
index, and the amount of source code lines is less.
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
Timo Teräs
Ariadne Conill