New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHP Implementation? #104

Closed
paragonie-scott opened this Issue Aug 30, 2018 · 25 comments

Comments

Projects
None yet
@paragonie-scott

paragonie-scott commented Aug 30, 2018

I intend to follow this up with a pull request.

Would the Tink team be interested in a PHP implementation of the same API? Obtensibly it would wrap both the openssl and sodium extensions.

@quannguyentm

This comment has been minimized.

Show comment
Hide comment
@quannguyentm

quannguyentm Aug 30, 2018

Contributor

There are several security concerns with PHP in general, so we won't support it.

Contributor

quannguyentm commented Aug 30, 2018

There are several security concerns with PHP in general, so we won't support it.

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Aug 30, 2018

  1. Which security concerns are you referring to, specifically?
  2. I'll support it, in a separate repository if need be.

paragonie-scott commented Aug 30, 2018

  1. Which security concerns are you referring to, specifically?
  2. I'll support it, in a separate repository if need be.
@Reverite

This comment has been minimized.

Show comment
Hide comment
@Reverite

Reverite Aug 30, 2018

I agree. I'd rather there be a longer explanation for what security concerns there could possibly be with the language?

Reverite commented Aug 30, 2018

I agree. I'd rather there be a longer explanation for what security concerns there could possibly be with the language?

@thaidn thaidn reopened this Aug 30, 2018

@thaidn

This comment has been minimized.

Show comment
Hide comment
@thaidn

thaidn Aug 30, 2018

Collaborator

I think we'd support PHP if there's enough interest and some help from the community.

At the moment PHP is not our priority, but if someone can step up and own it we can help with design/code review. I think PHP support can be built on top of our C++ library.

Collaborator

thaidn commented Aug 30, 2018

I think we'd support PHP if there's enough interest and some help from the community.

At the moment PHP is not our priority, but if someone can step up and own it we can help with design/code review. I think PHP support can be built on top of our C++ library.

@thaidn

This comment has been minimized.

Show comment
Hide comment
@thaidn

thaidn Aug 30, 2018

Collaborator

Re security concerns with PHP: PHP has been affected by hundreds of vulnerabilities (see http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74). Also coding in PHP (especially without a modern framework) has countless pitfalls/traps due to different PHP quirks - it's really easy to introduce a vulnerability into your code.

This is why we ban PHP at Google. We recommend switching to less error-prone languages like Java or Go. If you have to use PHP, you should hire a security engineer to help you harden your config and review your code.

Collaborator

thaidn commented Aug 30, 2018

Re security concerns with PHP: PHP has been affected by hundreds of vulnerabilities (see http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74). Also coding in PHP (especially without a modern framework) has countless pitfalls/traps due to different PHP quirks - it's really easy to introduce a vulnerability into your code.

This is why we ban PHP at Google. We recommend switching to less error-prone languages like Java or Go. If you have to use PHP, you should hire a security engineer to help you harden your config and review your code.

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Aug 31, 2018

I think we'd support PHP if there's enough interest and some help from the community.

At the moment PHP is not our priority, but if someone can step up and own it we can help with design/code review. I think PHP support can be built on top of our C++ library.

Great, thank you. I'll introduce the idea to a few of my friends and colleagues and see about the best way to get this done. Considering support for Python is already planned, PHP support is a great way to get your library readily into the hands of developers.

Re security concerns with PHP: PHP has been affected by hundreds of vulnerabilities (see http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74).

I don't think this is as strong of a reason as it might seem, at a glance.

In this year (2018), there were 11 vulnerabilities disclosed, affecting:

  • EXIF functions
  • LDAP functions
  • Serving a web application from a PHP Archive (Phar file)
  • The iconv extension
  • The GD extension
  • Local process memory management (which could be a problem on shared hosting).

None of those really scream "if you're running PHP-- regardless of what your scripts are actually doing-- you're vulnerable". Most of them were in niche extensions.

Also coding in PHP (especially without a modern framework) has countless pitfalls/traps due to different PHP quirks - it's really easy to introduce a vulnerability into your code.

Oh, definitely. Hard agree on this point. This is, unfortunately, true of most languages.

Improving the security of the PHP ecosystem is a particular hobby horse of mine. (Explained in detail here.)

This is why we ban PHP at Google. We recommend switching to less error-prone languages like Java or Go.

Yeah, so...

In this same year (2018), Java had 43 vulnerabilities and Go had a sev >= 9.0 bug.

