I have rather strict security extensions/policies for my firefox profile, including both noscript and requestpolicy. Suddenly they're both saying wiki.gentoo.org wants access to https://1b9a50f4f9de4348cd9f-e703bc50ba0aa66772a874f8c7698be7.ssl.cf5.rackcdn.com , but other than the fact that the reasonably trusted wiki.gentoo.org is asking for access, I haven't the foggiest what else is on that site or how long it might reasonably be expected to remain at that rather arbitrary-looking domain name. WOT Scorecard doesn't have anything about them, and the only interesting thing HPHosts has to say about them is (again) no entry, but that the reverse-lookup returns as akamai. OK, so it's caching, but that's still an awfully arbitrary-looking name for something permanent enough I'm comfortable giving it permanent access permissions, and it's DEFINITELY not a gentoo.org domain. Suggestions/questions: 1) Please consider giving it a more permanent domain name in the gentoo.org hierarchy and change the wiki to point to that. This could solve issues if that arbitrary-looking *.rackcdn.com name changes or goes away, too -- just change the dns entry and you're good to go again. 2) If it's as temporary an arrangement as that name hints, why is wiki.gentoo.org relying on it strongly enough that page layout breaks without access to it, and why are we encouraging people to trust domains that could well belong to someone many gentooers may not trust in a few months? FWIW, I've granted temporary permissions for now, but of course they expire at end of session so I'll need to grant them every time... Meanwhile, at least it's not doubleclick or google-analytics, both of which /never/ get access permissions (noscript untrusted, unfortunately requestpolicy doesn't have a similar permanent no, don't bother asking about this domain again, type option) here. =:^/ Thanks
It's indeed a CDN provided by a sponsor of Gentoo (rackspace, hence rackcdn). The domain name is permanent and exclusively ours. *.gentoo.org isn't possible as we wouldn't share private keys with third parties, nor is there a feature to do custom SSL setups.
Addendum: And should we cease to use it, it's highly unlikely the same UUID is generated for another party again.
*** Bug 547536 has been marked as a duplicate of this bug. ***
