# Windows Peer Verification - Thread: https://externals.io/message/72100 - Original archive: https://news-web.php.net/php.internals/72100 - Started by Daniel Lowrey on 2014-02-03T19:19:36+00:00 - Messages: 29 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/72100.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #72100 — Daniel Lowrey — 2014-02-03T19:19:36+00:00 URL: https://externals.io/message/72100#72100 > And anyway I'm not in agreement that if people are going to use > outbound encryption -- if they are going to simply call a PHP function > -- they need to understand how to update their local CA bundle. I > would think that, the majority of the time, users are either [a] > loading a provided "PHP binding" (.PHP file) for a public API or [b] > copying-and-pasting boilerplate code from API documentation and, just > speaking realistically, you should not expect them to know what's > going on under the hood. You can have a relatively good understanding > of HTTP (without the S) and when your service says "now you must use > encryption" there shouldn't be a big learning curve on the user side. I'm totally in agreement with everything you've said. There is no "learning curve." The only thing required for a secure transfer in this case is the knowledge that: (1) You need a CA to verify that the other party is who they say they are (2) As such, you have to tell PHP about the CA file(s) you want it to use. There is nothing confusing or difficult about setting a single php.ini value "openssl.cafile = C:\path\to\cacert.pem" But there is something *very* wrong with allowing users to do this without peer verification by default: file_get_contents('http://yourbankinginstitution.com'); The whole point of the recently accepted RFC and the new RFC on TLS security is to eliminate the need for users to understand TLS to use these features. There is no disagreement here and I'm not sure what you're arguing here. --- ## #72101 — Daniel Lowrey — 2014-02-03T19:27:01+00:00 URL: https://externals.io/message/72100#72101 · In reply to: #72100 > I have added the curl ca cert file option As of the recently merged RFC there now exist both openssl.cafile and openssl.capath (for hashed certificate directories). I was unaware of the curl php.ini option and perhaps you were unaware of the new openssl ini options? Either way, it might make sense to have a single universal option instead. There is still time to change/implement something like this for 5.6. Thoughts? --- ## #72104 — Sanford Whiteman — 2014-02-03T19:33:39+00:00 URL: https://externals.io/message/72100#72104 · In reply to: #72100 > I'm totally in agreement with everything you've said. There is no "learning > curve." The only thing required for a secure transfer in this case is the > knowledge that: > (1) You need a CA to verify that the other party is who they say they are > (2) As such, you have to tell PHP about the CA file(s) you want it to use. No. The other "only thing" required for a secure transfer on Windows, if you do not ship a working Windows installer, is that the user [] have permission to manage the server's PHP installation For emphasis: we are talking about the PHP developer. I don't know how you can assume that the PHP dev who is authoring -- let alone simply rolling out -- a WordPress plug-in can perform this step. Perhaps "learning curve" is the wrong term. How about "newly required server privileges"? Of course, they may be able to specify a PEM in their home directory. Which means they have to change the code they are rolling out to add the extra arguments. Which means that third-party code can no longer be updated automatically. > There is nothing confusing or difficult about setting a single php.ini > value "openssl.cafile = C:\path\to\cacert.pem" > The whole point of the recently accepted RFC and the new RFC on TLS > security is to eliminate the need for users to understand TLS to use these > features. The intent of turning on peer verification by default is to enforce better security at the possible (in fact, previously documented) cost of users having to understand, if not TLS itself, how to manage a CA > There is no disagreement here and I'm not sure what you're > arguing here. --- ## #72105 — Sanford Whiteman — 2014-02-03T19:37:49+00:00 URL: https://externals.io/message/72100#72105 · In reply to: #72100 > I'm totally in agreement with everything you've said. There is no "learning > curve." The only thing required for a secure transfer in this case is the > knowledge that: > (1) You need a CA to verify that the other party is who they say they are > (2) As such, you have to tell PHP about the CA file(s) you want it to use. No. The other "only thing" required for a secure transfer on Windows, if you do not ship a working Windows installer, is that the user (3) have permission to manage the server's PHP installation For emphasis: we are talking about the PHP developer. I don't know how you can assume that the PHP dev who is authoring -- let alone simply rolling out -- a WordPress plug-in can perform this step. Perhaps "learning curve" is the wrong term. How about "newly required server privileges"? Of course, they may be able to specify a PEM in their home directory. Which means they have to change the code they are rolling out to add the extra arguments. Which means that third-party code can no longer be updated automatically. > There is nothing confusing or difficult about setting a single php.ini > value "openssl.cafile = C:\path\to\cacert.pem" > The whole point of the recently accepted RFC and the new RFC on TLS > security is to eliminate the need for users to understand TLS to use these > features. The intent of turning on peer verification by default is to enforce better security at the possible (in fact, previously documented) cost of users having to understand, if not TLS itself, how to manage a trusted CA bundle, and having permission to do so. Please, let's not pretend that these measures are "eliminating" any burdens previously placed on the user -- except the burden that follows accidentally compromising your system due to forged certificates, of course! -- S. --- ## #72106 — Pierre Joye — 2014-02-03T19:39:31+00:00 URL: https://externals.io/message/72100#72106 · In reply to: #72101 > > > > […] > > As of the recently merged RFC there now exist both openssl.cafile and > openssl.capath (for hashed certificate directories). I was unaware of the > curl php.ini option and perhaps you were unaware of the new openssl ini > options? > > Either way, it might make sense to have a single universal option instead. > There is still time to change/implement something like this for 5.6. > Thoughts? As we discussed on IRC, I think it makes sense to merge the curl CA file ini setting and use the openssl one. Maybe alias them so we won't have BC issues (curl is in place since quite some time already). About bundling the CA file with the windows release (we agreed not to release them with the src, good this way), we still have time to evaluate it. We will not bundle it for the next releases, including first betas. If testers are complaining too much, it will be a sign that we may have to bundle it. As the support part won't scale well with all our end users on Windows. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #72108 — Daniel Lowrey — 2014-02-03T19:44:01+00:00 URL: https://externals.io/message/72100#72108 · In reply to: #72104 On Mon, Feb 3, 2014 at 2:33 PM, Sanford Whiteman wrote: > > […] > "learning > > […] > > > […] > use. > > No. I'm still completely befuddled. No one is arguing against ease-of use here. Have you read the relevant RFCs? Please just take sixty seconds to at least read this one part then come back and tell me I'm making it *more difficult* for the average user to make secure transfers. https://wiki.php.net/rfc/improved-tls-defaults#tldr_definitive_progress I'm clearly trying to simplify secure https:// usage as much as possible. What *may or may not be tenable* is the management of a custom CA file. Distribution has its own issues and deserves as much consideration as userland ease-of use. Instantly discounting those is a myopic approach. You can't just instantly rule out that bundling a file might not be feasible. --- ## #72116 — Sanford Whiteman — 2014-02-03T20:34:38+00:00 URL: https://externals.io/message/72100#72116 · In reply to: #72108 > No one is arguing against ease-of use here. PHP users may now need to have write access to PHP.INI in order to not get logs filled with security warnings, for the same code that previously did not issue a warning. Or else they need to change all outbound stream code, which in many cases isn't even theirs to safely change. This isn't ease-of-use. This is hardening security at the cost of ease-of-use for some users. We must call it what it is. > Have you read the relevant RFCs? I was the one who told you the Peer Verification RFC would break the official WPI package (break == `E_WARNING` without end) and nobody cared then. Now it's like a minor after-the-fact surprise after the RFC was accepted. This thread itself actually surprised me: I honestly didn't think you cared about the issue at all. Figured the next we'd hear about it would be in WONTFIXes on the bug tracker with directions to download the CA bundle. I'm psyched I got the earlier heads-up on Internals, and I don't worry about our servers because I have full control. Other users don't and you will upset them. I am not saying these changes to PHP are not advisable. They are! But how can you be "befuddled" when you started a thread that notes that Windows users may need to have sysadmin privileges -- else they will be constantly reminded that they don't? > Please just take sixty seconds to at least read this one part then > come back and tell me I'm making it *more difficult* for the average > user to make secure transfers. We will have made it easier for PHP users to either [a] make secure transfers or [b] fill up their logs with warnings The "average" user will fit into [a] per recent PHP statistics (at least on the production side) so yeah, the "average" user will see a major benefit. How many users need to fit into [b] for you to acknowledge that this rollout is going to be less than fully successful -- not a failure, just not an unqualified success -- unless we take those users seriously? > Instantly discounting those is a myopic approach. You can't just > instantly rule out that bundling a file might not be feasible. It's fine to not bundle a file. It's not fine to pretend that warnings will not be endlessly spewed on Windows without a file. It's not fine to suppress these warnings on Windows but not elsewhere. -- S. --- ## #72130 — Daniel Lowrey — 2014-02-03T21:45:44+00:00 URL: https://externals.io/message/72100#72130 · In reply to: #72108 > PHP users may now need to have write access to PHP.INI in > order to not get logs filled with security warnings, for thesame > code that previously did not issue a warning. To avoid any confusion, note that the above statement is incorrect. ini_set('openssl.cafile', 'C:\omg\this\is\too\hard.pem'); Source: https://github.com/php/php-src/blob/PHP-5.6/ext/openssl/openssl.c#L1078 Manual entry on where INI directives may be changed: http://www.php.net/manual/en/configuration.changes.modes.php > Or else they need to change all outbound stream > code, which in many cases isn't even theirs to safely change. Then I'm using a garbage library and need to migrate *immediately*. The maintainers don't know the first thing about security and they're putting all of my data at risk. Thank goodness for these warning to alert me that I'm doing something seriously wrong. I definitely didn't know that and I don't want to be left holding the bag when I compromise all my users' personal and sensitive information. Now I can fix it. This is the entire point of warnings: to tell you you're doing something wrong. Suggesting this is somehow harmful is seriously negligent. Let's not pretend like the doctor setting a cast on a broken arm is the problem; the broken arm is the problem. --- ## #72144 — Sanford Whiteman — 2014-02-03T22:17:26+00:00 URL: https://externals.io/message/72100#72144 · In reply to: #72130 > ini_set('openssl.cafile', 'C:\omg\this\is\too\hard.pem'); OK, users simply add ini_set on all their pages. Why bother playacting about this being worth discussing if you actually think it's \just\so\easy\for\any\user? Why start this thread? > > […] > Then I'm using a garbage library and need to migrate *immediately*. Yay! Let's tell people to "migrate immediately" from a WordPress plugin but also act like we didn't affect their PHP user experience in any way. Not even some negative impact for a net good, nope, all positive impact. I think you need to get more experience with the range of third-party code that doesn't turn on verify_peer. And frankly it is PHP's fault that most code doesn't do so, since PHP was insecure by default and never threw an error in the past. Heaping blame on library authors is absurd. If someone is writing to the Twitter API, they might not know anything about CAs, figuring, not entirely unreasonably, that making an outbound connection to https://api.twitter.com would be as verified as it would be from a browser. Furthermore, even if they did have an inkling that their connections weren't best-practices secureit is ridiculously cumbersome to try to bundle a PEM with a lightweight CMS plugin. > This is the entire point of warnings: to tell you you're doing > something wrong. Suggesting this is somehow harmful is seriously > negligent. Let's not pretend like the doctor setting a cast on a > broken arm is the problem; the broken arm is the problem. Of course it's harmful to spew warnings into a log when you damn well you could have worked harder (i.e. bundling the trusted CA bundle) to not have that happen. -- S. --- ## #72146 — Sanford Whiteman — 2014-02-03T22:21:08+00:00 URL: https://externals.io/message/72100#72146 · In reply to: #72144 > it is ridiculously cumbersome to try to bundle a PEM with a > lightweight CMS plugin. Moreover, it may not even be _possible_ to bundle a PEM with plugin code, depending on the distribution/packaging rules for whether your code can be in the CMS's official "app store." -- S. --- ## #72157 — padraic.brady@gmail.com — 2014-02-03T23:41:02+00:00 URL: https://externals.io/message/72100#72157 · In reply to: #72144 Hi, On 3 February 2014 22:17, Sanford Whiteman wrote: > I think you need to get more experience with the range of third-party > code that doesn't turn on verify_peer. And frankly it is PHP's fault > that most code doesn't do so, since PHP was insecure by default and > never threw an error in the past. Heaping blame on library authors is > absurd. If someone is writing to the Twitter API, they might not know I'm sorry, but this is simply outrageous. It is a programmer's responsibility to code securely. It's not absurd, it's reality. If you can't program securely, you shouldn't be programming. This is not some fantasy world where I should pity programmers for their ignorance. It's a world were security flaws can cost companies money, endanger user's privacy and THEIR money, where even minor mistakes can have devastating consequences to privacy and compliance with national and international laws. I fire programmers who can't learn secure coding, but thankfully that's almost unheard of ;). A little training goes a long way. My next favourite excuse is the one where Man-In-The-Middle attacks are rare theoretical occurances and so why bother - a belief in utter defiance of how the internet works. I bet the NSA gets a real chuckle out of that one. What's the next excuse? Right, it's all PHP's fault. Your blaming of PHP is significantly misplaced. It is not solely responsible for programmer malpractice. There are programmers out there, right this moment, with code all across Github doing one very unusual thing. They are deliberately disabling peer verification in cURL where it is enabled by default. They WILL do the same with PHP streams/sockets. The buck stops at the programmer's feet and that's it. All PHP can do is promote and encourage best practices, it can never enforce them. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative --- ## #72158 — Sanford Whiteman — 2014-02-03T23:56:46+00:00 URL: https://externals.io/message/72100#72158 · In reply to: #72157 > I'm sorry, but this is simply outrageous. It is a programmer's > responsibility to code securely. It's not absurd, it's reality. If > you can't program securely, you shouldn't be programming. No, the reality is that (most) PHP users (most of whom are consuming someone else's code to some degree) assume that making an SSL connection means "secure." It is absurd to claim otherwise. In fact, _we are agreeing that that assumption should always have been correct_ by changing the default behavior in PHP! How can you possibly "blame" users and "fix" the behavior at the same time? > Your blaming of PHP is significantly misplaced. No, it is not. If it were, this patch would not exist, for it has ALWAYS been possible to create a peer-verified outbound connection from PHP. You cannot at once place blame only on the developer and make a core change so the language is "the way it should always have been." -- S. --- ## #72159 — Sanford Whiteman — 2014-02-04T00:05:03+00:00 URL: https://externals.io/message/72100#72159 · In reply to: #72157 > Your blaming of PHP is significantly misplaced. It is not solely > responsible for programmer malpractice. There are programmers out > there, right this moment, with code all across Github doing one very > unusual thing. They are deliberately disabling peer verification in > cURL where it is enabled by default. They WILL do the same with PHP > streams/sockets. The buck stops at the programmer's feet and that's > it. All PHP can do is promote and encourage best practices, it can > never enforce them. So you don't agree with this patch? In that case I agree, you are being fully consistent and this standpoint is quite convincing. If we don't touch the language, we can affix blame solely to the user. However my argument assumed the patch was accepted into the language. _In that context_ it is foolish to say the language bears no responsibility while at the same time making language changes so it behaves "the way it should have been." > There are programmers out there, right this moment, with code all > across Github doing one very unusual thing. They are deliberately > disabling peer verification in cURL where it is enabled by default These aren't the programmers who are affected by the changing of defaults. They are fully culpable. -- S. --- ## #72161 — padraic.brady@gmail.com — 2014-02-04T00:29:29+00:00 URL: https://externals.io/message/72100#72161 · In reply to: #72158 Hi, On 3 February 2014 23:56, Sanford Whiteman wrote: > > […] > > No, the reality is that (most) PHP users (most of whom are consuming > someone else's code to some degree) assume that making an SSL > connection means "secure." > > It is absurd to claim otherwise. In fact, _we are agreeing that that > assumption should always have been correct_ by changing the default > behavior in PHP! > > How can you possibly "blame" users and "fix" the behavior at the same > time? Hello. I am a programmer. Sorry, but oopsie, that script I wrote to retrieve client data from our remote office? Well, I sort of forgot to configure SSL correctly and, well, somebody dumped a whole list of client names, emails, social security numbers and other personally identifiable information onto a file dump site. I'm really really sorry. It's all PHP's fault. FIRED! FIRED! FIRED! :P I blame programmers for security problems because it's their fault. Anyone who can't take personal responsibility needs to grow up and own up. Programmers aren't, at least in a professional capacity, children anymore. This whole attitude of avoiding responsibility by pointing fingers at anything else is the one thing that drives security people demented. > > […] > > No, it is not. We'll have to agree to disagree about who gets blamed when hackers strike. > If it were, this patch would not exist, for it has ALWAYS been > possible to create a peer-verified outbound connection from PHP. > > You cannot at once place blame only on the developer and make a core > change so the language is "the way it should always have been." You missed the cURL part of my last email, I presume... -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative --- ## #72162 — Sanford Whiteman — 2014-02-04T00:32:39+00:00 URL: https://externals.io/message/72100#72162 · In reply to: #72161 > I blame programmers for security problems because it's their fault. So do I understand you correctly that you are against this patch? Because as I said I can see your viewpoint as long as you aren't admitting that the language's insecure defaults have anything to do with user behavior. > You missed the cURL part of my last email, I presume... Not at all, but we aren't changing cURL defaults so it's irrelevant. -- Sandy --- ## #72164 — Sanford Whiteman — 2014-02-04T00:36:12+00:00 URL: https://externals.io/message/72100#72164 · In reply to: #72159 Anyway, I think we get off-topic with discussions of those who *knowingly* write insecure code, e.g. manually turning off secure options to save effort. Also think it is unnecessary _in the context of a related language change_ to discuss whether users writing insecure code due to ignorance of PHP's defaults is no excuse, a partial excuse, or a full excuse. All that matters is that the default options were being trusted in the real world by real -- by job description, if not competence -- developers. If it needs to be fixed, we should fix it, but with no extra grudges in the implementation. When we bear a grudge against our own users for "forcing" a language change we leave the doors open for punishing them with the implementation of that change. This is my main argument with Daniel: either we accept that we are breaking people's setups with a change *regardless* of their ultimate responsibility for that change, or we don't make the change. Stating that it's dirt-simple to make such a change is a way of punishing a subset of users who aren't any worse developers than the rest, and perhaps most unfortunately it targets a minority of users who already get the short end of the stick when it comes to extensions, etc., and now will be told that their code is less secure than their *nix counterparts' code -- even though the *nix side is going to get more secure without doing a whit of work. I guess the laissez-faire attitude about Windows users is what sticks in my craw, like they get a bizarre hybrid of respect and disrespect with this patch. -- S. --- ## #72171 — Pierre Joye — 2014-02-04T05:46:47+00:00 URL: https://externals.io/message/72100#72171 · In reply to: #72130 > > […] > > To avoid any confusion, note that the above statement is incorrect. > > ini_set('openssl.cafile', 'C:\omg\this\is\too\hard.pem'); > By the way, I'm not totally sure we should make this setting a user setting but system, like it is now for curl. That being said, I would also suggest to stay on focus, this discussion is getting off base, @sanford. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #72173 — Sanford Whiteman — 2014-02-04T05:58:40+00:00 URL: https://externals.io/message/72100#72173 · In reply to: #72171 > That being said, I would also suggest to stay on focus, this > discussion is getting off base, @sanford. Whatever, nothing else to add. Peer verification was voted in for 5.6 knowing that Windows users would be SOL unless they availed themselves of a CA bundle (and openssl.cafile as INI_ALL). If they can't figure out how to get it they probably shouldn't be developing, it's true. --- ## #72174 — Pierre Joye — 2014-02-04T06:14:43+00:00 URL: https://externals.io/message/72100#72174 · In reply to: #72173 On Tue, Feb 4, 2014 at 6:58 AM, Sanford Whiteman wrote: > > […] > > Whatever, nothing else to add. Peer verification was voted in for 5.6 > knowing that Windows users would be SOL unless they availed themselves > of a CA bundle (and openssl.cafile as INI_ALL). If they can't figure > out how to get it they probably shouldn't be developing, it's true. As I said earlier in this thread we have enough time to evaluate the right solution. We will try not to bundle the CA file until the 1st beta and see what kind of issues testers are experiencing. In any case, a script to fetch it from the curl site should be provided, in the source and binaries releases. This script should be documented in the PHP manual and in the upgrading guide (same for this RFC in general). Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #72178 — Lester Caine — 2014-02-04T07:38:31+00:00 URL: https://externals.io/message/72100#72178 · In reply to: #72174 Pierre Joye wrote: > In any case, a script to fetch it from the curl site should be > provided, in the source and binaries releases. This script should be > documented in the PHP manual and in the upgrading guide (same for this > RFC in general). At the risk of being shouted at as off topic ... This is not the only configuration data that may need managing externally to PHP builds. The tz data is similarly updated outside the PHP build cycles. People are hitting time being wrong more than having a problem with an out of date CA file ... and windows versions of the data tend to lag behind. Security is not the only thing that is reliant nowadays on third party data? -- 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 --- ## #72179 — Pierre Joye — 2014-02-04T07:39:14+00:00 URL: https://externals.io/message/72100#72179 · In reply to: #72178 > Pierre Joye wrote: > > […] > > > At the risk of being shouted at as off topic ... If you know it is off topic (just like the constant rants about notices and other "issues" you run into with legacy codes), why do you post it in the 1st place? That being said, I think we all know your views on these topics. > This is not the only > configuration data that may need managing externally to PHP builds. The tz > data is similarly updated outside the PHP build cycles. People are hitting > time being wrong more than having a problem with an out of date CA file ... > and windows versions of the data tend to lag behind. > Security is not the > only thing that is reliant nowadays on third party data? We bundle the TZ data and it is used on all supported platforms. So no, no platform lags behind other. Some distributions may patch the date extension to use the system TZ but then it is none of our business. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #72181 — Lester Caine — 2014-02-04T07:57:24+00:00 URL: https://externals.io/message/72100#72181 · In reply to: #72179 Pierre Joye wrote: > > […] > We bundle the TZ data and it is used on all supported platforms. So > no, no platform lags behind other. Some distributions may patch the > date extension to use the system TZ but then it is none of our > business. But that is the whole point here ... it's the same argument with CA file? -- 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 --- ## #72182 — Pierre Joye — 2014-02-04T08:00:12+00:00 URL: https://externals.io/message/72100#72182 · In reply to: #72181 > Pierre Joye wrote: > > […] > > > But that is the whole point here ... it's the same argument with CA file? If someone distributes a patched PHP, it is none of our business. And CA file on Windows is not the same issue as Windows do not have system CA files compatible with OpenSSL. Implementing a backend using windows keys store and SSL APIs would bring more issues and incompatibilities (user lever) than asking users to set an ini setting. --- ## #72184 — Lester Caine — 2014-02-04T08:29:53+00:00 URL: https://externals.io/message/72100#72184 · In reply to: #72182 Pierre Joye wrote: > > > […] > > If someone distributes a patched PHP, it is none of our business. > > And CA file on Windows is not the same issue as Windows do not have > system CA files compatible with OpenSSL. Implementing a backend using > windows keys store and SSL APIs would bring more issues and > incompatibilities (user lever) than asking users to set an ini > setting. OK that is making sense. The only reason that the tz data sprang to mind is a similar situation. Up until now windows has also had it's own timezone data management, so was not compatible with tz, but it seems from information being received that newer versions of windows are now using the tz data itself as it was their data which was lagging behind the real world. Linux distributions do update their tz data, but windows installs of PHP can't take advantage of the same update path? Just like the CA files. It's PHP distributing the 'patched' windows builds here? -- 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 --- ## #72185 — Pierre Joye — 2014-02-04T08:35:19+00:00 URL: https://externals.io/message/72100#72185 · In reply to: #72184 > > OK that is making sense. The only reason that the tz data sprang to mind is a similar situation. Up until now windows has also had it's own timezone data management, This statement and the rest of your mail are wrong. Again Php TZ data always have been built in, be on windows or other platforms. > It's PHP distributing the 'patched' windows builds here? No and no need to either. --- Next page: https://externals.io/message/72100.md?page=2