Address the following CVEs reported by Trivy on the LiveKit agent
image against `libssl3t64` 3.5.7-1~deb13u2:
* CVE-2026-63073 — CRITICAL (CVSS 9.8)
* CVE-2026-63072
Bump `libssl3t64` to the patched version to pick up both fixes.
Address the following MEDIUM severity CVEs reported against
`djangorestframework` 3.17.1:
* CVE-2026-73228 (CVSS 5.3)
* CVE-2026-73229 (CVSS 4.3)
Bump `djangorestframework` to the patched version to pick up the
fixes.
Bump `libexpat` from 2.8.4-r0 to 2.8.5-r0 to address the following
HIGH severity CVE, reported by Trivy on the frontend image
(alpine 3.24.1):
* CVE-2026-93990 — expat: XML injection via malformed UTF-16
input.
https://avd.aquasec.com/nvd/cve-2026-93990
Most call sites of `update_metadata` already wrap the call in a
try/except that logs the failure at info level.
Remove the warning log inside `update_metadata` itself to avoid
redundant logs, without losing any information.
`EGRESS_ABORTED` and `EGRESS_FAILED` events were previously ignored, leaving
recordings indefinitely in `ACTIVE` state and potentially blocking subsequent
recordings with 409 errors. Add handling and logging for failed and aborted
egresses, discarding failed recordings while preserving the existing behavior
for savable recordings.
Rename `handle_complete` to `handle_savable` to reflect that it handles both
`EGRESS_COMPLETE` and `EGRESS_LIMIT_REACHED`.
Slight refactor to separate LiveKit event handling from recording concerns as
part of a general separation concern to allow for future SFU swapping.
NB:
- FAILED recordings are currently discarded although exploitable media files
may exist
- There is a theoretical hole: if stop observes EGRESS_FAILED before the
egress_ended webhook is processed, the recording is immediately marked as
FAILED. Since only ACTIVE and STOPPED recordings are savable, the webhook
then skips the failure notification and LiveKit error log. In that rare race
condition, participants may therefore not see the failure toast. We accept
this trade-off for now, as this should be very infrequent.
- Another theoretical hole: There is a short race window where the user
clicks stop while the limit-reached status is being processed. Since the user
explicitly requested the stop, we consider skipping the limit notification
acceptable and do not handle this case.
fix(recording): log aborted worker events at info level
When a user starts a recording or a transcription while no track is
published yet, the recording stays in a "starting" state until an
appropriate track is available.
Show an explicit message on start explaining that the recording
will remain in "starting" state until a track of the required type
is published. The expected track type depends on the recording
type (audio-only vs. audio + video).
This situation was generating a lot of support requests, with users
asking why the recording did not actually start.
`VideoResolutionSubscription` applied the saved reception resolution on
`RoomEvent.TrackPublished`. livekit-client does not raise that event for cameras
that were already sending when the local participant joined, so a user who had
chosen Low definition still received High definition from everyone already in
the meeting, and Low definition only from whoever joined after them. Nothing in
the UI showed the discrepancy: the setting kept displaying Low definition.
Apply the preference to the publications we already know about when the effect
runs, and keep listening on `TrackPublished` — which stays the earliest point to
cap a camera that starts after us — plus `TrackSubscribed`, which is the first
event raised for the cameras that were already sending.
That initial pass also covers a change of preference mid-call, which
`VideoTab.updateExistingRemoteVideoQuality` was doing separately. Removed, it is
now the same code path for joining and for changing the setting.
The three entry points overlap on purpose; the `publication.videoQuality` guard
makes the repeats free. It reads as High definition when nothing was ever
requested, so the default case costs no signal round trip either.
Fixes#1606.
`DockerflowMiddleware` serves the endpoints `/__heartbeat__`, `/__lbheartbeat__
that we use for the kubernetes probes. Sitting at the bottom of
MIDDLEWARE, every Kubernetes probe traversed all middlewares which is not
efficient.
The backend and summary probes had the two Dockerflow endpoints the wrong way
round. `/__lbheartbeat__` returns an unconditional 200 as soon as the server is
up and touches no dependency, while `/__heartbeat__` runs the Dockerflow checks
and answers 500 when one of them errors.
Wired as they were, a database error made `/__heartbeat__` fail on every
backend pod at once, restarting them all. Since a restart cannot fix a
database outage, it's better to use these check on the readiness probe
and start routing traffic when the database is reachable.
- Probe liveness on `/__lbheartbeat__` and readiness on `/__heartbeat__`
- Add a startup probe on `/__lbheartbeat__`, polled every 5s with a
`failureThreshold` of 12, leaving the pod a minute to boot
- Drop `initialDelaySeconds` from liveness and readiness, now that the startup
probe holds them off until the server answers
- Set `timeoutSeconds` to 5s on every probe, up from the 1s Kubernetes default
- Set the readiness `failureThreshold` to 3
The `meet.probes.abstract` helper was missing `periodSeconds` block which means
Kubernetes fell back to its 10s default instead of the chart value.
It's now possible to configure the `failureThreshold` and `successThreshold`.
Builds through the Docker API of the Podman service receive none of the
proxy variables in their RUN steps and fail systematically because of
the proxy rejection. Plain HTTP connections are also rejected by the
proxy with a HTTP 405 method error.
- Passes http_proxy, https_proxy and no_proxy from the shell as build args
- Make the Debian mirror of the agents image a build argument and
override it for bureautix to force https usage
Add the minimal requirements to build and run the project locally on NixOS
- `devenv update` update devenv using NixOS 26.05 stable repositories
- `devenv shell` activates the devenv
- `devenv --profile <profile>` shell uses additional packages when
activated (profile=agent|summary|k8s)
Pin the LiveKit rtc section: the browser reaches the server through
podman's published ports on loopback while egress and the agents reach
it over the podman network, and those two have no address in common.
`advertise_internal_ip` keeps the container's own interface address as a
host candidate alongside the node_ip one, so LiveKit offers both and ICE
picks whichever works. Without it egress only ever sees 127.0.0.1, which
is the egress container itself, and its peer connection timeouts
`use_external_ip` is turned off since it would advertise the STUN-discovered
public IP, which no local peer can hairpin to.
Rootless podman maps container UID 0 to the host user and every other
container UID to a subuid that owns nothing in the worktree, so the usual
DOCKER_USER=$(id -u):$(id -g) makes every bind mount effectively
read-only.
Add a compose.podman.yml to override the compose.yml and set
`userns_mode: keep-id` in order to map the host user to the same UID and UID
inside the container. The merge of the docker compose file is now done with
the COMPOSE_FILE environment variable
The waiting room has its own sound in notifications.mp3, and nothing could play
it: the sprite is named "waiting" while triggerNotificationSound passes a
NotificationType, and howler returns without playing when the sprite id is
unknown. ParticipantWaiting was also absent from the sound settings, so the
check on the store would have refused it first. The toast borrowed the
participant joined sound instead.
The sound was tied to the waiting list going from empty to non empty, so a
second person arriving while someone was still waiting was silent, which is the
case the issue describes.
Name the sprite after the notification type, register the type in the settings,
and sound every arrival, detected on the participant ids so that an admission
and an arrival between two refreshes do not cancel each other out.
closes#1705
get_release() read the version from a version.json file but nothing generates
it during the CI Docker image build, therefore the release reported to Sentry
was always "NA".
Read the version from pyproject.toml instead, which is bumped at each
release and copied into the image.
Incorrect file permissions in the frontend Docker image caused
problems when running the project, and were surfaced by @briquet
while setting it up with Podman.
Adjust the ownership and permissions applied during the build so
the image works cleanly under Docker and Podman alike.
Docker Hub now denies anonymous pulls of minio/minio (pull access
denied), which fails the test-back job for every pull request. The
quay.io/minio/minio mirror remains publicly available, accepts the
same environment variables, and the container lookup in the Configure
MinIO step still matches the image name.
thx @mmaudet
lebaudantoine