Java beats PHP in the raw number of vulnerabilities-- both overall (PHP: 569, Java: 586) and in the past year (11 vs 43). Go's sev:hi was higher than any PHP bug in the same calendar year.

My point is: If we're using CVE statistics as the metric by which to judge a language (and determine whether or not to ban it), without context, Java isn't really a good recommendation. And if we're using the most severe vulnerabilities (which is an alternate way of interpreting the data) as a measuring stick, Go looks really bad.

In my opinion, the past year (or two years, depending on the pace of development) is far more insightful into the quality of software than its total CVE history in perpetuity. A project with a rocky start can still end up being secure; holding past mistakes against it forever is just... ignorant, really.

It's also important to evaluate these vulnerabilities in context. Most of the PHP vulnerabilities were in extensions that hardly anyone uses. (This is still important if you're using third party dependencies that might surprise you by using it.)

If Google has some privileged and up-to-date knowledge (i.e. affecting 7.2 and 7.3) about security flaws in PHP's design that would motivate an ongoing initiative to steer developers away from this language, I'd love to hear about them, so that they can be fixed. After all, arguably way too much software runs PHP, so the entire Internet would benefit from shoring up its security.

If you have to use PHP, you should hire a security engineer to help you harden your config and review your code.

I don't think config hardening is really important to PHP security. That's what people used to say in the early 2000's, but it was mostly blogs reposting mild alterations of the same tired advice from the days of register_globals (and I don't think critical thinking really entered the equation for that particular earworm), but 99% of it comes down to:

  1. Keeping your third-party dependencies up-to-date.
  2. Not writing trivially vulnerable code (e.g. prepared statements instead of brittle escape-n-concatenate strategies).

n.b. I wrote a thorough guide on this topic late last year: https://paragonie.com/blog/2017/12/2018-guide-building-secure-php-software

paragonie-scott commented Aug 31, 2018

I think we'd support PHP if there's enough interest and some help from the community.

At the moment PHP is not our priority, but if someone can step up and own it we can help with design/code review. I think PHP support can be built on top of our C++ library.

Great, thank you. I'll introduce the idea to a few of my friends and colleagues and see about the best way to get this done. Considering support for Python is already planned, PHP support is a great way to get your library readily into the hands of developers.

Re security concerns with PHP: PHP has been affected by hundreds of vulnerabilities (see http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74).

I don't think this is as strong of a reason as it might seem, at a glance.

In this year (2018), there were 11 vulnerabilities disclosed, affecting:

  • EXIF functions
  • LDAP functions
  • Serving a web application from a PHP Archive (Phar file)
  • The iconv extension
  • The GD extension
  • Local process memory management (which could be a problem on shared hosting).

None of those really scream "if you're running PHP-- regardless of what your scripts are actually doing-- you're vulnerable". Most of them were in niche extensions.

Also coding in PHP (especially without a modern framework) has countless pitfalls/traps due to different PHP quirks - it's really easy to introduce a vulnerability into your code.

Oh, definitely. Hard agree on this point. This is, unfortunately, true of most languages.

Improving the security of the PHP ecosystem is a particular hobby horse of mine. (Explained in detail here.)

This is why we ban PHP at Google. We recommend switching to less error-prone languages like Java or Go.

Yeah, so...

In this same year (2018), Java had 43 vulnerabilities and Go had a sev >= 9.0 bug.

Java beats PHP in the raw number of vulnerabilities-- both overall (PHP: 569, Java: 586) and in the past year (11 vs 43). Go's sev:hi was higher than any PHP bug in the same calendar year.

My point is: If we're using CVE statistics as the metric by which to judge a language (and determine whether or not to ban it), without context, Java isn't really a good recommendation. And if we're using the most severe vulnerabilities (which is an alternate way of interpreting the data) as a measuring stick, Go looks really bad.

In my opinion, the past year (or two years, depending on the pace of development) is far more insightful into the quality of software than its total CVE history in perpetuity. A project with a rocky start can still end up being secure; holding past mistakes against it forever is just... ignorant, really.

It's also important to evaluate these vulnerabilities in context. Most of the PHP vulnerabilities were in extensions that hardly anyone uses. (This is still important if you're using third party dependencies that might surprise you by using it.)

If Google has some privileged and up-to-date knowledge (i.e. affecting 7.2 and 7.3) about security flaws in PHP's design that would motivate an ongoing initiative to steer developers away from this language, I'd love to hear about them, so that they can be fixed. After all, arguably way too much software runs PHP, so the entire Internet would benefit from shoring up its security.

