summaryrefslogtreecommitdiff
path: root/apidoc
Commit message (Collapse)AuthorAgeFilesLines
* Update FSF license notices to use URL instead of addressJoseph Marrero2021-12-071-3/+1
|
* Remove OstreeTlsCertInteraction bits from introspectionColin Walters2021-10-061-1/+1
| | | | | | | | We filter out everything named `-private.h` from scanning, which differs from the gtk-doc exclude. Eventually this will be solved when we switch to the new gir-based docs. Came up in https://github.com/ostreedev/ostree-rs/pull/34#discussion_r723337772
* lib: Add an API to construct a `MutableTree` from a commitColin Walters2021-10-011-0/+1
| | | | | | | This is nicer than having the caller parse the commit object, or indirect via the `OstreeRepoFile*` object of the root. Will be used in ostree-rs-ext around tar parsing.
* repo: Add an API to init `OstreeSePolicy` from commit directlyColin Walters2021-09-301-0/+1
| | | | | | | | | | This is part of `OstreeCommitModifier`, but I'm not using that in some of the ostree-ext Rust code. It just makes more sense as a direct policy API, where it should have been in the first place. There's already support for setting a policy object on a commit modifier, so that's all the old API needs to do now.
* Add an API to verify a commit signature explicitlyColin Walters2021-08-301-0/+1
| | | | | | | | | | | | | We have a bunch of APIs to do GPG verification of a commit, but that doesn't generalize to signapi. Further, they require the caller to check the signature status explicitly which seems like a trap. This much higher level API works with both GPG and signapi. The intention is to use this in things that are doing "external pulls" like the ostree-ext tar import support. There we will get the commitmeta from the tarball and we want to verify it at the same time we import the commit.
* lib/repo: Add ostree_repo_remote_get_gpg_keys()Dan Nicholson2021-07-151-0/+3
| | | | | | | | | | | | | | | | This function enumerates the trusted GPG keys for a remote and returns an array of `GVariant`s describing them. This is useful to see which keys are collected by ostree for a particular remote. The same information can be gathered with `gpg`. However, since ostree allows multiple keyring locations, that's only really useful if you have knowledge of how ostree collects GPG keyrings. The format of the variants is documented in `OSTREE_GPG_KEY_GVARIANT_FORMAT`. This format is primarily a copy of selected fields within `gpgme_key_t` and its subtypes. The fields are placed within vardicts rather than using a more efficient tuple of concrete types. This will allow flexibility if more components of `gpgme_key_t` are desired in the future.
* repo: Make locking APIs publicColin Walters2021-06-051-0/+6
| | | | | | | | Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. https://github.com/ostreedev/ostree/issues/2337 Closes: https://github.com/ostreedev/ostree/issues/2286
* repo: Add ostree_repo_write_regfileColin Walters2021-04-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | This API is push rather than pull, which makes it much more suitable to use cases like parsing a tar file from external code. Now, we have a large mess in this area internally because the original file writing code was pull based, but static deltas hit the same problem of wanting a push API, so I added this special `OstreeRepoBareContent` just for writing regular files from a push API. Eventually...I'd like to deprecate the pull based API, and rework things so that for regular files the push API is the default, and then `write_content_object()` would be split up into archive/bare cases. In this world the `ostree_repo_write_content()` API would then need to hackily bridge pull to push and it'd be less efficient. Anyways for now due to this bifurcation, this API only works on non-archive repositories, but that's fine for now because that's what I want for the `ostree-ext-container` bits.
* repo: Add ostree_repo_write_symlinkColin Walters2021-04-081-0/+1
| | | | | | | Continuation of the addition of `ostree_repo_write_regfile_inline()`. This will be helpful for ostree-rs-ext and importing from tar, it's quite inefficient and awkward for small files to end up creating a whole `GInputStream` and `GFileInfo` and etc. for small files.
* Merge pull request #2327 from cgwalters/writing-apisColin Walters2021-04-081-0/+1
|\ | | | | repo: Add ostree_repo_write_regfile_inline
| * repo: Add ostree_repo_write_regfile_inlineColin Walters2021-04-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When working on ostree-ext and importing from tar, it's quite inefficient and awkward for small files to end up creating a whole `GInputStream` and `GFileInfo` and etc. for small files. Plus the gtk-rs binding API to map from `impl Read` to Gio https://docs.rs/gio/0.9.1/gio/struct.ReadInputStream.html requires that the input stream is `Send` but the Rust `tar` API isn't. This is only 1/3 of the problem; we also need similar APIs to directly create a symlink, and to stream large objects via a push-based API.
* | Merge pull request #2323 from cgwalters/remove-experimentalDan Nicholson2021-04-072-14/+9
|\ \ | | | | | | build-sys: Remove --enable-experimental-api
| * | build-sys: Remove --enable-experimental-apiColin Walters2021-04-072-14/+9
| |/ | | | | | | | | | | | | | | | | It was added for the collections bits, but we made that stable. It's now just cruft and we're very unlikely to reuse the infrastructure again. Motivated by a unit test failure when running from a tarball: https://github.com/ostreedev/ostree/issues/2313
* | Ensure consistent apidoc .gitignoreDan Nicholson2021-04-071-0/+7
| | | | | | | | | | | | | | | | If you don't configure with --enable-gtk-doc, these won't be included in the generated .gitignore. If you later configure with --enable-gtk-doc in the same checkout, they'll show up as untracked files. Include them in GITIGNOREFILES to ensure they're always added regardless of configure options.
* | Remove apidoc .gitignore from version controlDan Nicholson2021-04-071-53/+0
|/ | | | | | Like the top level .gitignore, there's no reason to track this if it's being generated automatically. It only produces spurious diff changes that you almost certainly don't want.
* sysroot: Add _require_booted_deployment() APIColin Walters2021-03-171-0/+1
| | | | | This is a common pattern that is replicated both in our code and in rpm-ostree a lot. Let's add a canonical API.
* Add an API+CLI to inject metadata for bootable OSTree commitsColin Walters2021-03-121-0/+1
| | | | | | | | | | | | | | | | | | | | | I was doing some rpm-ostree work and I wanted to compare two OSTree commits to see if the kernel has changed. I think this should be a lot more natural. Add `ostree commit --bootable` which calls into a new generic library API `ostree_commit_metadata_for_bootable()` that discovers the kernel version and injects it as an `ostree.linux` metadata key. And for extra clarity, add an `ostree.bootable` key. It's interesting because the "core" OSTree layer is all about generic files, but this is adding special APIs around bootable OSTree commits (as opposed to e.g. flatpak as well as things like rpm-ostree's pkgcache refs). Eventually, I'd like to ensure everyone is using this and hard require this metadata key for the `ostree admin deploy` flow - mainly to prevent accidents.
* Add ostree_repo_gpg_sign_data()Alexander Larsson2020-10-231-0/+1
| | | | | This is similar to ostree_sign_data() but for the old gpg code. Flatpak will need this to reproduce a signed summary.
* deltas: Make ostree_repo_static_delta_reindex() publicAlexander Larsson2020-10-231-0/+1
| | | | | | It is useful to be able to trigger this without having to regenerate the summary. For example, if you are not using summaries, or ar generating the summaries yourself.
* deltas: Add ostree_repo_list_static_delta_indexes() functionAlexander Larsson2020-10-231-0/+1
| | | | This lists all the available delta indexes.
* lib/deploy: Add support for overlay initrdsJonathan Lebon2020-09-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | In FCOS and RHCOS, the need to configure software in the initramfs has come up multiple times. Sometimes, using kernel arguments suffices. Other times, it really must be a configuration file. Rebuilding the initramfs on the client-side however is a costly operation. Not only does it add complexity to the update workflow, it also erodes a lot of the value obtained from using the baked "blessed" initramfs from the tree itself. One elegant way to address this is to allow specifying multiple initramfses. This is supported by most bootloaders (notably GRUB) and results in each initrd being overlayed on top of each other. This patch allows libostree clients to leverage this so that they can avoid regenerating the initramfs entirely. libostree itself is agnostic as to what kind and how much data overlay initrds contain. It's up to the clients to enforce such boundaries. To implement this, we add a new ostree_sysroot_stage_overlay_initrd which takes a file descriptor and returns a checksum. Then users can pass these checksums when calling the deploy APIs via the new array option `overlay_initrds`. We copy these files into `/boot` and add them to the BLS as another `initrd` entry.
* lib/deploy: Add deploy/stage APIs with optionsJonathan Lebon2020-09-301-0/+2
| | | | | | | And make the `override_kernel_argv` one of those options. This is mostly a mechanical move here, no functional change otherwise. Prep for adding a new option.
* lib/bootconfig: Add support for multiple initrd keysJonathan Lebon2020-09-301-0/+2
| | | | | | | Prep for actually teaching the rest of the codebase about this. We keep the primary initrd in the `options` hash table for backwards compatibility.
* lib/deltas: Check signed delta in execute_offlineFrédéric Danis2020-09-141-0/+1
| | | | | | | | | | | | | | | | Add a new function `ostree_repo_static_delta_execute_offline_with_signature` which takes a signature engine to verify the delta before applying it. The `ostree_repo_static_delta_execute_offline` is just a wrapper to this new function, passing a NULL signature engine. When this function is called without signature engine, but with a sign delta, it will only fails if `sign-verify-deltas` is set to true in repo core options. This commits move signature existence check and delta signature verification to share common parts between existing APIs and the new function. Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
* lib/deltas: Add signature check API for static-delta superblockFrédéric Danis2020-09-141-0/+1
| | | | | | | This retrieves the signatures and pass the static delta block as an array of bytes to ostree_sign_data_verify(). Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
* signing: Change API to create instances directlyColin Walters2020-05-101-1/+1
| | | | | | | This cleans up the verification code; it was weird how we'd get the list of known names and then try to create an instance from it (and throw an error if that failed, which couldn't happen).
* signapi: expose metadata format and keyDenis Pynkin2020-04-241-0/+2
| | | | | | | | | | | | Explicitly expose functions for querying the metadata format and key name used by OstreeSign object: - ostree_sign_metadata_format - ostree_sign_metadata_key This allows to use the same metadata format and key name by 3-rd party applications using signapi. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* lib/sign: make ed25519 engine non-publicDenis Pynkin2020-03-251-2/+0
| | | | | | Remove unneeded public declaration for ed25519 signing engine. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* lib/sign: make dummy engine non-publicDenis Pynkin2020-03-251-2/+0
| | | | | | Remove unneeded public declaration for dummy signing engine. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* lib/sign: new function for summary file signingDenis Pynkin2020-03-251-0/+1
| | | | | | Add function `ostree_sign_summary()` allowing to sign the summary file. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* apidoc: add API documentation for signing interfaceDenis Pynkin2020-03-251-0/+1
| | | | | | Add the documentation for all public functions. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* lib/sign: add ostree_seign_clear_keys functionDenis Pynkin2020-03-251-0/+1
| | | | | | Add the function for implicit cleanup of all loaded keys. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* lib/sign: public API optimisationDenis Pynkin2020-03-251-2/+1
| | | | | | | | Removed from public `ostree_sign_detached_metadata_append` function. Renamed `metadata_verify` into `data_verify` to fit to real functionality. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* lib/sign-ed25519: cleanup unneeded codeDenis Pynkin2020-03-251-1/+0
| | | | | | Removed unused code. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* sign: API changes for public keys and CLI keys formatDenis Pynkin2020-03-251-0/+1
| | | | | | | | | | | API changes: - added function `ostree_sign_add_pk()` for multiple public keys using. - `ostree_sign_set_pk()` now substitutes all previously added keys. - added function `ostree_sign_load_pk()` allowed to load keys from file. - `ostree_sign_ed25519_load_pk()` able to load the raw keys list from file. - use base64 encoded public and private ed25519 keys for CLI and keys file. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* lib/sign: initial implementationDenis Pynkin2020-03-251-0/+23
| | | | | | | | | | | Added the initial version of signing interface allowing to allowing to sign and verify commits. Implemented initial signing modules: - dummy -- simple module allowing to sign/verify with ASCII string - ed25519 -- module allowing to sign/verify commit with ed25519 (EdDSA) signature scheme provided by libsodium library. Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
* repo/commit: Add support for --selinux-policy-from-baseColin Walters2020-03-241-0/+1
| | | | | | | | | | | | | | | The [dev-overlay](https://github.com/coreos/coreos-assembler/blob/332c6ab3b91778d904224c3c960d9cc4739d60bd/src/cmd-dev-overlay) script shipped in coreos-assembler mostly exists to deal with the nontrivial logic around SELinux policy. Let's make the use case of "commit some binaries overlaying a base tree, using the base's selinux policy" just require a magical `--selinux-policy-from-base` argument to `ostree commit`. A new C API was added to implement this in the case of `--tree=ref`; when the base directory is already checked out, we can just reuse the existing logic that `--selinux-policy` was using. Requires: https://github.com/ostreedev/ostree/pull/2039
* core: Add ostree_commit_get_object_sizes APIDan Nicholson2020-01-201-0/+1
| | | | | | | | | This function parses the object listing in the `ostree.sizes` metadata and returns an array of `OstreeCommitSizesEntry` structures. Unfortunately, for reasons I don't understand, the linker wants to resolve `_ostree_read_varuint64` from `ostree-core.c` even though it's not used by `test-checksum.c` at all.
* core: Add OstreeCommitSizesEntry typeDan Nicholson2020-01-201-0/+6
| | | | | This will be used when reading out entries in the `ostree.sizes` metadata. Each entry corresponds to an object in the metadata array.
* Support mounting /sysroot (and /boot) read-onlyColin Walters2019-12-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to support extending the read-only state to cover `/sysroot` and `/boot`, since conceptually all of the data there should only be written via libostree. Or at least for `/boot` should *mostly* just be written by ostree. This change needs to be opt-in though to avoid breaking anyone. Add a `sysroot/readonly` key to the repository config which instructs `ostree-remount.service` to ensure `/sysroot` is read-only. This requires a bit of a dance because `/sysroot` is actually the same filesystem as `/`; so we make `/etc` a writable bind mount in this case. We also need to handle `/var` in the "OSTree default" case of a bind mount; the systemd generator now looks at the writability state of `/sysroot` and uses that to determine whether it should have the `var.mount` unit happen before or after `ostree-remount.service.` Also add an API to instruct the libostree shared library that the caller has created a new mount namespace. This way we can freely remount read-write. This approach extends upon in a much better way previous work we did to support remounting `/boot` read-write. Closes: https://github.com/ostreedev/ostree/issues/1265
* libostree: Add ostree_async_progress_copy_state()Philip Chimento2019-11-201-0/+1
| | | | | | | | | | | | This allows copying the state from one OstreeAsyncProgress object to another, atomically, without invoking the callback. This is needed in libflatpak, in order to chain OstreeAsyncProgress objects so that you can still receive progress updates when iterating a different GMainContext than the one that the OstreeAsyncProgress object was created under. See https://github.com/flatpak/flatpak/pull/3211 for the application of this API.
* fsck: Implement a partial commit reason bitmaskJason Wessel2019-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the corruption has been fixed with "ostree fsck -a --delete", a second run of the "ostree fsck" command will print X partial commits not verified and exit with a zero. The zero exit code makes it hard to detect if a repair operation needs to be run. When ever fsck creates a partial commit it should add a reason for the partial commit to the state file found in state/<hash>.commitpartial. This will allow a future execution of the fsck to still return an error indicating that the repository is still in the damaged state, awaiting repair. Additional reason codes could be added in the future for why a partial commit exists. Text from: https://github.com/ostreedev/ostree/pull/1880 ==== cgwalters commented: To restate, the core issue is that it's valid to have partial commits for reasons other than fsck pruned bad objects, and libostree doesn't have a way to distinguish. Another option perhaps is to write e.g. fsck-partial into the statefile state/<hash>.commitpartial which would mean "partial, and expected to exist but was pruned by fsck" and fsck would continue to error out until the commit was re-pulled. Right now the partial stamp file is empty, so it'd be fully compatible to write a rationale into it. ==== Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Closes: #1910 Approved by: cgwalters
* lib/kargs: add missing function to symbol-versioning tableRafael Fonseca2019-07-021-0/+1
| | | | | | | Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com> Closes: #1883 Approved by: jlebon
* lib/kargs: Make API public and upstream new rpm-ostree APIsAllen Bai2019-06-182-1/+22
| | | | | | | | | | | | | | | | This change makes public the current kargs API in src/libostree/ostree-kernel-args.c and adds documentations. Upstreams the new kargs API from rpm-ostree/src/libpriv/rpmostree-kargs-process.c Merges libostree_kernel_args_la_SOURCES to libostree_1_la_SOURCES in Makefile-libostree.am Upstreams tests/check/test-kargs.c from rpm-ostree. Closes: #1833 Closes: #1869 Approved by: jlebon
* lib/commit: Added new ostree_repo_write_archive_to_mtree_from_fd()Tristan Van Berkom2019-05-281-0/+1
| | | | | | | | | | | | Similar to ostree_repo_write_archive_to_mtree(), but takes a file descriptor to read the archive from instead of mandating a file path. Usefull for importing archives into an OSTree repo over a socket or from standard input in command line tools. Closes: #1862 Approved by: jlebon
* Release 2019.2v2019.2Jonathan Lebon2019-04-251-0/+1
| | | | | | | | Also add `ostree_repo_get_bootloader` to the public API, which was missed when it was initially merged. Closes: #1844 Approved by: rfairley
* Rename core.repo-finders to core.default-repo-findersMatthew Leeds2018-10-231-1/+1
| | | | | | | | | | | This renames a config key to make its semantics more obvious. Despite what the commit message says, it only applies when a set of repo finders is not specified (either on the command line or in a library API call). This also renames the corresponding ostree_repo_get function. We can do this since it hasn't been released yet. Closes: #1763 Approved by: pwithnall
* Allow disabling pulling from LAN/USB/InternetMatthew Leeds2018-10-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently libostree essentially has two modes when it's pulling refs: the "legacy" code paths pull only from the Internet, and the code paths that are aware of collection IDs try to pull from the Internet, the local network, and mounted filesystems (such as USB drives). The problem is that while we eventually want to migrate everyone to using collection IDs, we don't want to force checking LAN and USB sources if the user just wants to pull from the Internet, since the LAN/USB code paths can have privacy[1], security[2], and performance[3] implications. So this commit implements a new repo config option called "repo-finders" which can be configured to, for example, "config;lan;mount;" to check all three sources or "config;mount;" to disable searching the LAN. The set of values mirror those used for the --finders option of the find-remotes command. This configuration affects pulls in three places: 1. the ostree_repo_find_remotes_async() API, regardless of whether or not the user of the API provided a list of OstreeRepoFinders 2. the ostree_repo_finder_resolve_async() / ostree_repo_finder_resolve_all_async() API 3. the find-remotes command This feature is especially important right now since we soon want to have Flathub publish a metadata key which will have Flatpak clients update the remote config to add a collection ID.[4] This effectively fixes https://github.com/flatpak/flatpak/issues/1863 but I'll patch Flatpak too, so it doesn't pass finders to libostree only to then have them be removed. [1] https://github.com/flatpak/flatpak/issues/1863#issuecomment-404128824 [2] https://github.com/ostreedev/ostree/issues/1527 [3] Based on how long the "ostree find-remotes" command takes to complete, having the LAN finder enabled slows down that step of the pull process by about 40%. See also https://github.com/flatpak/flatpak/issues/1862 [4] https://github.com/flathub/flathub/issues/676 Closes: #1758 Approved by: cgwalters
* lib/repo: Define a metadata key, ostree.deploy-collection-idMatthew Leeds2018-09-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit defines a metadata key that tells clients to update their remote config to add a collection ID. This functionality is currently implemented in Flatpak for the key "xa.collection-id", but there are two good reasons for moving the key to OSTree: 1) Servers such as Flathub shouldn't set xa.collection-id in their metadata now or in the medium term future, because many users are still using old versions of Flatpak and OSTree[1] which would hit various bugs[2][3][4] on the P2P code paths that are enabled by collection IDs. Defining a new key means that only clients running recent (as-yet-unreleased) versions of Flatpak and OSTree will pay attention to it and deploy the collection ID, leaving the users on old versions unaffected. 2) OSTree is as "invested" in collection IDs as Flatpak, so there's no reason the key should be defined in Flatpak rather than here. According to Philip Withnall, the reason the key was put in Flatpak originally was that at the time there was uncertainty about tying OSTree to collection IDs. [1] https://ahayzen.com/direct/flathub.html#downloadsbyflatpakstacked [2] https://github.com/ostreedev/ostree/commit/e4e6d85ea [3] https://github.com/flatpak/flatpak/commit/5813639f [4] https://github.com/flatpak/flatpak/commit/5b21a5b7 Closes: #1726 Approved by: pwithnall
* OstreeMutableTree: add _remove methodRobert McQueen2018-09-201-0/+1
| | | | | | | | | | | | There is no API method to remove a file or subdirectory from a MutableTree besides directly manipulating the GHashTable returned by _get_files or _get_subdirs. This isn't possible from an introspection binding that transforms the returned GHashTable, and may also leave the tree checksum in an invalid state. Introduce a new method so that removing files or subdirectories is safe, and possible from bindings. Closes: #1724 Approved by: jlebon
View Lorry Controller Status