This fixes the problem for system packages (but not for imunify360):
tldr: Add a file
withCode:/etc/apt/apt.conf.d/99weakkey-warning
inside to disable the warning.Code:APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";
To undo, rm the file.
echo 'APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";' > /etc/apt/apt.conf.d/99weakkey-warning
deb http://apt.newrelic.com/debian/ newrelic non-free
deb [trusted=yes] http://apt.newrelic.com/debian/ newrelic non-free
Acquire {
AllowInsecureRepositories "true";
AllowDowngradeToInsecureRepositories "true";
}
APT {
Get {
AllowUnauthenticated "true";
}
}
I cannot update Imunify360 or any system packages - same issues as above. I have the 'package information not found' error when checking for updates.
I have two servers. For me the issue is only on the one running Ubuntu 24.04.2 LTS, my other server is on Ubuntu 22.04.5 LTS and it's updating normally.
I'm very new to Linux and Plesk - will the lack of system and Imunify updates pose a security threat if not available for a few days? I'm hoping Plesk and Imunify can release a fix asap. I'm not confident enough to apply the workaround fix shown above.
Thank you for the useful info. Fingers crossed they will release a fix asap.This is due to an update to the "update-manager" package on 28 May 2025 on Ubuntu 24.04.
It's affecting a lot of people, so either the repo owners will fix this quick and/or Ubuntu will roll it back temporarily.
If you ask me, their update makes sense security-wise, but not the way they rolled it out.
In any case, check here for temporary workarounds for Ubuntu 24. Make sure you revert them when they are not necessary anymore. DSA1024 is not deemed secure anymore, so allowing it unless you really need to (like now) isn't a good idea.
For workaround #1, you need to perform the command as root.Thank you for the useful info. Fingers crossed they will release a fix asap.
The workaround 1 seems the easiest to implement (I'm a little nervous about creating or modifiying files). Excuse my lack of knowledge, but do I literally just type:
echo 'APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";' > /etc/apt/apt.conf.d/99weakkey-warning
after I've logged in to my SSH remote console? or do I need to do anything else?
Also, how do I revert this afterwards?
Thanks again, feels like a rather inconvenient time to be a Plesk newbie!
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";
rm -f /etc/apt/apt.conf.d/99weakkey-warning
Thank you, that's massively helpful. Much appreciated.. now I know why this forum is so useful!For workaround #1, you need to perform the command as root.
It will create the file "/etc/apt/apt.conf.d/99weakkey-warning" and write...:
... into it.Code:APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";
You can do the same with nano or vi or any other editor if you prefer.
To revert the change, you only need to remove the file this command created, like this:
Code:rm -f /etc/apt/apt.conf.d/99weakkey-warning
It's not directly Plesk's fault (my failing repos are extensions, not Plesk ones). IMHO, it's Ubuntu's, they made a necessary change (dsa1024 isn't really secure anymore), but they rolled it out way too fast or with too little prior warning. Plesk users (and NewRelic, and many others) are just collateral damage.
Reenabling the dsa1024 algorithm (workaround 1) is better than nothing (workaround 2 and 3), but there's a reason why they disabled it: it isn't considered secure anymore.@tlacroix
Sorry - last question! Would you recommend I delete the file and just add it on when I need to do an update, or leave it in place until Plesk / Imunify release a proper fix?
Thanks again for your detailed reply, totally understand the reasons now, and makes sense.Reenabling the dsa1024 algorithm (workaround 1) is better than nothing (workaround 2 and 3), but there's a reason why they disabled it: it isn't considered secure anymore.
So to answer your question: Yes, you probably don't want to keep dsa1024 enabled longer than you need to, and you want to recheck it once in a while.
The risk with insecure keys is someone being able to break them and impersonate a repository and inject their hacked packages while your systems think they are legitimate. It would be super complexe and it is improbable, but it is possible.
Same as for TLS 1.0 which is now considered insecure, and TLS 1.2 + 1.3 being now the norm, with TLS 1.0 and 1.1 being usually entirely disabled.
You probably won't ever have any problem if you don't disable dsa1024 when you don't need it anymore. But better safe than sorry.