This patch introduces modification to AirPlay attributes allowing AirPlay clients seeing only appropriate Endpoints of specific version of AirPlay protocol.
[Test]
Run two instances of shairport-sync - built for version 1 and for version 2.
TuneBlade recognizes only AirPlay version 1 instance running.
MacOS/iOS recognizes only AirPlay version 2 instance running.
Without that patch, both MacOS/iOS detect two endpoints at the same time. The TuneBlade detects only AirPlay version 1 since it doesn't support AirPlay version 2.
This patch introduces modification to AirPlay attributes allowing AirPlay clients
seeing only appropriate Endpoints of specific version of AirPlay protocol.
[Test]
Run two instances of shairport-sync - built for version 1 and for version 2.
TuneBlade recognizes only AirPlay version 1 instance running.
MacOS/iOS recognizes only AirPlay version 2 instance running.
Without that patch, both MacOS/iOS detect two endpoints at the same time.
The TuneBlade detects only AirPlay version 1 since it doesn't support AirPlay version 2.
The introduction paragraph now more clearly mentions the hard facts/requirements with "as of v4.1 and newer" and the supported devices are displayed in bullet list format for better readabilty.
Configuration files may contain it, but those can be protected with
filesystem permissions.
Debug log, however, may end up in syslog(3) which is usually accessible
by all users on a system.
Avoid disclosing user secrets by simply not printing the password.
OpenBSD issues syslog(3) warnings about these as they may hint at bugs:
shairport-sync: vfprintf %s NULL in "metadata socket address is "%s" port %d."
Metadata listener socket is empty by default so use the existing `strnull`.
Limit the set of system calls shairport-sync is allowed to make,
most importantly fork(2)/execve(2) if and only if user defined commands
are run.
OpenBSD's official audio/shairport-sync port already ships with this
patch.
https://man.openbsd.org/pledge.2
On OpenBSD 7.4-current, failure to listen on the RTSP socket(s) results
the `rtsp_listener_thread` being pthread_cancel(3)'ed twice, once through
`rtsp_listen_loop()` and again via atexit(3) handler `exit_rtsp_listener()`:
```
$ nc -4l 5000 &
$ nc -6l 5000 &
$ shairport-sync -c/dev/null
warning: could not establish a service on port 5000 -- program terminating. Is another instance of Shairport Sync running on this device?
Segmentation fault (core dumped)
```
```
Program terminated with signal SIGSEGV, Segmentation fault.
433 if (tib->tib_canceled == 0 && tid != 0 &&
[Current thread is 1 (process 290061)]
```
`die()` -> `exit(EXIT_FAILURE)` normally in this case, thus forgoing the
first cancel and relying on the atexit handler alone.
With Mike Brady.
Failure to read does not exit despite
` /* Read the file. If there is an error, report it and exit. */`
EACCES (e.g. insufficient filesystem permissions) is enough to crash
on access through later `config_*()` such as those when either of
either of D-Bus, MPRIS or MQTT is used.
Seen `--with-mpris-interface` and
```
$ ls -l /etc/shairport-sync.conf
-rw-r----- 1 root _shairport 28114 Jan 25 01:53 /etc/shairport-sync.conf
$ shairport-sync
Segmentation fault (core dumped)
```
NQPTP works and runs as _shairport user on OpenBSD.
Linux capabilities(7) allow starting as unprivileged user in the first
place, otherwise programs only need to start and perform privileged
actions such as bind(2)ing sockets as root, after that they can and
should! drop privileges.
Instead of updating/repeating supported systems, drop listings.
Mike Brady
Craig Lockwood
Oleh Kuzhylnyi
porgandGitHub
Hugo Villeneuve
Ryan Mounce
HNKNTA
Klemens Nanni