I, like a number of people on these forums, run my Roon Server on DietPi (x86-native). To date this has been pretty painless and trouble free. I also run Plex on the same machine.
However, today I have noticed an issue:
DietPi update fails to work because of an obsolescent signing key for Plex.
The problem is also visible using ‘apt update’ where I see:
Warning: OpenPGP signature verification failed: https://downloads.plex.tv/repo/deb public InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on CD665CBA0E2F88B7373F7CB997203C7B3ADCA79D is not bound: No binding signature at time 2025-09-22T18:33:03Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
Error: The repository ‘https://downloads.plex.tv/repo/deb public InRelease’ is not signed.
Notice: Updating from such a repository can’t be done securely, and is therefore disabled by default.
Notice: See apt-secure(8) manpage for repository creation and user configuration details.
The reference to " because: SHA1 is not considered secure since 2026-02-01T00:00:00Z" suggests that this has only become an issue over the last couple of days.
In the case of the apt update, it is not immediately an issue because all apt sources other than Plex get updated and a subsequent “apt upgrade” works as expected (with the exception that it would not update plex should a new version be available).
However, when running dietpi-update, this failure causes the script to fail and not proceed to perform the update.
I can get the dietpi-update script to work as expected (but without any Plex updates) by renaming /etc/apt/sources.list.d/plexmediaserver.list so that it is not picked up as a repository source by apt or apt-get. However, this is a workaround. Not a fix.
If things remain like this, the Plex package overwriting plexmediaserver.list, we will adjust the key location we download the latest signing key to. But since ChuckPa mentioned that engineering is looking for a different solution, I’ll wait for next release (or DietPi release) before changing anything our end.
The probably easiest solution is
sudo dpkg-reconfigure plexmediaserver
to let the package postinst re-download the key. As long as this is done by the package, our /etc/apt/trusted.gpg.d/dietpi-plexmediaserver.gpg isn’t used anymore after any package upgrade, hence no point to update that one.
I bought a lifetime subscription to Plex before going to Roon. For a while, I could still access my music server from both platforms. Lately, I have lost that access via Plex, which I could not solve. Roon works well and when both ran, Roon sounded much better. I don’t have any video on my server; Plex is “serving” nothing (sorry for the pun). My server is a dedicated Windows laptop, and so the whole implementation is different than yours. I would be quite vexed also if an error notation showed that Roon stopped working because of Plex. I am thinking: why hang on to Plex?
Unfortunately, that did not work - probably because of:
Err:2 https://downloads.plex.tv/repo/deb public InRelease
Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on CD665CBA0E2F88B7373F7CB997203C7B3ADCA79D is not bound: No binding signature at time 2025-09-22T18:33:03Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
So, since the beginning of February, sha1 keys are not being accepted - no matter where they are located.
I can, of course, still download any updated .deb package directly from the Plex web site and install using dpkg but this issue still prevents dietpi-update running successfully with the plexmediaserver sources included.
I think this is completely unrelated to the issue that I was drawing attention to. Until today (for me - but maybe for a few days now), Plex Media Server and Roon Server both running on the same Dietpi machine have caused no issues.
Yeah I just saw the same. Weird that re-downloading the key to /etc/apt/trusted.gpg.d/dietpi-plexmediaserver.gpg and removing the signed-by from the list originally worked. It seems they changed the key again, or reverted the rotation, so it is the old SHA1 one again or so .
Reading new posts on the topic in the Plex forum, they are setting up new repos and deprecate the existing ones. So there is no real point to keep that repo, it won’t receive any update anymore:
Of course this means Plex (re)installs are broken for now. Need to wait until new repo and key paths are known. Otherwise, downloading the DEB without APT repo is the only way.
1 Like
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
7
The perfect solution is for Plex or the package maintainer to issue a new key.
However, as a workaround, you could sign the current key with your PGP key, and import your key into APT …
… or wait for the package maintainer to update (and disable the repo until then.)
Somewhat funny that they reverted the repo after the needed key rotation because some users’ lists were pointing to a different key than expected, but thereby broke the repo entirely . To me it seems quite unnecessary to create a new repo. All it needs is a clear docu about the automatic key download and list creation in the package postinst (or removing this part), and hence aligned instructions about where to download the key manually to, if it gets rotated. A clean SHA256 signature works with all versions or all APT-based distros. But well, now we need to wait until new repos were setup.
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
9
It looks like a pigs breakfast. I’ve recently rebuilt my media server, so will spin up a pod for Plex later.
.