At the same time, 8b6c039a1a is reverted, i.e.
session state is removed from the output. It was added to workaround #26744,
and doesn't really make too much sense after the issue is properly fixed.
no-pager-255 was added in #29184, which I reviewed and agreed.
However, as #30887 came up, I reconsidered it a bit, and now
I actually think that this should be removed.
We add new tools that refer to these standard options. During
the process, some options are also promoted to be standard ones.
I think a more sane practice is to generally keep old tools in
the loop, rather than overloading the standard-options with versions.
- fix memleak in parser,
- fix missing return in parser on failure,
- drop unnecessary temporary argument in command line argument parser,
- use recently introduced macros and helper functions.
- introduce link_required_operstate_for_online() helper function,
- use recently introduced macros and helper functions,
- unconditionally serialize the minimum and maximum of required
operational state.
Now that we can selectively suppress only sensitive fields in JSON
objects we can reenable debug logging for incoming messages, which was
removed in 2e3414660c.
This makes Varlink fully debuggable again: we'll see both incoming and
outgoing messages, only the sensitive fields are suppressed.
See: #30578
Previously, the flag would completely refuse formatting a JSON object if
any field of it was marked sensitive. With this change we'll simply
replace the subobject with the string "<sensitive data>", and show
everything else.
This is tremendously useful when debugging, since it means that we can
again trace varlink calls through the stack: we can show all the message
metadata and just suppress the actually sensitive parameters.
The ability to debug this matters, and we should not hide more
information that we can get away with, to keep things debuggable and
maintainable.
Let's export this function, so that we can use it elsewhere. Also, while
at it, let's cache the result in a flag. This is only safe if the result
is positive, since we allow the flag to be enabled at any time down thre
tree somewhere, which we need to look at. (We never allow it to be
turned off however)
So far the varlink logic honoured the "sensitive" flag of output
messages. Let's add something similar for input messages. Since we don't
really know incoming messages, the flag simply controls whether the
"parmaeters" field of all incoming messages should be marked as
sensitive.
Then, turn this on in the credentials logic and in homed, since both
deal with credentials.
The kernel uses different logics to find or distinguish IPv4 and IPv6 routes.
Let's follow the same way that the kernel uses.
See comments in the code for more details.
To prevent the request freed in req->process().
This also makes a request that is not requested by a link detached on failure.
Otherwise, the request may periodically processed and failed forever.
Let's rename return parameters to ret_xyz, and let's guarantee the usual
rule to initialize all return parameters on success, and not touch any
on failure.
Lennart Poettering
Mike Yuan
Luca Boccassi
Yu Watanabe
hfavisado
Frantisek Sumsal
A S Alam