php.net website

php.internals

Mathias Grimm

9 years ago
Hi, I would like to know who is/are "in charge" of the website ( https://github.com/php/web-php). I think I would like to help improving it a bit. I can possibly understand the reasons why it is still like it is, code wise, but I think there is a lot of room from improvement. Also, from the reference point of view, I don't think it's a good example/image for the php community. I would like to understand also a little bit about how it is hosted/deployed/build etc. I was briefly asking Sara about it and as she pointed out it is likely a big project but I think we can do something about it. Cheers, Mathias Grimm

Midori Kocak

9 years ago
I can help.

Sara Golemon

9 years ago
On Wed, Jul 19, 2017 at 1:07 PM, Mathias Grimm <mathiasgrimm@gmail.com> wrote:
> I was briefly asking Sara about it and as she pointed out it is likely a > big project but I think we can do something about it. >
One thing I should have mentioned on twitter was: https://wiki.php.net/web/mirror That'll get you a locally running web-php instance though it's not ideal for iterative development against the git repo without some massaging. As to the actual hosts: There are (I believe) two hosts actually administered by @php.net folk: us1.php.net and us2.php.net, others (AIUI) are run by third parties and not under our control. The PHP version on these hosts is, comically, not the lastest-and-greatest. I'm fairly confident it's not even consistently 7.0+ so whatever you write needs to take that into account (particularly given the status of third-party mirrors). -Sara

Niklas Keller

9 years ago
> > On Wed, Jul 19, 2017 at 1:07 PM, Mathias Grimm <mathiasgrimm@gmail.com> > wrote: > > I was briefly asking Sara about it and as she pointed out it is likely a > > big project but I think we can do something about it. > > > One thing I should have mentioned on twitter was: > https://wiki.php.net/web/mirror > > That'll get you a locally running web-php instance though it's not > ideal for iterative development against the git repo without some > massaging. > > As to the actual hosts: There are (I believe) two hosts actually > administered by @php.net folk: us1.php.net and us2.php.net, others > (AIUI) are run by third parties and not under our control. The PHP > version on these hosts is, comically, not the lastest-and-greatest. > I'm fairly confident it's not even consistently 7.0+ so whatever you > write needs to take that into account (particularly given the status > of third-party mirrors). >
We should really change that and fully move to HTTPS. Regards, Niklas

Sara Golemon

9 years ago
On Wed, Jul 19, 2017 at 1:42 PM, Niklas Keller <me@kelunik.com> wrote:
> We should really change that and fully move to HTTPS. >
I was actually just thinking how lovely it would be to re-architect the mirroring process to use docker images. Benefits: * Usual consistent/predictable deployment arguments... * Full control of the webserver and PHP version (and extensions) used on mirrors. * Use docker hub as the distribution channel. (https out of the box) * Extra level of isolation for site hosts (web-php isn't alone on its hosts AIUI) * Apparently we could even add container image signing. That's sort of an orthogonal project to rewriting the site code, but it's arguably a simpler task to undertake. -Sara

Rasmus Lerdorf

9 years ago
On Wed, Jul 19, 2017 at 1:50 PM, Sara Golemon <pollita@php.net> wrote:
> > * Use docker hub as the distribution channel. (https out of the box) >
Getting https support in the web server is not what prevents us from getting https for www.php.net. It is key management across our geodns www.php.net that is the limiting factor here. A Docker image doesn't do anything to help with that. -Rasmus

Rasmus Lerdorf

9 years ago
On Wed, Jul 19, 2017 at 1:42 PM, Niklas Keller <me@kelunik.com> wrote:
> > We should really change that and fully move to HTTPS. >
I have looked at various ways of doing this, but it isn't trivial and it has absolutely nothing to do with the actual html and slapping in some https links instead of http. The problem here is that we have external volunteers running all our mirrors and we do geo-dns for www.php.net to your geographically close mirror site. Putting the private key for www.php.net on dozens of servers around the world we don't control is a non-starter. One way that I played with was to use letsencrypt and have each mirror request an ssl cert for their local mirror, ca1.php.net, for example, and include a CN alias for www.php.net in that request. Then we would run domain a validation gateway/proxy on www.php.net which would validate these requests on behalf of the mirrors. But there are some security issues with this approach that I haven't quite thought through. I would love to hear suggestions for perhaps a simpler solution to this problem that doesn't require pasting our private key all over the internet. -Rasmus

Stephen Reay

9 years ago
> On 20 Jul 2017, at 07:40, Rasmus Lerdorf <rasmus@lerdorf.com> wrote: > >> On Wed, Jul 19, 2017 at 1:42 PM, Niklas Keller <me@kelunik.com> wrote: >> >> >> We should really change that and fully move to HTTPS. >> > > I have looked at various ways of doing this, but it isn't trivial and it > has absolutely nothing to do with the actual html and slapping in some > https links instead of http. The problem here is that we have external > volunteers running all our mirrors and we do geo-dns for www.php.net to > your geographically close mirror site. Putting the private key for > www.php.net on dozens of servers around the world we don't control is a > non-starter. > > One way that I played with was to use letsencrypt and have each mirror > request an ssl cert for their local mirror, ca1.php.net, for example, and > include a CN alias for www.php.net in that request. Then we would run > domain a validation gateway/proxy on www.php.net which would validate these > requests on behalf of the mirrors. But there are some security issues with > this approach that I haven't quite thought through. I would love to hear > suggestions for perhaps a simpler solution to this problem that doesn't > require pasting our private key all over the internet. > > -Rasmus
Hey Rasmus, Does it need to be geo-dns, or could it instead be "geo-http" - a small number of servers responding to (www.)?php.net, which then respond with http redirects based on client ip. This is similar to how Debians "new" mirror service works for apt repos. I know it would be very nice to have the URLs stay as php.net (no CCn. Prefix) but anything else simple is going to involve tls certs for the base domain on servers the project doesn't control. The only other option I can see, would be to use "keyless" tls. It's described pretty well by CF here: https://www.cloudflare.com/ssl/keyless-ssl/ Unfortunately I don't know that cf have open sourced their nginx&openssl patches to make them talk to a remote key server. Happy to discuss this further if I can help. Cheers Stephen

Rasmus Lerdorf

9 years ago
On Wed, Jul 19, 2017 at 11:59 PM, Stephen Reay <php-lists@koalephant.com> wrote:
> > Does it need to be geo-dns, or could it instead be "geo-http" - a small > number of servers responding to (www.)?php.net, which then respond with > http redirects based on client ip. This is similar to how Debians "new" > mirror service works for apt repos. > > > I know it would be very nice to have the URLs stay as php.net (no CCn. > Prefix) but anything else simple is going to involve tls certs for the base > domain on servers the project doesn't control. > > The only other option I can see, would be to use "keyless" tls. It's > described pretty well by CF here: https://www.cloudflare. > com/ssl/keyless-ssl/ > > Unfortunately I don't know that cf have open sourced their nginx&openssl > patches to make them talk to a remote key server. >
I did look at the stuff from Cloudflare last year, but at the time they hadn't opened enough of it to implement. And it is really nice to have www.php.net be fast and low-latency from all over the world. Even the initial request. We are quite spoiled in Europe and North America with our fast peering. But in many other parts of the world, even if the local connection is fast, getting to a server in N.America is quite slow. but yes, eventually we may have to give up on geo-dns if we can't find a decent way to layer https on top of it. -Rasmus

Niklas Keller

9 years ago
> > I have looked at various ways of doing this, but it isn't trivial and it > has absolutely nothing to do with the actual html and slapping in some > https links instead of http. The problem here is that we have external > volunteers running all our mirrors and we do geo-dns for www.php.net to > your geographically close mirror site. Putting the private key for > www.php.net on dozens of servers around the world we don't control is a > non-starter. >
I expected something like that. How does it work then that https://www.php.net and https://php.net can redirect to https://secure.php.net? I must be reaching a server with a valid certificate, otherwise that wouldn't work. If putting a private key for php.net doesn't work, then we should get rid of these mirrors ASAP IMO.
> One way that I played with was to use letsencrypt and have each mirror > request an ssl cert for their local mirror, ca1.php.net, for example, and > include a CN alias for www.php.net in that request. Then we would run > domain a validation gateway/proxy on www.php.net which would validate > these > requests on behalf of the mirrors. But there are some security issues with > this approach that I haven't quite thought through. I would love to hear > suggestions for perhaps a simpler solution to this problem that doesn't > require pasting our private key all over the internet. >
They can also just request them themselves, but only for their mirror domain. If you allow them to issue for www.php.net, you can as well just put the current private key there. Regards, Niklas

Rasmus Lerdorf

9 years ago
On Thu, Jul 20, 2017 at 1:42 AM, Niklas Keller <me@kelunik.com> wrote:
> > They can also just request them themselves, but only for their mirror > domain. If you allow them to issue for www.php.net, you can as well just > put the current private key there. >
I think there is a big difference between putting the private key there and proxying validation for just a www.php.net CN alias. We already have a list of known mirrors, so we would make sure to only validate www.php.net for those. By validating www.php.net we allow any mirror to pretend they are www.php.net and no other *.php.net domain, which is exactly what we want. -Rasmus

Larry Garfield

9 years ago
On 07/20/2017 12:38 PM, Rasmus Lerdorf wrote:
> On Thu, Jul 20, 2017 at 1:42 AM, Niklas Keller <me@kelunik.com> wrote: >> They can also just request them themselves, but only for their mirror >> domain. If you allow them to issue for www.php.net, you can as well just >> put the current private key there. >> > I think there is a big difference between putting the private key there and > proxying validation for just a www.php.net CN alias. We already have a list > of known mirrors, so we would make sure to only validate www.php.net for > those. By validating www.php.net we allow any mirror to pretend they are > www.php.net and no other *.php.net domain, which is exactly what we want. > > -Rasmus
I figure this is a long-shot, but Platform.sh hosts a number of community sites for free. (We recently became the home of https://externals.io/, for example.) We have multiple data centers and SSL-all-the-things using Lets Encrypt. We'd be happy to help on the hosting side of the equation for any *.php.net sites if there's interest, either full or partial. We also offer PHP 7.1 and will have the just-released 7.2 beta up shortly. :-) (We have no opinion on the code side; we're just happy to help on the infrastructure side.) --Larry Garfield

Rasmus Lerdorf

9 years ago
On Thu, Jul 20, 2017 at 3:25 PM, Larry Garfield <larry@garfieldtech.com> wrote:
> > I figure this is a long-shot, but Platform.sh hosts a number of > community sites for free. (We recently became the home of > https://externals.io/, for example.) We have multiple data centers and > SSL-all-the-things using Lets Encrypt. We'd be happy to help on the > hosting side of the equation for any *.php.net sites if there's > interest, either full or partial. We also offer PHP 7.1 and will have > the just-released 7.2 beta up shortly. :-) >
I like the current mirror system which spreads out the duties to many different providers in more (around 60) countries than even someone as big as AWS can have data centers in. It is just the geodns part on www.php.net that makes https tricky. Nothing else about the current mirror system prevents https. -Rasmus

Mathias Grimm

9 years ago
If php is mainly static it could be almost fully cached in a CDN. For the downloads I don't think the latency would be a problem but that can also be in the CDN If php owned two servers in US and two in Europe and possibly 2 in Asia we would be goon in terms of latency for the search IMO. On 20 July 2017 at 19:38, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

Tony Marston

9 years ago
"Niklas Keller" wrote in message news:CANUQDCjB9UY8jTmmp43bQAW_9xJnoMbREN1zOQh1LubTfO4C-w@mail.gmail.com...
> >> >> On Wed, Jul 19, 2017 at 1:07 PM, Mathias Grimm <mathiasgrimm@gmail.com> >> wrote: >> > I was briefly asking Sara about it and as she pointed out it is likely >> > a >> > big project but I think we can do something about it. >> > >> One thing I should have mentioned on twitter was: >> https://wiki.php.net/web/mirror >> >> That'll get you a locally running web-php instance though it's not >> ideal for iterative development against the git repo without some >> massaging. >> >> As to the actual hosts: There are (I believe) two hosts actually >> administered by @php.net folk: us1.php.net and us2.php.net, others >> (AIUI) are run by third parties and not under our control. The PHP >> version on these hosts is, comically, not the lastest-and-greatest. >> I'm fairly confident it's not even consistently 7.0+ so whatever you >> write needs to take that into account (particularly given the status >> of third-party mirrors). >> > >We should really change that and fully move to HTTPS. > >Regards, Niklas
Why on earth should you need to use HTTPS for a website that does not deal with personal information? Nothing on that website can possibly be classed as "sensitive" so what would be the point?
-- Tony Marston

Andrey Andreev

9 years ago
Hi, On Fri, Jul 21, 2017 at 11:47 AM, Tony Marston <TonyMarston@hotmail.com> wrote:
> > Why on earth should you need to use HTTPS for a website that does not deal > with personal information? Nothing on that website can possibly be classed > as "sensitive" so what would be the point? >
Because HTTPS isn't just about encrypting secret data. Ensuring data integrity, authenticity is just as important. Cheers, Andrey.

lists@rhsoft.net

9 years ago
Am 21.07.2017 um 10:47 schrieb Tony Marston:
>> We should really change that and fully move to HTTPS. >> >> Regards, Niklas > > Why on earth should you need to use HTTPS for a website that does not > deal with personal information? Nothing on that website can possibly be > classed as "sensitive" so what would be the point?
because in a few months major browsers start with warnings if a unencrypted page contains any form not just logins? guess hwat happens by the search field on the right top corner? because HTTPS is also about data integrity? because currently when you click on the download link and have not explicitly called https://secure.php.net/ you land on unencrypted download-pages? because the whole web goes straight to HTTPS?

Lester Caine

9 years ago
On 21/07/17 09:47, Tony Marston wrote:
> Why on earth should you need to use HTTPS for a website that does not > deal with personal information? Nothing on that website can possibly be > classed as "sensitive" so what would be the point?
That applies to many of the websites I support yet the likes of Google and Bing now 'downrate' sites that don't have https and browsers complain about 'insecure' sites. Add the problems created when you add a private https area to a 'public' domain name and things get even messier. That some people even here insist that HTTP should be killed off seems not to have been thought through at all? On the website front, the problem I see is that while the MANUAL is a static site, adding things like the wiki, bug system, pecl/pear management, and other dynamic areas and allowing a decent CLEAN cross content search is what I see as being needed. Add managed translations then while a single static english copy of the main stuff is easy to distribute, and dynamic set of content WOULD be easier going forward. Except there would never be any agreement on how THAT would be managed and on which database engine :(
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Niklas Keller

9 years ago
Hey,
> I would like to know who is/are "in charge" of the website ( > https://github.com/php/web-php). > I think I would like to help improving it a bit. > > I can possibly understand the reasons why it is still like it is, code > wise, but I think there is a lot of room from improvement. Also, from the > reference point of view, I don't think it's a good example/image for the > php community. >
Could you name a few points that need improvements? I'd really say that PHP.net a really good reference compared to other projects.
> I would like to understand also a little bit about how it is > hosted/deployed/build etc. >
It's built on one server and then rsynced to other servers IIRC. Regards, Niklas

lists@rhsoft.net

9 years ago
Am 19.07.2017 um 19:07 schrieb Mathias Grimm:
> I would like to know who is/are "in charge" of the website ( > https://github.com/php/web-php). > I think I would like to help improving it a bit
a good start would be http://www.php.net/ also support https:// instead one needs to know that https://secure.php.net/ exists and supports encryption or at least point the downloads-menu to the encrypted page

Kalle Sommer Nielsen

9 years ago
Hi Mathias 2017-07-19 19:07 GMT+02:00 Mathias Grimm <mathiasgrimm@gmail.com>:
> I was briefly asking Sara about it and as she pointed out it is likely a > big project but I think we can do something about it.
A side note to all of this, I would personally like to see if parts of php.net redone, that we can integrate windows.php.net back into the main website, I was never a big fan of the separation of the two. The binaries are hosted by Microsoft if I remember correctly and has its own mirroring system, we could still keep this by just pointing the downloads to the relevant links to windows.php.net mirroring, as I can easily agree with the size amount that the Windows binaries do contain with all these flavors we produce nowadays.
-- regards, Kalle Sommer Nielsen kalle@php.net