This is not really a pamac issue but is caused by the CDN url for the aur package database.
You are - most likely - only seing this because you have opted to update custom pkgbuilds in the same run and - for reasons that should be obvious - this is not recommended.
Always sync official repo first - restart if required - then you can rebuild the custom packages.
Everybody agrees on this. The error message is not expressive enough. I guess it’s an invalid certificate because the server killed the connection before it even could have sent a certificate.
But that’s semantics.
If this is not the recommended way, why do you give me a gun, show me where my foot is, and tell me in all other threads “please pull it now”.
(The “you” is generic and pointed at you.)
I can’t rebuild the AUR packages after using pacman for the “official” updates because with pamac update --aur, it still tells me the above mentioned error.
What a poster recommend in a thread is the poster’s opinion.
One can only speculate on the reason CDN generates those messages. One valid thought - I sincerely hope not - the source where CDN pulls the package database has failing renewal script - but I don’t know.
@codesardine is co-admin on some of the servers - perhaps he can enlighten the community.
The message is more clear when you open Firefox
Secure Connection Failed
An error occurred during a connection to aur.manjaro.org. The OCSP response does not include a status for the certificate being verified.
Try disabling OCSP stapling in Firefox under settings privacy to restore functionality, meanwhile we will research if this firefox issue can be fixed server side.
I understand the pamac issue, however there is also a bug in firefox that does not read certificates with sha2 and I provided a temporary fix for that, as for pamac it will be investigated by the team, so my comment above was not very specific and it does not provide a fix for your issue but it will provide a fix for people having this issue on firefox.
The only reason why ppl get that message is because the AUR’s CDN is just mal-configured…
When it seemingly does “rate-throttling” it serves a page with a bad certificate, because if you try sometime later and get lucky the error disappears and the normal working continues without error, eg packman database + AUR np…
The CDN serves the AUR domain with proper certificate, but the error page is served from a default page with bad certificate or config.
AUR, Download and Mirrors use the same as our main homepage.
So why do I get those errors?
CDN works like this:
we have one storage server which gets every 10 Minutes a new DB file from the Arch server
we purge the files every 15 mins from all CDN nodes
CDN nodes will fetch the updated DB files from the storage server and cache them again
If you hit a node which is in progress to purge the file you hit an error page. pamac should in that case ignore the error and try to fetch that file again. I assume if you retry to fetch the file you won’t have that error. You only wonder why you have that error and complain.
The certificates of the domains the CDN serves might be all correct, but how about the certificate of the default error pages of the CDN itself?
Because if there are no wrong certificates at all, why the error message about the certificate then?
“Simple logical deduction dedective Holmes”
not so easy if you have to do it manually. I can check if their API supports something so we can use cron jobs from our servers and upload them that way, else it is a paid service to let them maintain the CERTs. However, that is not the problem here. More or less our strict domain rules don’t accept other CERTs from the CDN provider not matching our domain when a user hits an error page when a node is in purge mode.