On Wed, Jan 9, 2013 at 5:49 AM, Ferenc Kovacs <[email protected]> wrote:
> > > > On Wed, Jan 9, 2013 at 11:22 AM, Sherif Ramadan > <[email protected]>wrote: > >> >> >> >> On Wed, Jan 9, 2013 at 5:19 AM, Ferenc Kovacs <[email protected]> wrote: >> >>> >>> >>> >>> On Thu, Sep 20, 2012 at 5:30 PM, Daniel Brown <[email protected]> wrote: >>> >>>> On Thu, Sep 20, 2012 at 7:30 AM, Ferenc Kovacs <[email protected]> >>>> wrote: >>>> > >>>> > so should I wait for them to go away (some? all?), or should I just >>>> commit >>>> > my patch knowing that it will not work on some of the mirrors? >>>> >>>> No, just hold off for now. I want to get them out first, so we >>>> don't have more complaints coming in about broken things (in addition >>>> to php.net/www.php.net. >>>> >>>> -- >>>> </Daniel P. Brown> >>>> Network Infrastructure Manager >>>> http://www.php.net/ >>>> >>> >>> 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. > > - 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. > > > what do you think? > > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
