When I currently run tlsdate it says: # tlsdate certificate is self signed child process failed in SSL handshake I saw that you added something in the ebuild to change upstream's time source to google. It is somehow this that causes this (although I haven't investigated further). When I comment that out it works. I don't really see why Gentoo should change upstream's default here at all. Please note that ptb.de is not a "random German site", it's the site of the organization that runs the Atomic clocks in Germany. So it's kinda some official state-controlled time source, which is probably the reason usptream chose this.
It is not the changed server alone. The problem is connected to bug #446426. The file /etc/tlsdate/ca-roots/tlsdate-ca-roots.conf seems to be used by tlsdate. It is replaced with a symlink to /etc/ssl/certs/Equifax_Secure_CA.pem, which is just one of the certificates in the original file. Using the original file from tlsdate fixes that problem.
I'm still not sure if we should change upstream's defaults at all here, but for now I fixed it to always use the correct www.google.com config. The problem was that tlsdate hardcodes a default server and that was still www.ptb.de, though there was no cert for it installed.
using Google makes a lot more sense: - Google's job is to run websites - Google's servers are distributed around the world - Google's dns is round robined & localized - Chrome OS uses tlsdate with Google servers which means it's guaranteed to be working all the time the upstream default on the other hand has no such guarantees: - being good at atomic clocks doesn't mean you're good at websites - they have a single server in Germany
@vapier: As you have re-opened this bug, do you see any problem with the current ebuild? Basically in 0.0.12-r1 I sticket with the google-presetting (and I won't fight over it - I'm okay with leaving it that way). What I changed was that it *always* defaults to google. Before it was that the tlsdated-config had google configured, but the tlsdate binary had ptb.de compiled in. Which caused tlsdate to fail if you just ran it. Do you have any issues with that? I plan to request stabilization for 0.0.12-r1 soon.
(In reply to Hanno Boeck from comment #4) sorry, the comments in this bug and the changelog made it sound like the defaults were changed from google back to what upstream was using (ptb.de), so i re-opened. i've read the actual ebuild now and see what you're doing. stabilizing that is fine. we shouldn't have to mess with the compiled in defaults, but until we fix bug 532464 & bug 534394 by having tlsdate use the existing cert store instead of hardcoding a single path, we'll have to live with that.
(In reply to SpanKY from comment #5) err, *this* is bug 532464 ;) looks like bug 534394 contains a fix for the cert store issue, so i'll post a -r2 to try and fix things up. we can still move forward with -r1 to stable though.
fwiw, upstream has now changed to google.com by default: https://github.com/ioerror/tlsdate/commit/2049a7c43f591b490a9840454c272a8629cd1356
