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
This mostly boils down to making sure control_started and
data_started are consistently used to gate actions, instead of
relying whether on file names start with a '.'.
None of the weaknesses this fixes are exploitable, but they
might have become so after changes to seemingly-unrelated code,
so it's good to clean them up.
A crafted .apk file could to trick apk writing unverified data to
an unexpected file during temporary file creation due to bugs in handling
long link target name and the way a regular file is extracted.
Several hardening steps are implemented to avoid this:
- the temporary file is now always first unlinked (apk thus reserved
all filenames .apk.* to be it's working files)
- the temporary file is after that created with O_EXCL to avoid races
- the temporary file is no longer directly the archive entry name
and thus directly controlled by potentially untrusted data
- long file names and link target names are now rejected
- hard link targets are now more rigorously checked
- various additional checks added for the extraction process to
error out early in case of malformed (or old legacy) file
Reported-by: Max Justicz <max@justi.cz>
It's common for a pre-install script to do something like
addgroup -S group 2>/dev/null
When apk installs files after this, it sets the owner/group based on id cache
but currently the id cache is stale and doesn't contain the new group at that
point: instead the file will be installed with gid that the build host
happened to have for that group -- on target this might mean a non-existing
group or a completely different group.
We can't know if the script really did modify id cache contents so make sure
to reset the id cache on every script execution.
By introducing a new package metadata field, `provider_priority`
(index letter `k`), we can specify default packages to satisfy a
virtual.
If a user wishes to select an alternative provider for the virtual,
a changeset swapping the default provider for the selected provider
will be generated by the dependency resolver.
This is useful for requirements such as: python3=~3.6, which would match python3-3.6.[0-9].
This implementation should in theory be backwards compatible with the implementation in Adelie.
This allows for instance integration of etckeeper
[TT: Reorganized code a bit, and modified to use single
directory commit_hooks.d with argument for script of stage.]
It is unreasonable to assume that all package writers would except
to reset umask themselves. It's done currently in most packages,
but we had first issue of this kind recently, so better just reset
umask.
- self-conflicts when the exact same version of a name is provided
twice is now properly detected and diagnozed
- don't print redundant satisfies diagnostic
So same package it is possible to not match same package multiple
times. Use generation count, so this is handled cleanly during
recursion, like in the use case of search applet.
Instead of the dependency oriented logic, switch to print them
for each package or name needed. Might give a bit more readable
errors now. There's still few corner cases that proper error is
not output, which are cought by the test cases.
fixes#1476
Instead of:
ERROR: Index generation failed: Success
The following is now printed:
ERROR: Metadata for package timo-1.0-r0 is too long.
ERROR: Index generation failed: No buffer space available
Solver will now never report partial solution where a conflict
constraint is not satisfied. The is because with --force we might
install the partial solution; and if conflicted packages were to
be installed we might have extra trouble.
* solver internally calculates now using tags; not repository masks
* installeddb now contains the tag name where the package came from
-> we can now handle upgrades properly
* the pinning is still a preference, and not strictly enforced;
versioned dependencies may overrule preference
Timo Teräs