The 'arch' parameter of flatpak_dir_remote_fetch_indexed_summary() is
used to construct the names of the caches, and can't be NULL. This
function is used by flatpak_remote_state_ensure_subsummary(), which is
used by ensure_remote_state_arch(). So, the parameter can't be NULL in
those either.
Of the 27 instances where ostree_repo_remote_get_url() is used, these
are the only ones where the return value is ignored. This triggers
Coverity.
It might not always be strictly necessary to handle the errors, but
doing so can only help with debugging. However, in the case of
flatpak_dir_get_remote_disabled() this clarifies the subtle difference
between an empty URL (ie., ""), and a NULL URL caused by a corrupt
configuration file or a missing "url" key.
We would get a reference to the old permission, then free it, and then
insert the freed pointer into the new hashtable again.
Closes: #6524
Fixes: 6667e1d3 ("context: Use the new permission system for shares and features")
OpenScanHub [1] triggered this and flagged it as CWE-688 [2]:
common/flatpak-appdata.c:298:7: warning[-Wanalyzer-null-argument]: use
of NULL ‘parent’ where non-null expected
common/flatpak-appdata.c:282:6: branch_false: following ‘false’
branch...
common/flatpak-appdata.c:285:3: branch_false: ...to here
common/flatpak-appdata.c:285:3: branch_true: following ‘true’
branch...
common/flatpak-appdata.c:287:15: branch_true: ...to here
common/flatpak-appdata.c:289:6: branch_false: following ‘false’
branch...
common/flatpak-appdata.c:297:7: branch_false: ...to here
common/flatpak-appdata.c:297:6: branch_true: following ‘true’ branch
(when the strings are equal)...
common/flatpak-appdata.c:298:7: branch_true: ...to here
common/flatpak-appdata.c:298:7: danger: argument 1 (‘parent’) NULL
where non-null expected
# 296| /* avoid picking up <id> elements from e.g. <provides> */
# 297| if (g_str_equal (element_name, "id") &&
# 298|-> g_str_equal (parent, "component"))
# 299| {
# 300| component->id = g_steal_pointer (&text);
The parsing code doesn't throw any errors from G_MARKUP_ERROR. It
expects the input to be valid, and relies on assertions to express that.
eg., it asserts that a <component> element or tag is encountered before
any other, and particularly <content_attribute>, <content_rating> and
<release>.
In the same vein, an assertion was added to express that an <id> element
or tag always has a parent.
Spotted by Siteshwar Vashisht.
[1] https://openscanhub.dev/
[2] https://cwe.mitre.org/data/definitions/688.html
Several glibc functions now return a const pointer if the input is a const pointer and a non-const pointer if the input is non-const, causing a build failure.
Fix this by declaring the output pointers as const if they are never modified and for the lone failure where the output is modified instead make the input non-const.
What I did
Repository rules / “don’t edit” areas
From CONTRIBUTING.md and subprojects/README.md, subprojects/ contains vendored/submodule/copylib code (bubblewrap, libglnx, dbus-proxy, variant-schema-compiler). I treated subprojects/ as third-party and excluded it from typo fixing.
You already skip po/ (translations) and node_modules/, and I kept those exclusions.
Typos fixed (project-owned files only)
I ran codespell with write mode and exclusions, and fixed the reported typos across:
NEWS
app/…
common/…
doc/…
tests/…
session-helper/…
portal/…
data/…
Then I handled the remaining items individually:
NEWS: thse -> these
common/flatpak-utils-private.h: Thse -> These
app/flatpak-polkit-agent-text-listener.c: identies -> identities
tests/test-auth.sh: Propertly -> Properly
tests/testlibrary.c: remore -> remote
common/flatpak-transaction.c: improved wording to avoid the xwindows typo (X11 window ID)
Added .codespellrc
Created .codespellrc:
skip: node_modules,po,subprojects
ignore-regex: .*(ratatui|Affinitized|affinitized).*
ignore-words-list: nd,ot,THUR,IST,fo,hel,bu
(these were confirmed as legitimate tokens/abbreviations/namespace prefix/test strings in this repo, so they should not be “fixed”)
Verification:
codespell --config .codespellrc . now exits clean.
Signed-off-by: rezky_nightky <with.rezky@gmail.com>
While the arguments for --filesystem permissions either have to come
from a privileged source, or from the manifest which is supposed to be
checked by the remote, it was decided that paths are not allowed to move
up (..) a directory.
The check for this was both too complicated, and not sufficient, because
the special directories (e.g. xdg-download) might contain only a single
slash (xdg-download/..) and move one directory up.
This gives us conditionals for shares and features. So far we have no
use case for this, but the system already exists, it makes the code
simpler, and when we need this in the future, we don't have to wait for
it to roll out.
For device and socket the negated versions are nodevice and nosocket,
but for shares, the strings are allow and disallow. Take arguments for
both forms.
Allow specifying a lookside URL for downloading signatures for
an OCI remote. This can be specified:
In a .repofile with the SignatureLookaside key
As the --signature-lookaside option to remote-add/remote-modify
FlatpakOciSignature was a Flatpak-specific analog to
the containers/image "simple signatures" - but it wasn't used at
all, and Flatpaks on registry.redhat.io are signed by the
original simple signatures. So modify it correspond to
the original simple signatures.
There is some code for OCI signature verification that isn't currently
hooked up at all. In preparation for reworking it to usefully check
signatures that actually exist in OCI registries, move it to a
separate file.
We declare the autoptrs explicitly on those typedefs so it works on
older systems but this one accidentally uses the type provided by polkit
itself.
Fixes: 1372e16d ("dir: Check parental control authorization via system bus name")
When an xdg dir is not available, it is supposed to point at $HOME. We
do not want to mount $HOME though in that case, so we just skip the xdg
dir instead.
The check compares the strings of the the xdg dir path and the home dir
path. So far it relied on the functions internally canonicalizing the
paths in the same way, but there was a glib regression:
https://gitlab.gnome.org/GNOME/glib/-/issues/3811
("g_get_user_special_dir doesn't strip trailing slash from $HOME")
Which then was fixed in cb3e9fe74 ("gutils: Strip all trailing
slashes").
We can however just canonicalize on the paths on the caller side to make
this more robust, so let's just do that.
Closes: #6323
Extra-data usually is downloaded on the user side into an ostree repo.
For system installs, a temporary ostree repo is used on the user side
and then imported on the system side. This doesn't work for OCI images
because importing the image into an ostree repo makes it impossible for
the system side to verify the data.
So instead, the OCI image is first mirrored into a local OCI repo and
then gets imported on the system side, which can verify the image from
the index by the digest.
Closes: https://github.com/flatpak/flatpak/issues/3790
It took in a ostree commit before, but it really only needs the detached
metadata. The single caller now converts it correctly.
This will become useful when we want to know the size of the extra data
when the metadata is coming from an OCI image.
This cleans up flatpak_dir_pull_extra_data in a way that it is only
responsible for downloading the extra-data. In has no dependencies on
ostree concepts any more.
The new flatpak_dir_pull_ostree_extra_data now takes care of extracing
the extra data sources and saving it in the detached metadata.
CURLcode return values from curl_easy_setopt() were being compared
with CURLM_OK (a CURLMcode constant) instead of CURLE_OK. This is
incorrect as CURLM_OK is for multi interface functions, not easy
interface functions.
A few years ago there was a very painful attempt at porting from
libsoup2 to libsoup3. Flatpak libsoup3 support never landed and it seems
like a large amount of distros have switched over to libcurl instead.
This commit removes libsoup2 support completely instead of growing
libsoup3 support.
Closes#5915Closes#4582
Add an option to build OCI bundles with zstd compressed layers.
gzip is kept as the default for maximum compatibility:
Ecosystem support:
distribution/distribution: no explicit support, but works
quay.io: sinc 2021
Amazon ECR: supported
pulp_container: since 2022
flatpak: since first-OCI supporting version
tardiff: since first version
This comment needs to be modernized for 2025. It notably fails to
mention the two projects that are actually still using code that looks
like Flatpak's.
If an SDK is already installed in a dir that is not targeted with a
flatpak transaction, and the transaction has auto_install_sdk set,
add_new_dep_op returns NULL in dep_op which is not correctly handled in
add_deps.
Fixes#5894
We could previously just assume that the first enabled remote
(potentially matching the collection ID) contains the ref, but that
obviously is not always the case.
The change here looks up the remote state of the remotes to figure out
if they actually contain the ref, and adds the first matching remote to
the transaction.
Sudo can be used in several ways other than calling a command with the
root user. For example, one can use -u to run the command as the
specified user, or -g to specify a primary group to run the command
as.
Flatpak adds a check when --user is used to prevent an installation in
the root's directory, for example, but it does it by only checking if
sudo was used. As stated previously, it does not necessarily imply
root, so this patch explicitly checks if the command is being run with
the root user.
Fixes: https://github.com/flatpak/flatpak/issues/5979
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
The appstream docs say:
Release data may be present directly in a component metainfo file, but
also optionally be split out into an external metadata file.
The file must be installed as
/usr/share/metainfo/releases/%{cid}.releases.xml, where cid is the
component ID of the component the release information belongs to.
This change allows flatpak build-finish to export those external release
files.
Closes#6057
PIDs are pretty much always a bad idea because they can be racy. The
authorization did use the PID though. We can replace it by a check via
the system bus name.
Closes: https://github.com/flatpak/flatpak/issues/6212
