PHP Implementation?

[paragonie-scott]

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.

[cryptosubtlety]

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

[paragonie-scott]

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

[ladyisatis]

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

[thaidn]

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]

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]

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]

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 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]

@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]

@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]

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

[ondrejmirtes]

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]

@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]

@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]

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]

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]

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 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.

[cryptosubtlety]

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]

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.

[cryptosubtlety]

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

[itAsia]

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]

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!

[stamster]

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 is why we ban PHP at Google.

Nice!

[pakalbekim]

Guys, is there any development on supporting PHP? I haven't found any repos or docs related to that, is it still where it was in Sep 2018? Any pointers would be greatly appreciated.

[afk11]

@pakalbekim I'd say yeah, pretty much, except that now we have ffi in PHP!

thaidns last words on this:

we want to support PHP, but we need help from the community.

IMO we could get this moving quite easily. First, add C support to the project (tink is written in c++ and uses objects). No crypto code, just write a C function taking an object pointer and the other args for every object method.

Then we'd have a few options - PHP's recent support of the FFI means you could write a script interacting with the library, or we can write a PHP extension that mirrors the C interface.

Both these options expose all of tinks features in PHP, and without having to port every upstream code change into PHP.

I've just opened an issue for this #202