If you have to use PHP, you should hire a security engineer to help you harden your config and review your code.

I don't think config hardening is really important to PHP security. That's what people used to say in the early 2000's, but it was mostly blogs reposting mild alterations of the same tired advice from the days of register_globals (and I don't think critical thinking really entered the equation for that particular earworm), but 99% of it comes down to:

  1. Keeping your third-party dependencies up-to-date.
  2. Not writing trivially vulnerable code (e.g. prepared statements instead of brittle escape-n-concatenate strategies).

n.b. I wrote a thorough guide on this topic late last year: https://paragonie.com/blog/2017/12/2018-guide-building-secure-php-software

@SecondeJK

This comment has been minimized.

Show comment
Hide comment
@SecondeJK

SecondeJK Aug 31, 2018

For the one of the most commonly used server side languages on the planet, I think stating "several security concerns in general" and closing isn't really good enough. I get that you don't like it, but lots of other people do, and you're effectively saying get lost and learn something else which isn't too nice to read.

SecondeJK commented Aug 31, 2018

For the one of the most commonly used server side languages on the planet, I think stating "several security concerns in general" and closing isn't really good enough. I get that you don't like it, but lots of other people do, and you're effectively saying get lost and learn something else which isn't too nice to read.

@pwaring

This comment has been minimized.

Show comment
Hide comment
@pwaring

pwaring Aug 31, 2018

This is why we ban PHP at Google.

Is that official Google policy or your personal opinion? Google seems to have actively maintained PHP projects under its GitHub organisation:

https://github.com/google?language=php

pwaring commented Aug 31, 2018

This is why we ban PHP at Google.

Is that official Google policy or your personal opinion? Google seems to have actively maintained PHP projects under its GitHub organisation:

https://github.com/google?language=php

@thaidn

This comment has been minimized.

Show comment
Hide comment
@thaidn

thaidn Aug 31, 2018

Collaborator

@pwaring we don't use PHP in production, but we understand that PHP is an important language with a large user base, so we still provide libraries and frameworks that help people use PHP correctly. This is why we want to support PHP in Tink.

Collaborator

thaidn commented Aug 31, 2018

@pwaring we don't use PHP in production, but we understand that PHP is an important language with a large user base, so we still provide libraries and frameworks that help people use PHP correctly. This is why we want to support PHP in Tink.

@thaidn

This comment has been minimized.

Show comment
Hide comment
@thaidn

thaidn Aug 31, 2018

Collaborator

@paragonie-scott thanks Scott, that's very useful.

I have to admit that because Google doesn't use PHP, my PHP knowledge is quite outdated and limited. I based my comment on an internal resource, I'd asked the author to comment. Hopefully they'd have cycles to chime in.

I agree that it's possible to build secure applications in any languages. What matters is the availability of good frameworks, libraries, and tooling. This is why I fully support Tink for PHP.

Collaborator

thaidn commented Aug 31, 2018

@paragonie-scott thanks Scott, that's very useful.

I have to admit that because Google doesn't use PHP, my PHP knowledge is quite outdated and limited. I based my comment on an internal resource, I'd asked the author to comment. Hopefully they'd have cycles to chime in.

I agree that it's possible to build secure applications in any languages. What matters is the availability of good frameworks, libraries, and tooling. This is why I fully support Tink for PHP.

@thaidn

This comment has been minimized.

Show comment
Hide comment
@thaidn

thaidn Aug 31, 2018

Collaborator

@SecondeJK I can't speak for @quannguyentm, but on behalf of Tink team I confirm that we want to support PHP.

Collaborator

thaidn commented Aug 31, 2018

@SecondeJK I can't speak for @quannguyentm, but on behalf of Tink team I confirm that we want to support PHP.

@ondrejmirtes

This comment has been minimized.

Show comment
Hide comment
@ondrejmirtes

ondrejmirtes Aug 31, 2018

PHP is a really great language and in recent versions you can achieve the same code quality as in the other languages you mentioned.

ondrejmirtes commented Aug 31, 2018

PHP is a really great language and in recent versions you can achieve the same code quality as in the other languages you mentioned.

@SecondeJK

This comment has been minimized.

Show comment
Hide comment
@SecondeJK

SecondeJK Aug 31, 2018

@thaidn Thanks for the sensible response. If it's tricky, I get it, if you don't use it I get it, but surely we've all learned that in OSS you can't just say "No, bye"

SecondeJK commented Aug 31, 2018

