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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
The ordering of the includes apparently matters...and I didn't
actually check that the previous change enables composefs on c9s.
But I did now. For reals.
While we have the patient open, I switched to `AC_LANG_PROGRAM`
because I originally thought the bug had something to do with that.
As far as I understand, more cleanly separating the includes
from the injected body text is a useful thing in `AC_LANG_PROGRAM`.
I've verified that this fixes compatibility with GRUB, which
parses the filename:
https://github.com/ostreedev/ostree/issues/2961
However, out of a large degree of conservatism I've made this
an opt-in behavior for now.
My plan is to test it out in the FCOS development streams first.
Add long overdue unit testing coverage for this, which
at least slightly closes out the android boot CI gap.
Actually, this *copies* the karg parsing code into otcore because
it now uses glib, which we're not yet using in the static
prepare-root. It's pretty tempting to drop support for the
static prepare root entirely. But for now we'll live with some
code duplication.
