Make a new body.h file with some functions to deal with pod and their
body. Make the iter.h functions use mostly this.
Rework the parser so that it only uses body.h functions. With the separation
of pod+body, we can read and verify the pod once and then use the
verified copy to handle the rest of the body safely.
We do this because iter.h only works in pods in memory that doesn't change
because it is vulnerable to modifications of the data after verifying it.
The new parser is not vulnerable to this and will not cause invalid
memory access when used on shared memory. There is however no need for
atomic operations to read the headers, whever is read is either valid
and useable of invalid and rejected.
See #4822
This gets the next key and value from an object. This function is better
because it will skip key/value pairs that don't fit in the array to hold
the key.
The previous code patter would stop parsing the object as soon as a key
larger than the available space was found.
Add spa_json_begin_array/object to replace
spa_json_init+spa_json_begin_array/object
This function is better because it does not waste a useless spa_json
structure as an iterator. The relaxed versions also error out when the
container is mismatched because parsing a mismatched container is not
going to give any results anyway.
Since `spa/utils/cleanup.h` is not a private header anymore, there is
no need for a separate `pipewire/cleanup.h` since the definitions of
the cleanup routines can now be moved into the respective headers.
Add a new extension that can create a server on a user provided socket
with user provided security properties.
This is mainly used in flatpaks that want to create and bind a pipewire
socket with specific permissions for the flatpak app.
The flatpak will also provide an fd that will be closed when the server
can be removed.
Add props to the protocol_data and server. Instead of storing the
server_info, just add the relevant properties for the server to the
props.
When we get a new client, we can simply copy the server props to the
client props. This makes it possible to create specific servers later
that create clients with specific properties.
Use a subset of the context properties to create servers. We only need
the CORE_NAME for now.
Add a function to check if a specfic custom log level has been defined
for a topic.
We can use this to dynamically check if we need to do the connection debug
messages.
We can also get rid of the conn.* pattern hack to disable connection
messages by default.
Emit error if message construction is not holding appropriate locks or
runs from wrong thread, so that the flush may be running concurrently.
This generally causes corrputed messages to be sent silently, and can be
fairly hard to debug otherwise in client applications.
If no socket configuration specified for a server, create two sockets,
"CORENAME" and "CORENAME-manager" where CORENAME is the value computed
by get_server_name.
Add client key PW_KEY_SEC_SOCKET that indicates which socket the client used
to connect to the server.
This can be used by other modules as an access control mechanism.
For all the modules that include the private header we require that the
library and compiler versions match.
Otherwise we might end up poking into new or old fields that got moved or
changed in the private struct and crash.
See #3243
When we consumed all the buffer data, don't clear all the fds but only
those that were already consumed in the message. It is possible that we
already have fds for the next message and we don't want to discard
those.
Fixes some intermittend memory map errors.
Always first use the env var and then check the properties. So that
PIPEWIRE_CORE=pipewire-1 PIPEWIRE_REMOTE=pipewire-1 make run runs
everything on pipewire-1 sockets regardless of the config files.
Also PIPEWIRE_NODE always needs to be taken into account first.
Support fork-free readiness notifications.
Without this, a service supervisor that does not implement socket
activation has no way of knowing whether or not pipewire is ready to
accept connections on the socket.
s6 is the most popular service manager that supports this mechanism.
See here: https://skarnet.org/software/s6/notifywhenup.html
Init the compat types map a little earlier so that it is initialized
when we try to clear it on error.
Add the client listener earlier so that we can use the events to clean
up the map, source and connection.
When the client destroys the protocol-native module, the server
and the client are destroyed but the client is still reffed (not freed).
It will be unreffed after its messages are processed, after which point
it will be freed and removed from the server client_list that is already
destroyed.
Fix this by removing the client from the server list when it is
destroyed.
See #565
Add a refcount to resource and client so that we can keep them alive
while the native protocol is using them.
One problem might be that the protocol destroys the client or resource
while handling it and that would cause errors.
Fixes#565
Message footer should be handled before attempting to find the object
the main message is sent to / checking permissions, because it is not
aimed at a specific object. E.g. the registry generation updates should
be handled regardless of whether the main message is valid or not,
because the updates will not be re-sent.
Fixes registry generation updates sometimes going missing.
There's an assumption that marshaled messages consist of a single POD,
since we now tag on a footer after it. This is true for the
protocol-native implementations, which all wrap the message in a single
POD Struct.
To catch protocol-native implementation bugs here later, add assert that
marshaling produces a single POD.
Extend version 3 protocol with message footers, which are for passing
around global state data that is not addressed to a specific object.
The extension is backward compatible with previous v3 clients, and won't
e.g. result to error spam in logs.
The footer is a single SPA POD, appended after the main message POD.
Because both the protocol message and the message POD record their
length, it's possible to append trailing data. Earlier clients will
ignore any data trailing the message POD.
The footer POD contains a sequence [Id opcode, Struct {...}]*,
so there is room to extend with new opcodes later as necessary.
There are separate marshal/demarshal routines for messages aimed at
resources and proxies.