@thaidn Thanks for the sensible response. If it's tricky, I get it, if you don't use it I get it, but surely we've all learned that in OSS you can't just say "No, bye"

@afk11

This comment has been minimized.

Show comment
Hide comment
@afk11

afk11 Aug 31, 2018

@thaidn Swig handles using C++ code directly from what I can tell. Otherwise, the extension could be written by hand against a C interface for tink.

The downside is extensions aren't friendly for people using shared hosts, hence polyfills are likely unavoidable. So I think @paragonie-scott's suggestion is valuable in this context.

afk11 commented Aug 31, 2018

@thaidn Swig handles using C++ code directly from what I can tell. Otherwise, the extension could be written by hand against a C interface for tink.

The downside is extensions aren't friendly for people using shared hosts, hence polyfills are likely unavoidable. So I think @paragonie-scott's suggestion is valuable in this context.

@J7mbo

This comment has been minimized.

Show comment
Hide comment
@J7mbo

J7mbo Aug 31, 2018

surely we've all learned that in OSS you can't just say "No, bye"

In OSS, it's entirely "allowed" to say "No, bye". OS maintainers do not owe you anything. You are using their software free of charge and are also free not to / fork it.

Great to see the Google guys increasing their awareness of the modern PHP landscape 👍

J7mbo commented Aug 31, 2018

surely we've all learned that in OSS you can't just say "No, bye"

In OSS, it's entirely "allowed" to say "No, bye". OS maintainers do not owe you anything. You are using their software free of charge and are also free not to / fork it.

Great to see the Google guys increasing their awareness of the modern PHP landscape 👍

@itAsia

This comment has been minimized.

Show comment
Hide comment
@itAsia

itAsia Aug 31, 2018

It’s a shame to read such non sense from a Google official. PHP hasn’t more vulnerability than C , python or any other. Problems can come from the usage, not from the language itself. As we have almost the largest community of developer, you cannot criticize the problems coming from non skilled programmers and put it on everyone. Are you really a graduated engineer, and do you really think what you just wrote ???????

itAsia commented Aug 31, 2018

It’s a shame to read such non sense from a Google official. PHP hasn’t more vulnerability than C , python or any other. Problems can come from the usage, not from the language itself. As we have almost the largest community of developer, you cannot criticize the problems coming from non skilled programmers and put it on everyone. Are you really a graduated engineer, and do you really think what you just wrote ???????

@nhlm

This comment has been minimized.

Show comment
Hide comment
@nhlm

nhlm Sep 1, 2018

So you measure the security of a entire language by its vulnerabilities count at CVEDetails? PHP is the only language entirely available to almost every hosting provider at this globe. Vulnerabilities are easily gathered when you have such a wide spreading availability.

