Please note that llvm.org proper is NOT moving at this time. Therefore SVN, Bugzilla, ViewVC, and all the llvm.org/* webpages will remain on that server. I will be updating on this in a separate email.
How does this impact you?
You may see a very short downtime (< 1 hour) when the switch is made. This is most likely due to the DNS switch. I will notify the list when all websites listed have been moved. Since this does not involve SVN, the downtime is hopefully tolerable.
Are you fixing the SSL problem?
Yes. The new server will have SSL support for all websites and have an updated certificate.
What about the website auto-update?
Currently, the web sites all automatically update via post-commit hook for SVN. We have temporarily set up an alternative method and websites will update every 30 minutes.
What about website documentation generation?
There are 3 scripts that generate documentation on the web server. For doxygen, it will continue to update daily. For sphinx documentation, it will update every hour instead of immediately after a commit.
In order to increase visibility into the server, these scripts have been enhanced to now email a list to indicate success or failure. You can either subscribe to the list or check the archives if you have concerns about documentation not being updated: http://lists.llvm.org/cgi-bin/mailman/listinfo/www-scripts
Why are you doing this?
We want to increase the reliability, stability, and speed of the LLVN services. The current machine is outdated and is not set up for our current needs.
If you have any questions, please do not hesitate to ask.
Please note that llvm.org proper is NOT moving at this time. Therefore SVN, Bugzilla, ViewVC, and all the llvm.org/* webpages will remain on that server. I will be updating on this in a separate email.
How does this impact you?
You may see a very short downtime (< 1 hour) when the switch is made. This is most likely due to the DNS switch. I will notify the list when all websites listed have been moved. Since this does not involve SVN, the downtime is hopefully tolerable.
Are you fixing the SSL problem?
Yes. The new server will have SSL support for all websites and have an updated certificate.
Please note that llvm.org proper is NOT moving at this time. Therefore SVN, Bugzilla, ViewVC, and all the llvm.org/* webpages will remain on that server. I will be updating on this in a separate email.
How does this impact you?
You may see a very short downtime (< 1 hour) when the switch is made. This is most likely due to the DNS switch. I will notify the list when all websites listed have been moved. Since this does not involve SVN, the downtime is hopefully tolerable.
Are you fixing the SSL problem?
Yes. The new server will have SSL support for all websites and have an updated certificate.
Is there any plan to make the migrated sites SSL-only? That is, have http://clang.llvm.org/** only serve a redirect to https://clang.llvm.org/** instead
of serving content over http.
If not, that'd be a great thing to add to the plans.
I’m curious: why?
I understand that you want anything authenticated (bugzilla, …) or the binary/source download, but what’s the reason to use SSL for looking up doxygen or LangRef? (Easier to setup or get it right could be a reason, I don’t know)
Well, sure, that's one reason: it's much easier to ensure that everything
that matters is properly protected, if you always protect everything. You
don't have to think about it anymore, and you won't mess up and
accidentally allow unencrypted binary downloads, which puts users at
unnecessary risk of tampering when they forget to explicitly type https.
Also: do you really want your site's visitors to be running the random
javascript that Comcast injects into it? Using https avoids that, too.
But beyond that: there's no downside. Why should *anyone* continue to serve
http traffic? It's just all around better and safer to require https, for
everything, always.
I think it's easier to simply enforce the redirect and have everything be served over TLS. Once you do that, there's never any danger of parts that require TLS not actually getting it.
and then I know everything is using TLS. (It seems llvm.org is using apache, but I imagine the apache directives are equally simple.) It seems significantly easier to maintain than needing to serve different content using HTTP vs. HTTPS.
As an added benefit, every connection tests your TLS configuration meaning that it's much easier to find problems such as expired certs. For example, https://llvm.org is using a cert with SHA-1 which it absolutely should not be doing in 2017. This shows up as insecure for me in Chrome.
(One can also make arguments about how all Internet traffic should be authenticated at the least, but I think the pure engineering argument that it's easier to just enforce it everywhere is the better argument.)
This is one reason why blindly redirecting http to https is a bad idea. Unless you can be sure that everything everywhere is done correctly, you put clients through extra pain for content that doesn’t need the extra protection. (Note, I’m not arguing for or against this particular change … only pointing out that it isn’t free of consequences.)
Jim Rowan jmr@codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
I take you haven't tried to use WiFi at UK airports or coaches recently?
There are a lot of other places with completely broken "transparent"
proxies and forcing HTTPS (especially in combination with HTST) makes
the network unusable.
No, I haven't had the pleasure recently, so I'm not aware of what you're talking about.
But, whatever the case is there, I don't think that's an argument for continuing to serve http, especially for a small site like llvm. At this point, almost all of the major/popular sites on the internet (facebook.com, google.com, amazon.co.uk, wikipedia.org, github.com, yahoo.com, ...), already force https.
So, if UK airport WiFi doesn't work with https, and therefore doesn't work with a majority of the popular sites, well...I hardly see how they can claim to be providing WiFi service at all, at this point. Any such network is going to be, in the eyes of most users, simply useless and broken.
You said there is no downside. I've demonstrated a situation people can
face right now where it can make a website unusable. Don't handwave away
the cost of forcing HTTPS, it adds overhead for all involved parties.
Don't get me wrong, I'm all for properly supporting HTTPS everywhere,
but it is not without downsides.
Hi,
I know this thread is quite old, however, I am about to start working on: https://bugs.llvm.org/show_bug.cgi?id=39309 and I couldn’t quite tell if there was any real consensus reached in this thread? Are folks okay with me changing the Apache configs to force a redirect to HTTPS for all of the llvm.org landing pages? Honestly, just from an administration standpoint it would be much easier if I could make everything work the same way. I understand it will incur some overhead processing costs for some people and I’m sorry for any inconvenience. I feel, in this case, the simplicity of maintaining a single configuration outweighs the the burden of connecting over HTTPS. Thoughts?
Hi,
I know this thread is quite old, however, I am about to start working on: 39309 – foundation page link goes to "http://foundation.llvm.org/documents/" rather than "http://llvm.org/foundation/documents/" and I couldn't quite tell if there was any real consensus reached in this thread? Are folks okay with me changing the Apache configs to force a redirect to HTTPS for all of the llvm.org landing pages? Honestly, just from an administration standpoint it would be much easier if I could make everything work the same way. I understand it will incur some overhead processing costs for some people and I'm sorry for any inconvenience. I feel, in this case, the simplicity of maintaining a single configuration outweighs the the burden of connecting over HTTPS. Thoughts?
+1
Not sure what you mean by landing pages, but I think all http
requests, to any resource under llvm.org or its subdomains, should
redirect to https.
Hi,
I know this thread is quite old, however, I am about to start working on: 39309 – foundation page link goes to "http://foundation.llvm.org/documents/" rather than "http://llvm.org/foundation/documents/" and I couldn't quite tell if there was any real consensus reached in this thread? Are folks okay with me changing the Apache configs to force a redirect to HTTPS for all of the llvm.org landing pages? Honestly, just from an administration standpoint it would be much easier if I could make everything work the same way. I understand it will incur some overhead processing costs for some people and I'm sorry for any inconvenience. I feel, in this case, the simplicity of maintaining a single configuration outweighs the the burden of connecting over HTTPS. Thoughts?
+1
Not sure what you mean by landing pages, but I think all http
requests, to any resource under llvm.org or its subdomains, should
redirect to https.
I meant exactly what you just said, only I said it poorly. I shouldn’t comment late at night.
