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.