The security a language could (and should provide) is limited and it has to be this way. A language that implements close to everything to protect developers against vulnerabilities which may result from their code is a over-protective approach and will earlier or sooner become a language with a slow evolution. Security first on language level is a misconception from my point of view, no widely used language does this in general (C, C++, C#, Java, JavaScript, ...).

Implementing secure applications is the duty of the developer who makes use of languages, frameworks and libraries. If a concrete vulnerability is the result of a bug at language level, it will be solved quickly in case of PHP. In general faster than Google solves issues.

PHP is an environment which grants a lot of secure components, extensions and libaries. If developers aren't able to implement their applications with a sense of security, it will not be PHPs fault.

nhlm commented Sep 1, 2018

So you measure the security of a entire language by its vulnerabilities count at CVEDetails? PHP is the only language entirely available to almost every hosting provider at this globe. Vulnerabilities are easily gathered when you have such a wide spreading availability.

The security a language could (and should provide) is limited and it has to be this way. A language that implements close to everything to protect developers against vulnerabilities which may result from their code is a over-protective approach and will earlier or sooner become a language with a slow evolution. Security first on language level is a misconception from my point of view, no widely used language does this in general (C, C++, C#, Java, JavaScript, ...).

Implementing secure applications is the duty of the developer who makes use of languages, frameworks and libraries. If a concrete vulnerability is the result of a bug at language level, it will be solved quickly in case of PHP. In general faster than Google solves issues.

PHP is an environment which grants a lot of secure components, extensions and libaries. If developers aren't able to implement their applications with a sense of security, it will not be PHPs fault.

@gsdevme

This comment has been minimized.

Show comment
Hide comment
@gsdevme

gsdevme Sep 2, 2018

This is why we ban PHP at Google.

There are several security concerns with PHP in general, so we won't support it.

I based my comment on an internal resource

Disappointing to see such nonsense is being distributed within Google. Sounds like out of date information but as with all languages vulnerabilities normally exist because of humans, they put the bugs in.. and no language is immune to that.

I would've thought Google would be on the cutting edge of all languages although its clear from the PHP Google do write that is published that it's outdated in it's language features and support.

I'm sure Google employees are using PHP based websites throughout daily life including giving personal information out even given this "everything php is a security risk" motto.

gsdevme commented Sep 2, 2018

This is why we ban PHP at Google.

There are several security concerns with PHP in general, so we won't support it.

I based my comment on an internal resource

Disappointing to see such nonsense is being distributed within Google. Sounds like out of date information but as with all languages vulnerabilities normally exist because of humans, they put the bugs in.. and no language is immune to that.

I would've thought Google would be on the cutting edge of all languages although its clear from the PHP Google do write that is published that it's outdated in it's language features and support.

I'm sure Google employees are using PHP based websites throughout daily life including giving personal information out even given this "everything php is a security risk" motto.

@quannguyentm

This comment has been minimized.

Show comment
Hide comment
@quannguyentm

quannguyentm Sep 3, 2018

Contributor

itAsia@ Are you really a graduated engineer, and do you really think what you just wrote ???????

You’d better hope that I’ve graduated because I contributed to several critical security code in Tink. Just to give you an idea of my work:

  1. I spent an intensive unsung effort to review Ed25519 code written by another contributor when the code was only at @Alpha phase.
    a) One of the issues I found & fixed is this one d4665a4.
    Exercise for the readers: this bug allowed attackers to extract the private key by only 2 signatures.
    b) If a) is difficult, try to solve a simplified version in my Google CTF final challenge 2017 https://github.com/google/google-ctf/blob/master/2017/finals/2017-finals-crypto-ed25519finalchallenge/attachments/Ed25519Final.java
  2. I implemented PKCS1 from scratch 4828a81 because old Java version is vulnerable, and we wanted to protect user even with old Java version.
  3. I added a majority of Wycheproof tests to Tink to protect its security.

What I meant is it took Tink developers a long time in writing code, careful reviewing its security and testing it until this “official” release, so it’s not nice being insulted like this.

It’s fine to criticize my statement, right or wrong. I take the heat and I’m willing to learn anything new related to security. However, I have no tolerance to insults/personal attack.

Contributor

quannguyentm commented Sep 3, 2018

itAsia@ Are you really a graduated engineer, and do you really think what you just wrote ???????

You’d better hope that I’ve graduated because I contributed to several critical security code in Tink. Just to give you an idea of my work:

  1. I spent an intensive unsung effort to review Ed25519 code written by another contributor when the code was only at @Alpha phase.
    a) One of the issues I found & fixed is this one d4665a4.
    Exercise for the readers: this bug allowed attackers to extract the private key by only 2 signatures.
    b) If a) is difficult, try to solve a simplified version in my Google CTF final challenge 2017 https://github.com/google/google-ctf/blob/master/2017/finals/2017-finals-crypto-ed25519finalchallenge/attachments/Ed25519Final.java
  2. I implemented PKCS1 from scratch 4828a81 because old Java version is vulnerable, and we wanted to protect user even with old Java version.
  3. I added a majority of Wycheproof tests to Tink to protect its security.

What I meant is it took Tink developers a long time in writing code, careful reviewing its security and testing it until this “official” release, so it’s not nice being insulted like this.

It’s fine to criticize my statement, right or wrong. I take the heat and I’m willing to learn anything new related to security. However, I have no tolerance to insults/personal attack.

@Majkl578

This comment has been minimized.

Show comment
Hide comment
@Majkl578

Majkl578 Sep 3, 2018

I spent an intensive unsung effort to review Ed25515 code

I think you mean Ed25519, or is Google about to publish new ECC curve?

What I meant is it took Tink developers a long time in writing code, careful reviewing its security and testing it until this “official” release

That's of course appriciated and also the reason why someone requested a port to PHP. 👍

What I meant is it took Tink developers a long time in writing code, careful reviewing its security and testing it until this “official” release, so it’s not nice being insulted like this.

It's not nice being insulted (being a PHP developer myself) like:

There are several security concerns with PHP in general, so we won't support it.

And closed feature request immediately without discussion.

However, I have no tolerance to insults.

I think you are not the only one, that's the reason why this issue got so much attention in just few days.

