> hi, >>>> >>>> any update on this? >>>> currently we have the following mirrors without openssl support: >>>> >>>> - >>>> - md1.php.net >>>> - jp1.php.net >>>> - dk1.php.net >>>> - pt2.php.net >>>> - ru2.php.net >>>> - es2.php.net >>>> - in2.php.net >>>> - mx2.php.net >>>> - pa1.php.net >>>> - tw1.php.net >>>> >>>> we could send out a notification to the php-mirrors list, that there is >>>> a new requirements, and give them a reasonable timeframe to fix up. >>>> btw. I've just heard from Googleguy that there are some mirrors where >>>> the posttohost is already broken, as they restrict external network access >>>> from php. >>>> I suppose that also should be listed as a requirement. >>>> >>> >>> Yea, I opened a bug for this last month. I'm not sure what the best fix >>> is but this prevents users from being able to do things like add notes or >>> vote on notes from those mirrors that disable outgoing requests since all >>> those things depend on posttohost. >>> >>> Here's the bug report. >>> >>> https://bugs.php.net/63850 >>> >>> >>>> >>>> -- >>>> Ferenc Kovács >>>> @Tyr43l - http://tyrael.hu >>>> >>> >>> >>> >>> >> we just had a discussion with GoogleGuy on irc and he brought up an >> argument, which was discussed before: >> why do we even allow mirrors to handle php.net account information in >> the first place? >> with the current architecture there isn't a feasible way which would >> allow them to use https, so anybody on their or the visitors' network could >> harvest accounts from the account-request, and even if we somehow fix that, >> a rouge mirror could still steal the passwords from the account-request >> form before sending it to the master. >> I would like to make a small change, adding a hostname check >> to git-php.php and redirect to http://www.php.net/git-php.php if we are >> on a mirror. >> After this, two other improvements could be done later: >> >> - we could TOKEN protect this master api entry, as it will be used >> only by services controlled by us. >> >> I've considered the TOKEN approach for the user notes API I integrated > recently, but one of the problems I came across is how to validate that the > mirror is indeed a legitimate mirror. This is actually a non-trivial > problem as it turns out. One of the considerations was how to push the > token to the mirror without exposing it publicly. Possible solution was to > have the mirror pull the token from master. The problem with that is how do > you verify it is indeed a php.net mirror? You could use the zone file, > but then again there are IPs listed in that zone file that don't actually > point to valid mirrors. For example, http://mx.php.net > > Note the DNS records indicate an A record that does not point to a valid > php.net mirror. > > ;; QUESTION SECTION: > ;mx.php.net. IN A > > ;; ANSWER SECTION: > mx.php.net. 3593 IN A 187.162.34.26 > mx.php.net. 3593 IN A 148.206.80.9 > > > I've baffled over ways to solve this problem that were feasible with our > architecture. Ideas are welcome. > >
as long as the mirrors serve the account request there isn't much point adding a TOKEN. it would require us an additional step in the mirror registration (give out the TOKEN on a secure/private channel), TOKEN compromises would require interaction from the mirrors to fix (you can't revoke the TOKEN because other mirrors are still not updated, or you would need to give out unique TOKENs for each mirror). but we are talking about removing the account-request handling from the mirrors, moving it to the www.php.net mirror which is hosted and controlled by us, so we can set manage a TOKEN there the same way as we do it now for other services. >> - enable https for www.php.net: we have a virtualhost already ready, >> but it turned out, that some assets/resources are loaded from http://and >> that breaks the site layout/javascript. >> >> > As for https might I add we consider using URIs with relative protocols to > resolve this issue in the future "://php.net/foo", for example, instead > of "http://php.net/foo"; so if we decide to switch everything https in the > future this shouldn't be an issue resolved with code. > that is also my personal preference. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
