Dear Sirs: The address used to check the KF5 Porting Status: https://developer.kde.org/~cfeck/portingstatus.html doesn't work. However, the address http://developer.kde.org/~cfeck/portingstatus.html works, so maybe the problem would be solved with a little change. DERIVED PROBLEMS Moreover, if people use the "HTTPS Everywhere" extension (developed by the EFF), when entering https://developer.kde.org/~cfeck/portingstatus.html as this extension sees that that address doesn't work, it tries to go to https://developer.kde.org but as that address leads people (maybe it shouldn't?) to https://techbase.kde.org and https://techbase.kde.org/~cfeck/portingstatus.html doesn't exist, people get even more confused: http://www.phoronix.com/forums/showthread.php?116987-KDE-Applications-15-04-Adds-Kdenlive-amp-KDE-Telepathy&p=484046#post484046 That could be solved if https://developer.kde.org/~cfeck/portingstatus.html just worked. Thank you for all the good work! Reproducible: Always
I'm not sure what your browser is doing - https://developer.kde.org/ cannot work at all as the server hosting it does not listen for https traffic. Something else is redirecting you, likely a defective browser addon - such as the EFF's HTTPS Everywhere module.
The point is, to avoid: 1) People seeing that https://developer.kde.org/~cfeck/portingstatus.html is not working. 2) Having only http://developer.kde.org/~cfeck/portingstatus.html with the insecurities of http. 3) The confusions of http://www.phoronix.com/forums/showthread.php?116987-KDE-Applications-15-04-Adds-Kdenlive-amp-KDE-Telepathy&p=484046#post484046 4) The page https://developer.kde.org redirecting people to https://techbase.kde.org ? if https://developer.kde.org/~cfeck/portingstatus.html worked, then this bug would be solved.
The interesting question here is: if developer.kde.org does not answer on https, why is the connection redirected to techbase.kde.org (and not for example on kde.org)? Ben, you know the structure, is there any special connection between developer and techbase? If there are no connection, I would say that the extension shouldn't do magic redirections and inform the user or drop the connection...
Accessing http://developer.kde.org/ will get you redirected to https://techbase.kde.org/ as it is the successor to the original content of that domain. That doesn't explain why https://developer.kde.org/ (which doesn't work) would end up as a redirect to https://techbase.kde.org/ though unless someone decided to circumvent our lack of SSL on developer.kde.org and "add" a rule to extension(s) to make "SSL everywhere" work. The extension is acting incorrectly in this case, so requests to fix it should be directed to it's developers.
The developers of the extension can change it, but that won't solve those main problems already stated in this bug report: 1) People seeing that https://developer.kde.org/~cfeck/portingstatus.html is not working. 2) Having only http://developer.kde.org/~cfeck/portingstatus.html with the insecurities of http. Etc. If this bug was solved that would be better for everyone.
How are you insecure by accessing http://developer.kde.org/~cfeck/portingstatus.html ?
"The main motivation for HTTPS is to provide authentication of the visited website and to protect the privacy and integrity of exchanged data". Web browsers such as Internet Explorer, Firefox and Chrome also display a padlock icon in the address bar to visually indicate that a HTTPS connection is in effect. -- https://www.instantssl.com/ssl-certificate-products/https.html For example, when Firefox users go to https://techbase.kde.org they see a padlock icon, they can click on it, they know is really KDE who is informing them, they see a message saying that the connection is secure, etc. When users to go https://developer.kde.org/~cfeck/portingstatus.html well, first they see that it doesn't work, it puzzles them, "what is happening?", doesn't give them a good impresion about KDE, etc. Then they have to think about what they can do, if they finally think that then can try http://developer.kde.org/~cfeck/portingstatus.html they know that they ignore who is sending them the pages, they have to think "is this information protected by encription?", "it should?", "what if it isn't?", think about the risks, what can be happening, "the other KDE pages I visited didn't do this", etc.; that is solved if just https://developer.kde.org/~cfeck/portingstatus.html works. When users see: 1) A page like http://developer.kde.org/~cfeck/portingstatus.html that doesn't have any icon indicating a secure connection, its real author, etc. 2) A page like https://developer.kde.org/~cfeck/portingstatus.html that doesn't work. they think that there is something wrong. That, and all the problems that have been written in this bug report, can be solved if just https://developer.kde.org/~cfeck/portingstatus.html works.
The purpose and benefits of HTTPS aren't being debated here. There is simply no reason to deploy HTTPS support and the required certificates on the machine hosting developer.kde.org however. In all the links that have been publicly posted by Christoph at least, none of them contain https://. They are all http:// so I don't know who made them https://. Likely some defective browser plugin - in which case fixing the plugin is the best thing to do here - as we've no plans, at least not in the immediate future to add SSL support to developer.kde.org (as it is simply unnecessary, it doesn't really host anything anymore).
> The purpose and benefits of HTTPS aren't being debated here. If someone has been reading there, he has seen https://bugs.kde.org/show_bug.cgi?id=346292#c6 > There is simply no reason to deploy HTTPS support As everyone can read: - http://googlewebmastercentral.blogspot.com.es/2014/08/https-as-ranking-signal.html - https://www.instantssl.com/ssl-certificate-products/https.html - https://bugs.kde.org/show_bug.cgi?id=346292#c7 - [Put there your reference to a site about security] Some users that care about security know what is authentication, some of them know what are "man in the middle" attacks, encryption, etc. and use HTTPS consequently. Other users don't know all that but they know enough to use HTTPS regularly, as they have been advised by security-conscious websites. When users see a KDE page like http://developer.kde.org/~cfeck/portingstatus.html that doesn't have any icon indicating a secure connection, its real author, etc.; and when they see that https://developer.kde.org/~cfeck/portingstatus.html does not even work; that all causes a bad impression about KDE. KDE is a lot better than that!
The link is not meant for users, they cannot do anything with this information. It is for developers getting an overview where porting help is needed.
That page shows a lot of information that can be used for several goals. For example, people use that page to see if a KDE software is stalling (or dying) or progressing, where is help needed, how the general KDE move to Qt5-KF5 is going, etc. This page is useful for people. For example, they talk about it in that page: https://kdepepo.wordpress.com/2015/02/18/kf5-porting-progress/ and that page gives an introduction to what is happening, because that page is aimed to final users. In http://www.phoronix.com/forums/showthread.php?116987-KDE-Applications-15-04-Adds-Kdenlive-amp-KDE-Telepathy&p=483992#post483992 one user wrote "Can't wait for KDE5 as default for archlinux which will happen as soon as all applications are ported over. So the question is: How many are left? [...]" and he was answered "Here you go: http://developer.kde.org/~cfeck/portingstatus.html" so that he could get informed. By the way, thank you, KDE people, for keeping us informed!
> they talk about it in that page kdepepo == cfeck The purpose of the blog was to motivate more developers to start porting. Having an overview of "how many already did it" clearly motivated other lesser known KDE application developers (e.g. Robby from Tellico fame etc.) to begin the porting efforts. > because that page is aimed to final users No, it isn't. It was motivated by Ömar's request finding information where porting help is needed, see http://lists-archives.com/kde-devel/32022-kf-port-progress.html > as soon as all applications are ported over There will be no "all". Many KDE developers already use a pure Qt5 system (in addition to some non-Qt applications), because they do not need all of them. Porting progress happens because either developers want their application as a Qt5 version, or other developers help porting, not because there is a schedule.
> > as soon as all applications are ported over > There will be no "all". [...] That's what that user wrote. Thank you, KDE people, for keeping us informed! developer.kde.org/~cfeck/portingstatus.html is useful!
Last week news have shown us new attacks and measures. Speaking about the question that Albert Astals Cid made about HTTPS security, it's important to beware of another kind of unexpected automatic attacks that are used if e.g. HTTPS connections are not used: Websites are used effectively as a botnet because attackers are able to intercept and modify javascript sent via HTTP. HTTPS stops a lot of threats, even if you're a hobbyist; HTTPS ensures that an attacker can't just intercept your page and put there his javascript and a bunch of exploit kits. http://googleonlinesecurity.blogspot.com.es/2015/04/a-javascript-based-ddos-attack-as-seen.html and last week news about Mozilla: Mozilla Security Blog -- Deprecating non-secure HTTP https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ Today we are announcing our intent to phase out non-secure HTTP. [...]
The URL in question no longer exists.