IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- Also rolls up a few other changes in the C API
- Drop `&mut` from `OstreeKernelArgs`; it now confuses type inference.
More generally while using `&mut` here was well intentioned, it
goes against the glib standard of mapping everything to `&` and
accepting interior mutability.
Since it bumped semver (when I didn't expect it to; xref
963eebf3ab (r121651362)
It's not load-bearing enough here to matter versus just passing
an untyped file descriptor.
This mainly means that it will be the `glib` ecosystem which
forces transitive semver bumps for us, not both.
It complains that we could leak memory if the return value
pointer isn't set. That's actually a nonsensical case, there's
no reason to call this and ignore the return value.
So change things to require it be set, and also change the
`g_return_val_if_fail` to be hard assertions per our new policy.
We did this in some prior patches because it's better for
static analyzers; code is either reachable or not, and we don't
want the default desktop-style behavior of "try to stumble on
without crashing". It's just likely to lead to a crash somewhere
else.
The warning here was about a use-after-free which is serious, but
I don't think it was reachable in practice, because we'd only
enter the second conditional if `contents_checksum != self->contents_checksum`,
yet we made them the same thing here.
Nevertheless, refactor the code to do a direct return in this
case because that's basically what happened before, and doing
so is a lot clearer.
Since we enabled composefs at build time, the default (non-composefs)
case now always prints
`composefs: Optional support failed: No such file or directory`
But that's normal and expected.
Rework things here so that in the very special case where
we are in "maybe/optional" mode and we get ENOENT, then we
output a much more normal-looking message that doesn't include
the string "failed".
Now on the flip side - if I have explicitly enabled signature
checking, I think we *do* want to make that fatal even if
composefs is in "maybe" mode.
(This part is more debatable; perhaps we should just disallow
the case of "maybe" + signatures at all; but I think this is
an improvement in that direction)
Now that we don't support digest-but-not-signature verification
for composefs, the logic here was unnecessarily complicated.
With a prior prep patch that moved the composefs option
initialization up, we can just have everything related to signature
verification in a single conditonal.
We print if we're doing a signature+digest verification; its absence is
sufficient in the other case. The goal here is to avoid polluting
the logs when signatures are not enabled.