Majkl578 commented Sep 3, 2018

I spent an intensive unsung effort to review Ed25515 code

I think you mean Ed25519, or is Google about to publish new ECC curve?

What I meant is it took Tink developers a long time in writing code, careful reviewing its security and testing it until this “official” release

That's of course appriciated and also the reason why someone requested a port to PHP. 👍

What I meant is it took Tink developers a long time in writing code, careful reviewing its security and testing it until this “official” release, so it’s not nice being insulted like this.

It's not nice being insulted (being a PHP developer myself) like:

There are several security concerns with PHP in general, so we won't support it.

And closed feature request immediately without discussion.

However, I have no tolerance to insults.

I think you are not the only one, that's the reason why this issue got so much attention in just few days.

@quannguyentm

This comment has been minimized.

Show comment
Hide comment
@quannguyentm

quannguyentm Sep 3, 2018

Contributor

Right, it's Ed25519, my typo. Edited.

Contributor

quannguyentm commented Sep 3, 2018

Right, it's Ed25519, my typo. Edited.

@itAsia

This comment has been minimized.

Show comment
Hide comment
@itAsia

itAsia Sep 3, 2018

I have certainly no diplomacy talent, but I know this one :
“Don't do unto others what you don't want done unto you.” (Confucius)
And reading the answers, I remember that one as well : "Think Before You Speak".
Ego will bring you nowhere.
Period.

itAsia commented Sep 3, 2018

I have certainly no diplomacy talent, but I know this one :
“Don't do unto others what you don't want done unto you.” (Confucius)
And reading the answers, I remember that one as well : "Think Before You Speak".
Ego will bring you nowhere.
Period.

@thaidn

This comment has been minimized.

Show comment
Hide comment
@thaidn

thaidn Sep 3, 2018

Collaborator

Hey folks,

Let's calm down. Instead of throwing words against one another, let's build something together.

I want to repeat one more time: we want to support PHP, but we need help from the community. Since we have no PHP programmer in the team, we need a group of volunteers. To not slow down the development of existing languages, I propose creating a separate repo for PHP.

If any of you wants to lead this effort, please drop me a line at thaidn@google.com. I'll loop in the right folks in our security team that can help with PHP security. Of course we Tink maintainers would help with the crypto part.

The conclusion of this bug has been reached and therefore I'm going to close it. Thanks everyone for a very passionate discussion. I've learned a lot!

Collaborator

thaidn commented Sep 3, 2018

Hey folks,

Let's calm down. Instead of throwing words against one another, let's build something together.

I want to repeat one more time: we want to support PHP, but we need help from the community. Since we have no PHP programmer in the team, we need a group of volunteers. To not slow down the development of existing languages, I propose creating a separate repo for PHP.

If any of you wants to lead this effort, please drop me a line at thaidn@google.com. I'll loop in the right folks in our security team that can help with PHP security. Of course we Tink maintainers would help with the crypto part.

The conclusion of this bug has been reached and therefore I'm going to close it. Thanks everyone for a very passionate discussion. I've learned a lot!

@thaidn thaidn closed this Sep 3, 2018

@stamster

This comment has been minimized.

Show comment
Hide comment
@stamster

stamster Sep 4, 2018

I remember Microsoft folks speaking with similar tone towards F/OSS in general, some 10 years ago. They made jokes and said that it is kids playground they don't want to get involved being a "big serious" vendor.

But these days we see their appreciation of OSS. They are integrating some large portions of the OSS into their own products, which was a big surprise for everyone, even them :)
But things they change, and they realized that such 'enterprisey' attitude is driving them nowhere.

This topic and responses from Google devs about PHP in 2018. reminds me of such scenarios. :)

Cheers

stamster commented Sep 4, 2018

I remember Microsoft folks speaking with similar tone towards F/OSS in general, some 10 years ago. They made jokes and said that it is kids playground they don't want to get involved being a "big serious" vendor.

But these days we see their appreciation of OSS. They are integrating some large portions of the OSS into their own products, which was a big surprise for everyone, even them :)
But things they change, and they realized that such 'enterprisey' attitude is driving them nowhere.

This topic and responses from Google devs about PHP in 2018. reminds me of such scenarios. :)

Cheers

@marufmax

This comment has been minimized.

Show comment
Hide comment
@marufmax

marufmax Sep 15, 2018

This is why we ban PHP at Google.

Nice!

marufmax commented Sep 15, 2018

This is why we ban PHP at Google.

Nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment