PHP Becomes First Programming Language To Add 'Modern' Cryptography Library In Its Core (bleepingcomputer.com)

An anonymous reader writes from a report via BleepingComputer: The PHP team has unanimously voted to integrate the Libsodium library in the PHP core, and by doing so, becoming the first programming language to support a modern cryptography library by default. Developers approved a proposal with a vote of 37 to 0 and decided that Libsodium will be added to the upcoming PHP 7.2 release that will be launched towards the end of 2017. Scott Arciszewski, the cryptography expert who made the proposal, says that by supporting modern crypto in the PHP core, the PHP team will force the WordPress team to implement better security in its CMS, something they avoided until now. Additionally, it will allow PHP and CMS developers to add advanced cryptography features to their apps that run on shared hosting providers, where until now they weren't able to install custom PHP extensions to support modern cryptography. Other reasons on why he made the proposal are detailed here. Arciszewski also says that PHP is actually "the first" programming language to support a "modern" cryptography library in its core, despite Erlang and Go including similar libraries, which he claims are not as powerful and up-to-date as PHP's upcoming Libsodium implementation.

Comments

Oh please

[Anonymous Coward]

Any language where the default equality comparison operator is *true* given two string-type variables with values "0E54321" and "0E12345" is not a cryptographically secure language. In fact there is a nonzero chance of the default equality operator returning true between two different MD5 or SHA256 hashes if they happen to fall into a hexadecimal form that is all digits except for one E or F.

Anyone who claims that PHP is somehow more secure as a language because it has added *new optional library calls* without doing anything about the fundamental language defects is demented.

Re:Oh please

[Vairon]

PHP has a comparison operator === that evaluates if the two things it is comparing are equal and of the same type.

$ php -r "if (\"0E54321\" === \"0E12345\") { echo 'equal'; } else { echo 'not equal'; } "
not equal

Without ===, variable type conversion can cause a string containing numbers to be converted to an integer. See these links for details:

http://php.net/manual/en/langu...
http://php.net/manual/en/langu...

Re:Oh please

[Lisandro]

Except for objects, where a === b is true only if a and b are the same object. Such a beautifully designed language.

Re:Oh please

[Dogtanian]

Any language where the default equality comparison operator is *true* given two string-type variables with values "0E54321" and "0E12345" is not a cryptographically secure language. In fact there is a nonzero chance of the default equality operator returning true between two different MD5 or SHA256 hashes if they happen to fall into a hexadecimal form that is all digits except for one E or F.

Technically, that (in itself) doesn't necessarily mean that the built-in cryptography nor the language itself are inherently insecure. In theory, that is, provided you understand the language and use it correctly.

And that's the problem. Because in practice, PHP's design philosophy of trying to be clever- often too clever by half- when it comes to comparisons, equality, automatic coercion, data types, etc. etc. too often gives unpredictable and unexpected results from people who weren't aware of that behaviour.

You absolutely do *not* want any risk of this happening when you're designing a system that has to be secure. You want boringly explicit and utterly predictable data and type handling.

My prediction is that far, *far* more security holes will be down to bugs caused by unforeseen subtle aspects- i.e. pitfalls- of PHP's type handling and equality behaviour (etc.) in the apps using it rather than bugs in the cryptographic module itself.

PHP being a language more favoured by inexperienced users, this is likely to be made far worse. Expect lots of newbies with misplaced confidence designing what they think are "secure" apps that are in fact full of holes- either because they've misused or misunderstood the cryptographic module, or because they've overlooked some basic aspect of computer security elsewhere (e.g. failure to parse input securely) that makes the use of cryptography irrelevant.

And those are the sorts of mistakes newbies would make when using any language- with PHP's language design issues on top of that, it has the potential to be far worse.

So, yeah. I trust that the module will be secure. The main problems- I guarantee- will be caused by caused by overlooked (or not known about) aspects of PHP's too-clever-by-half data handling (in client apps using it) leading to exploitable holes, and by the fact that too many of PHP's newbie-skewing userbase will overconfidently assume it makes their apps foolproof while using it incorrectly and ignoring security holes elsewhere that make it redundant.

Re:Oh please

[deKernel]

Please tell me you are kidding me on this? I haven't touched PHP so this is all new to me...if it is true.

Re:Oh please

[Lisandro]

Oh, how i wish i was: https://developers.slashdot.or...

Re:Oh please

[hcs_$reboot]

Except for objects, where a === b is true only if a and b are the same object

In Java, a == b is true if a and b references are identical, which is probably what does PHP under the hood.

Re:Oh please

[hcs_$reboot]

even the double equals of C is one of the least "beautiful" design decisions ever made.

It's not because some not so good programmers confuse '=' with '==' that '==' is not "beautiful". On the contrary, I think this is one of the many genius ideas K&R had at the time ('a = b', 'a == b'... think about it!)

Re:Oh please

[JustAnotherOldGuy]

Without ===, variable type conversion can cause a string containing numbers to be converted to an integer.

Yep, and as much as I like php, I'll be the first to say that php's "converting a string to an integer" as a default behavior is idiotic. It's just an accident waiting to happen.

Re:Oh please

[Anonymous Coward]

Came for the PHP haters, was not disappointed.

Re:Oh please

[Ksevio]

I can get a segfault pretty reliably in C with this code:
char *s = "hello world"; *s = 'H';

Re:Oh please

[fahrbot-bot]

PHP has a comparison operator === that evaluates if the two things it is comparing are equal and of the same type.

The next version will support "====" for things are really, *really* equal.

Re: Oh please

[Edgewize]

Or more relevantly, I think this is what the original poster was referring to:
https://www.whitehatsec.com/bl...

Here are some examples of PHP doing mind boggling things with md5 and sha1 hashes.

https://3v4l.org/tT4l8

Re:Oh please

[Lisandro]

I think you meant s = 'H'; there....

But again, this is to be expected. C is a low level language without memory management; PHP is neither. There is no sane reason why it is supposed to segfault (according to the developers, "infinite recursion crashes") and i'm not aware of any other high level language which does the same. How hard is to add a recursion counter?

Re:Oh please

[sconeu]

It was needed for Animal Farm Simulation support, because some objects are more equal than others.

Re:Oh please

[Anonymous Coward]

Funny how the rest of the languages out there which do type conversion manage to avoid this shit: http://phpsadness.com/static/p...

Re:Oh please

[goose-incarnated]

I think you meant s = 'H'; there....

No, he is correct that *s = 'H' can segfault. You aren't allowed to modify string literals, only char arrays.

Re:Oh please

[mysticgoat]

To repeat: quit blaming the language for the lack of skills of the programmer.

Programmers who are incompetent in PHP should not attempt to build secure systems with it. Those who do attempt to do so should really not be involved in making secure systems in any language, since they have demonstrated that they do not know how to assess the limitations of their tools, let alone work properly within those limitations.

It is a poor craftsman who blames his tools for his shoddy workmanship.

Re: Oh please

[p91paul]

Object comparison is not easy, you have to compare every field and if fields are objects, compare their fields and so on. And I did not take into account recursive objects, where an object contains a reference to itself, either directly or through a contained object. Nor thread safety: what should happen if an object is modified while the comparison (which is at this point not atomic) occurs? Hiding all that in a == would be very bad. And well, objects are pointers, so with == you are comparing them (if you think about it this way, you see that when passing parameters to functions, objects, like primitive types, are passed by value since their pointer is passed by value)

Re:Oh please

[gweihir]

It is a sign of very junior and inexperienced language designers with very big egos. And no concept of personal responsibility.

Writing good code is hard enough with good tools.

Re:Oh please

[gweihir]

And there we have the core problem: Clueless language designers with big egos. A segfault is like scramming a reactor. It is an absolute least resort, it may do significant damage, it is always a sign of something having gone terribly wrong and it should never, ever happen in normal operation.

Re:Oh please

[gweihir]

C is not an interpreted language with memory safety.Your example does not apply and it is completely clueless in addition.

Re:Oh please

[gweihir]

Because modifying string _constants_ is a bad idea?

Re:Oh please

[gweihir]

It is a poor craftsman that uses shoddy tools in the first place. Selecting good tools is a core skill for any craftsman. Those that do not have it will never amount to anything.

Re:Oh please

[TheRaven64]

That's pretty common for OO languages (or, in fact, any language with a notion of subtyping), where individual classes implement their own comparison operators. In C++ you can overload the comparison operators, but most OO languages that don't do operator overloading just use a named method. If you write a.equals(b), then you'll call the equals method implemented by the class of a. If you write b.equals(a) then you'll call the method implemented by the class of b. One may know about the other, but the converse is not guaranteed. The Objective-C collection classes document certain invariants for inserting objects into sets (or as keys in a dictionary), including that [a isEqual: b] implies [b isEqual: a] (and that [a isEqual: b] implies that [a hash] equals [b hash]), but this is impossible to statically verify in the general case.

Re:Oh please

[TheRaven64]

If one developer makes a mistake, it's the fault of the developer. If most developers make the same mistake, it's the fault of the language.

Re:Oh please

[TheRaven64]

The type of "hello world" is const char *, so your compiler should warn that you're dropping the const in an implicit cast (and if you're a sensible person and compile with -Werror, then your compiler will reject the code). You can get the behaviour that you want with:

const char s[] = "hello world";

This will copy the contents of the string literal into a mutable array. If you write this at the global scope, the copy will be done at compile time, so you'll end up with the string in the data section, not the rodata section (if you do it in a variable with automatic storage, you'll get a copy every time the variable comes into scope). Putting constant strings in the rodata section is important for optimisation, because it allows them to be coalesced. If you write "hello world" in two place, then you'll end up with a single string in the rodata section. With some linkers, if you also write "world" somewhere else, then you'll just get two pointers into the same string (this is also one of the reasons that C uses null-terminated strings: you can't do this with Pascal strings, and it saved a useful amount of memory on the PDP-11). Once you're sharing the string, it becomes a really bad idea to allow someone to modify it, because that modification will then become visible in a different bit of code.

Re:Oh please

[angel'o'sphere]

But that depends on many things like operating system and Compiler, and I would not wonder if you forgot a 'const' to force the crash ;D

Re: Oh please

[Lisandro]

Oh, it certainly isn't. Too bad on PHP, == when used on objects compares both value and type of every attribute in them, which is what === does for all other types.

Re:Oh please

[Lisandro]

Oh, it can. It just won't do it reliably. Setting a string pointer to 0x72 will certainly do.

Re:Oh please

[Lisandro]

You do know that "feature" is present on all PHP versions up to the 7.x line, right?

Re:Oh please

[goose-incarnated]

Oh, it can. It just won't do it reliably. Setting a string pointer to 0x72 will certainly do.

It can. It might not though. It depends, actually, on whether it is ever deferenced or not. The original *s = 'H' can crash without ever needing any more derefencing. Your correction can (not 'will', but 'can') crash only if it is dereferenced.

Setting it is not enough, you have to dereference it as well. Although now that I think about it, depending on the platform, simply dereferencing it may still not be enough.

For example, I just tried it now, verbatim, in the OS kernel I hobby-developed and it worked just fine reading from it. Of course, it returned some random address stored in the interrupt vector table, but it did not crash!

I can also write to it too - I've not yet filled in the IVT so no interrupt number is using those numbers ... yet! The OS is probably going to use int-0x80 and storing 12 bytes at 0x72 will not reliably overwrite address 0x80. At the current alignment it certainly will not. A single character more will take the total to 13 + alignment padding = 16 bytes total, which is 0x72. A bad jump here will probably reboot, which we can safely judge to be a crash.

Re:Oh please

[Anonymous Coward]

B===D is much better than B=D. Trust me, I'm an engineer.

Re:Oh please

[goose-incarnated]

Dereferencing the virtual address 0x72 is guaranteed to crash an application when the OS is designed never to map the first (usually 4K) addresses. Accessing that memory causes a page fault, the OS searches the page table for the corresponding page mapping, fails to find a valid mapping, so you get a segmentation fault.

This has nothing to do with C though. C says the behavior is "undefined" if you set a pointer to a location that is not used to store a C object.

We've already agreed that it's undefined behaviour. What we're arguing are the circumstances that this particular invocation of UB would result in a crash. Just because something is UB doesn't mean that it consistently crashes at the point of UB.

Re:Oh please

[rp]

Please note that the article claims nothing of the kind.

Re:Oh please

[Anonymous Coward]

Pascal's notation is better:

a = b : the value of variable a is equal to the value of variable b (as = is used in mathematics, == in most other current languages)
a := b : variable a takes the value from variable b (unfortunately = in most other current languages)

Re:Oh please

[mysticgoat]

It is a poor craftsman who blames his tools for his shoddy workmanship.

It is a poor craftsman that uses shoddy tools in the first place. Selecting good tools is a core skill for any craftsman.

Same thing.

The take-away: If you don't know how to use PHP to build secure systems, use some other tool. If you don't know how to use any other tool, don't try to do secure systems.

In every case, the fault is with the programmer, not PHP.

Re:Oh please

[djinn6]

If s = 'H' actually compiled, it would be very bad, because s is a pointer, and 'H', being a char, can be converted to an int value of 72. What this code would do is to set the pointer s to a memory address of 72.

What's can you find at byte #72 in memory? Who knows! But it's probably not the character "H".

Re:Oh please

[AndroSyn]

gcc used to accept -fwritable-strings to allow for writable strings as mentioned in the sample. Generally only really, really old code needed this I believe gcc 4.x removed this feature. I think this was always an implementation defined feature, one where the spec is silent on how to treat these strings.

Most people these days will do something like the following to simulate:

char s[] = "hello world";

*s = 'H';

The assignment will work this way, since the string literal is copied to the stack.

Re:Oh please

[gweihir]

Actually, quite a bit of fault is with PHP, as novices may just not know any better without really being at fault. Poor tools play a role in creating poor craftsmen. It can also not be disputed by anybody sane that the makers of PHP are exceptionally poor craftsmen.

Re:Oh please

[gweihir]

I would recommend to pay more for that screwdriver. It pays off.

Re:Oh please

[Vairon]

You are wrong. In my example, using ==, it will report equal. Using ===, it will report not equal.

$ php -r "if (\"0E54321\" === \"0E12345\") { echo \"equal\n\"; } else { echo \"not equal\n\"; } "
not equal
$ php -r "if (\"0E54321\" == \"0E12345\") { echo \"equal\n\"; } else { echo \"not equal\n\"; } "
equal

The string "0E54321" and "0E12345" both get converted into the integer 0 for comparison purposes when you only use ==.

The documentation clearly explains this behavior. I'll link it again for you.
Type Juggling
String Conversion

Re:Oh please

[Dashiva Dan]

Call me an idiot, but if programming something that needs to be secure in PHP, you simply don't rely on the default equality comparator. It's there for simpler noncritical issues where it's behaviour is expected. So yeah, working around the "fundamental language defects" is something unfortunately most (all?) programmers need to do regardless of language. Adding better tools can only help.

Re:Oh please

[spongman]

$ gcc -Wwrite-strings -Werror a.c
a.c: In function ‘main’:
a.c:3:12: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
    char *s = "hello world";
                        ^~~~~~~~~~~~~
cc1: all warnings being treated as errors

Re:Oh please

[michael_wojcik]

The next version will support "====" for things are really, *really* equal.

We won't be safe until PHP adds the ===== operator, which is always false.

PHP also could really use the stricter ====== operator, which terminates your program and wipes the disk regardless of its operands.

Of course I jest. PHP will never get better, we will never be safe, and the former is only one of many causes of the latter. But given the PHP designers' inclination to add everything plus a kitchen sink with swapped hot and cold valves and a clogged trap to the language, it's surprising that they haven't added operators for doxastic logic:

x ?= y is true if the program believes x is equivalent y.

x ?== y is true if the program believes x and y are the same entity.

x ??= y is true if the program believes that it believes that x is equivalent to y.

A few more rules, and PHP becomes Godel-complete!

SubjectsSuck

[aardvarkjoe]

Arciszewski also says that PHP is actually "the first" programming language to support a "modern" cryptography library in its core, despite Erlang and Go including similar libraries, which he claims are not as powerful and up-to-date as PHP's upcoming Libsodium implementation.

So it's the first to support a modern cryptography library, as long as you define "modern" to mean "the one that we're using."

It's easy to be first to do something if you place enough arbitrary restrictions on what that something is.

Re:SubjectsSuck

[NotInHere]

"Modern" is for CS people like "Alternative facts" is for politicians.

Re:SubjectsSuck

[MightyMartian]

I don't even understand the point of the claim. So the interpreter has a baked-in crypto library? And how is that different than simply #including a crypto library, which has the added bonus that you can pick any number of crypto libraries.

Re:SubjectsSuck

[SCY.tSCc.]

It's easy to be first to do something if you place enough arbitrary restrictions on what that something is.

Hey, you're the first user in this thread whose user id starts with 15680 to say THAT.

Re:SubjectsSuck

[Chuck Chunder]

What are the best alternatives to NACL for cryptographic primitives?

I think the point is "first" is a weird word to use when you are talking about "modern" as "modern" changes with time.

OpenSSL or mcrypt or whatever else you might point to were "modern" when they were "first" used, even if they aren't "modern" any more.

"Only" might be a better choice if you are talking about the current time.

Re:SubjectsSuck

[Anonymous Coward]

Libsodium is an extended fork of Daniel J. Bernstein's original NaCl project (not to be confused with Google Native Client), which is a cryptography library developed with the overarching aim of simplifying (and improving the implementation-level safety of) the practical use of strong cryptographic constructs. The "big idea" behind NaCl was to abstract away many of the low-level choices and technical details associated with various cryptographic primitives in favor of more "generic" interfaces, utilizing implementations of algorithms that are widely deemed strong and safe behind the scenes. Thus, the potential for human error via misuse or misunderstanding of various primitives would ideally be reduced, and overall security posture could be improved for many applications, without every developer needing to spend years becoming a cryptography expert. For additional background on NaCl, you might reference the following paper: The security impact of a new cryptographic library. Like its predecessor, libsodium is freely licensed, and developers are encouraged to embed and distribute the library along with their projects.

Hope this helps. -PCP

Re:SubjectsSuck

[Darinbob]

Tomorrow there may be a new security library and the first language that uses it will be the "first" language to use a "modern" security library.

Pity the person who's been campaigning to include SSL into a language only to be told "we're deferring this because it's no longer modern enough so we will continue providing no security library."

Re: SubjectsSuck

[Sledgy]

It's different in that if a vulnerability is discovered in the underlaying library an new release of PHP is required to fix it. Note you will need to convince the hosting provider/infrastructure team to test and deploy the latest release. This is the reason the cryptography library for Python (and requests) don't want to be made part of the core so they can be agile and respond quickly to security problems.

Re:SubjectsSuck

[Waccoon]

Well, it certainly makes things easier for us hobby programmers that make redistributable projects designed to run on shared servers. I can't count on people installing a framework or keeping a library up to date if they have no admin access to the server. A lot of PHP projects, like Wordpress, still aren't aimed at serious, large-scale enterprises. Don't assume the owners have shell access with enough permission to install dependencies.

I started working with PHP over a decade ago because it had a graphics library built directly into its core, so I could always depend on it being there. GDlib isn't great, but it works well enough for generating thumbnails. Saved me a lot of trouble trying to dick around with detecting ImageMagick or doing stupid shell calls that might not even work on hardened shared environments.

Granted, I only do small, trivial stuff, which is all I recommend PHP be used for.

Re:SubjectsSuck

[bluefoxlucid]

More ridiculous is the claim that including crypto will force WordPress to implement better security. WordPress can just ignore this; and getting hacked by shitty REST API authentication verification isn't fixed by pouring on more crypto sauce.

This guy is a crypto nerd who thinks crypto solves all problems. It doesn't. He probably has databases with columns (UserID, UserName, CryptedPassword, AESKey) so the password is AES-encrypted with an individual key per-user.

Re:SubjectsSuck

[Trailer Trash]

I don't even understand the point of the claim. So the interpreter has a baked-in crypto library? And how is that different than simply #including a crypto library, which has the added bonus that you can pick any number of crypto libraries.

More to the point - this is the main problem with PHP. The idiots who "design" it think that something like this should be compiled into their interpreter and made into even more built-in function calls. The better way to handle it is exactly as you describe - allow people to add their own code and make your language robust enough to allow them to code the crypto library (or whatever) in your language.

Historically, PHP was terrible at handling binary data and such, so there was no way to do a lot of these sorts of actions in straight PHP. The workaround was to write your functionality in C and then include it as a PHP module - meaning that PHP would have a new set of functions when your module was included. This caused namespace issues and idiocy such as two sets of "functions" for handling MySQL connectivity: the "mysql_" set and the "mysqli_" set. It's like the "Attack of the Killer Tomatoes" of programming languages, except "it's so bad, well, it's just bad".

Now their idea is to encourage WordPress programmers to do better by including a crypto library in their already polluted function namespace.

<facepalm>

Re:SubjectsSuck

[dougTheRug]

NSA published EC algorithms and even specific curves.

Re:SubjectsSuck

[wimg]

And you're claiming this stone dropping based on which source ?

So they'll be the first to do it wrong?

[OverlordQ]

I'll stick to every other language that has had libsodium bindings for a while now.

Re:So they'll be the first to do it wrong?

[c]

I'll stick to every other language that has had libsodium bindings for a while now.

I'm just waiting for them to release the libsodium bindings for C...

Re:So they'll be the first to do it wrong?

[thegarbz]

The only way to really get libsodium to bind with C is to use Google's Native Client environment.

Re:So they'll be the first to do it wrong?

[gweihir]

They probably only care to be the "first" at something.

Now that that's done...

[Anonymous Coward]

... let's get proper multibyte support.

Re:Now that that's done...

[AlphaBro]

Hilarious this was modded down to troll. It's a legitimate request.

libsodium is a C library

[adam.voss]

For those who don't know, libsodium is a C library that PHP will be utilizing. It is not a PHP library.

Re:libsodium is a C library

[Anonymous Coward]

That's actually a good point. PHP is a bit unlike most other "interpreted" languages in that there are two kinds of libraries. There are the mods, written in native C, and included in the PHP+Apache runtime environment. That reflects PHP's basic structure as more-or-less a fancy wrapper around a bunch of C libraries. Then there are libraries written in PHP, such as the stuff in the PEAR libraries.

AFAIK (but I'm ignorant on this topic), Java, Javascript/node.js, etc. don't have a way to include C libraries in the runtime environment (no equivalent to "#include stdio.h"), so if you want a library to do "X", it has to be written in Java or Javascript. So in that sense, PHP may in fact be the first to include a crypto library in the default runtime.

Re: libsodium is a C library

[p91paul]

Java has support for calling C (actually, any compiled library) through JNI (Java Native Interface)

Too little... too late...

[__aaclcg7560]

I got tired of script kiddies banging down my PHP/MySQL servers. I'm using Pelican (Python) to convert my websites into static websites. With nothing to hack, script kiddies go away.

Re:Too little... too late...

[tepples]

I'm using Pelican (Python) to convert my websites into static websites. With nothing to hack, script kiddies go away.

How do you edit your Pelican-powered website while away from your home PC? Skiddies can hack through that.

Re:Too little... too late...

[__aaclcg7560]

How do you edit your Pelican-powered website while away from your home PC? Skiddies can hack through that.

I don't allow outside access to my file server at home. From my file server I can make whatever changes needed to the website, run pelican to generate the static files, and rsync the output directory to the hosting server. Since I don't use PHP or MySQL, the script kiddies have no attack vector into my website.

Re:Too little... too late...

[tepples]

I don't allow outside access to my file server at home. From my file server I can make whatever changes needed to the website

If you get an idea for an update while away from home, particularly for an extended period, what do you do with that idea?

Re:Too little... too late...

[__aaclcg7560]

If you get an idea for an update while away from home, particularly for an extended period, what do you do with that idea?

I write it down in my dead tree notebook.

Re:Too little... too late...

[thegarbz]

I don't allow outside access to my file server at home. From my file server I can make whatever changes needed to the website

If you get an idea for an update while away from home, particularly for an extended period, what do you do with that idea?

Sorry but this is a silly thread. Security is an inconvenience and you have to live with it. That said your problem is not solvable:

1) write it down.
2) email it to myself.
3) ssh.
4) outright VPN.

Me I take the last option. There's no dynamic content accessible on my site which isn't behind at the least HTTP auth. There's no dynamic content on my website which takes user input that doesn't also limit it's scope to the local network.

And despite all of these restrictions, content is still easier to update than it was back in the mid 2000s, and I managed just fine then too.

Ahhh PHP....

[cmdrbuzz]

PHP, the "Speak 'n Spell" of programming languages.... More marketing fluff.

Re:Ahhh PHP....

[AlphaBro]

Unless it's a buffer over-read, in which case there might not be a 'BZZZZT!' You know, like Heartbleed.

BULLSHIT!

[allo]

BULLSHIT! BULLSHIT! BULLSHIT!

PHP is one of the programming languages, which load all stuff into the core (which can be quite a disadvantage), but other languages use a library by a single include. So what?
And even php has it into a .so file, which can be loaded, but isn't required to be used. So the "core" is relative as well. Actually its a bundled module.

Re:BULLSHIT!

[allo]

> but I don't recall Java or Javascript (for example) having any equivalent method for including a .so file into their runtime either permanently or on demand.
Javascript isn't the best example, as it doesn't have any good standard library (which leads to the whole npm fuckup).
Java can load binary modules, but much stuff is written in java and performs good enough.
But the actual point is, that you link against a libsodium binding and php does it as well. They have build some lib, which then provides functions to the php interpreter. And they bundle it. That's it. You can just download libsodium and link it to your C program and get a similiar result without using a library for binding it to something, as it is written for C.

Re:BULLSHIT!

[rp]

Bullshit. PHP doesn't load everything into its core: it has a well-developed system for managing optional extensions (PEAR). "Core" extensions are the ones that come with PHP.. This is pretty standard terminology. You just can't be bothered to look it up. Then why reply at all?

Re:BULLSHIT!

[allo]

you're confusing php modules with php extensions. Pear installs php scripts, not modules. The modules are stuff like libgd for graphics and so on, coming as shared library (.dll or .so).

Re:BULLSHIT!

[allo]

> it still depends on how its compiled. Most distros have the "core" modules as php extensions. But if you WANT to, you can compile php to include these modules into the lib/exe so you don't have to load the shared libraries.
Of course, you can do.
And in a C program you can statically link the libsodium.a. So what?

> I believe you can compile ANY php extension INTO php so you don't have to load it every time
You won't notice.

> because binding with a static library allows the software to function even if the underlying shared libraries have been updated.
That's a reason. On the other hand, you update your libs and your php stays insecure. No good idea.

> The point here is that once this library is included, distros will have this in by default, and it won't require you to install a compiler and pear/pecl software to get the extension into your php
Yep. But that's still a strange definition of "the first langauge to add modern cryptography" (btw. why the quotes in the title, libsodium IS modern cryptography).

Perhaps instead of building everything and .....

[aix tom]

.... a kitchen sink into the core, they could have instead done a *sane* way to include additional modules.

Perl and Python for example have no problem loading user-specific or script-specific modules, not like the "system wide or nothing" approach of PHP. ( which of course doesn't work with shared hosting. )

Other languages did this first

[MobyDisk]

I remember when Java was the first language to do this. Shortly after that, C# was the first language to do this. Now PHP is the first language to do this. So who will be the next one to do it first?

Re:Other languages did this first

[Agripa]

I remember when Java was the first language to do this. Shortly after that, C# was the first language to do this. Now PHP is the first language to do this. So who will be the next one to do it first?

It is not first until Apple does it.

I'm not sure this is a good idea

[jandrese]

I'm torn on the idea of having one particular crypto implementation having first class citizen status in the language. It should help adoption and alleviate deployment headaches, but if that library turns out to have problems or just becomes obsolete it's even more of a hassle to work around it. Crypto algorithms are unusual in computer science in that they come with use-by dates. Most algorithms are timeless, but crypto changes constantly. What are the odds that in 5 years this becomes "that thing you shouldn't use but everybody uses it anyway because it's the default and its built in"?

Re:I'm not sure this is a good idea

[gweihir]

This is PHP. The language is saturated with bad decisions. This is just one more of those.

Gotta love PHP ...

[Qbertino]

I'm smiling while I read this.

Every single bit of this news is sooo PHP and one of the reasons this awkward mess of a PL is so successful.

They find something new or something they need and bolt it on. Just like that. End of story. A vote on the core team, a little coding and *BAM* PHP has a new inner API function with what has to be the most over-the-top all-out-PHP-style name for an inner API function ever - sodium_crypto_box_keypair_from_secretkey_and_publickey($ecdh_secret, $ecdh_public); (seriously, this is no joke).

Totally LOL. Takes the cake for inner function names ten times over, even by PHP standards, which is quite a stunt. And right away PHP has up-to-date hard crypto that even a simpleton can use.

You have to hand it to the PHP crew - they actually get shit done, no matter what. :-)

Re:Gotta love PHP ...

[phantomfive]

You have to hand it to the PHP crew - they actually get shit done, no matter what. :-)

They should make that their motto: "Getting shit done, no matter what!"

Re:Gotta love PHP ...

[michael_wojcik]

You have to hand it to the PHP crew - they actually get shit done, no matter what.

Indeed. Shit is precisely what they get done. Indeed, despite PHP's lack of originality in most areas, it has been quite inventive in the production of shit.

Monte beat PHP by a year!

[MostAwesomeDude]

My beloved Monte https://monte.rtfd.org/ beat PHP to this by a wide stretch. While it's true that PHP is a big established language, that doesn't mean that they get to claim sudden leaps in innovation which didn't happen. I've tweeted at the author of the blog post https://twitter.com/corbinsimpson/status/834175224736157696 with timestamped commits from the Monte codebase.

So, you're embedding libsoduim...

[Lisandro]

...which effectively prevents me from updating it. Great choice for a security library guys.

Re:So, you're embedding libsoduim...

[Anonymous Coward]

Most software is (or should be) subject to maintenance updates for various reasons. Embedding libsodium in an application simply shifts the distribution point for updates. If you're using software (PHP in this case) distributed as a package in a common Linux or BSD distribution, you'll have the ability to install updates/fixes whenever the distribution's package maintainers make them available from new or patched upstream sources. If you're compiling from source, you'll have the option of tracking updates and doing rebuilds yourself whenever they're made available by the core PHP development team (which would have the responsibility to track updates to libsodium and other included libraries).

In the end, you're still responsible for monitoring update announcements for the various components which comprise the systems you depend on, regardless of which model of integration and deployment you decide is best for your use case. There's no free lunch in any event, only various decisions to be made regarding which parties have which duties in the maintenance pipeline. -PCP

Re:So, you're embedding libsoduim...

[Lisandro]

Sorry, that is not enough. There's a vast difference from updating a crypto library (which can happen, f.ex, due to security updates) to updating the whole damn language, which can have system-wide implications.

Re:So, you're embedding libsoduim...

[Lisandro]

I understand what you're saying; my point is that the problem is not the release model.

First off, i'm not aware of any languages which do rolling releases - PHP certainly doesn't - and with good reason. The problem is that PHP makes a security component part of the language itself and provides no other way of updating it; a libsodium update becomes now a PHP update, which means you're at the whim and mercy of the language creators when it comes to managing it.

This is specially annoying in PHP, where language installs cannot be made but system wide. Ever tried to run two different versions on the same machine?

Re:So, you're embedding libsoduim...

[Lisandro]

That's quite more than "a bit of thinkering", specially compared with pretty much any other interpreted language in the *nix word, which allow multiple language/library versions on a single system in a much saner way.

Same type inequality comparison operators?

[tepples]

Is there also a "less than and of the same type" operator? Or is calling strcmp() the best practice for this?

Would you prefer an interpreted crypto library?

[tepples]

And how is that different than simply #including a crypto library, which has the added bonus that you can pick any number of crypto libraries.

I can see three ways to proceed:

A built-in crypto library This runs at full speed and is available by default to the shared hosting customer. An add-on crypto library compiled to native code and distributed as a PHP extension This runs at full speed but requires the shared hosting customer to convince the hosting provider to install it. An add-on crypto library written in pure PHP This is available by default to the shared hosting customer but can run unacceptably slowly due to interpreter overhead.

Re:Would you prefer an interpreted crypto library?

[tepples]

An add-on crypto library compiled to native code and distributed as a PHP extension

use an add on binary library that runs at full speed but that the user can install together with their scripts through dynamic loading

That depends on two things: whether the shared hosting provider has configured the interpreter to allow such dynamic loading, particularly from within the subscriber's home directory, and whether the shared hosting provider allows the subscriber to install a compiler and corresponding headers to compile said library. As the PHP manual states:

The main reason for turning dynamic loading off is security. With dynamic loading, it's possible to ignore all open_basedir restrictions.

Re: Queue the Rust is better people

[cyber-vandal]

Cue*

Every time I see a PHP job ad I think

[FryingLizard]

"...man, you guys must have some serious technical debt"

I built a startup's entire stack on PHP back in the 2003-2006 time, now I look back and SMH at the foolishness. If you want a quick'n'weakly-typed language (which I often do), Python beats the crap out of PHP, as well as being ten times more readable.

Re:Doesn't Java have a cryptographic library?

[rubycodez]

guess back in the late 80s ANSI weren't smart enough to include block cipher libraries we were calling from FORTRAN and C into the languages. pfft, php never disappoints, it's like the QBASIC of the 21st century

The crypto is the easy part of this

[thogard]

The cryptography algorithms are the easy part. The vary hard part is protecting keys so I hope someone provides plenty of examples of how to do that properly. I hope they don't go down the Java route of showing how to use the functions without proper key management.

Re: Queue the Rust is better people

[PCM2]

Well, technically you could have them line up for comment.

And it'll be a shitshow because of course it is

[Just Some Guy]

Sneak preview of the API:

crypto_really_encode(plaintext, algorithm); // Simplest
crypto_really_encode(plaintext, mode, algorithm); // Next arg goes in the middle
crypto_really_encode(block_size, plaintext, algorithm, mode); // Switch it up yo lol

...where AES will somehow be a valid value for both mode and algorithm (which will silently override to "NULL" if plaintext starts with a zero or the letter "p").

Re:And it'll be a shitshow because of course it is

[AlphaBro]

Lots of gold in this thread, but this one should be a 5. The PHP API design decisions are the shittiest I've ever seen in my life.

Dynamic Type Comparing [Re:Oh please]

[Tablizer]

In my opinion, dynamic languages should require, or at least encourage, one to specify what comparison type to use rather than rely on parameter (operand) analysis. The hard part is coming up with a nice syntax for such. I've had various discussion groups consider different suggestions, and found no consensus.

In the shorter term, one can roll their own functions and hope staff coders follow along. Example:

if (strCompare(a, '>', b)) {...}
if (numCompare(a, '<=', b)) {...}

Re:System.Security.Cryptography

[AlphaBro]

Yes, but you see, Microsoft didn't statically link all the crypto stuff into a monolithic binary. Because, uh... I guess loading a bunch of unused stuff into memory is newsworthy.

Re:Proud to be stupid

[gweihir]

You have to admit that they are consistent at the bad decisions though. Making bad decisions seems to be their most important guiding principle.

Oh LOL! PHP!

[dschiptsov]

FYI Golang has a "modern" cryptography library in its core. PHP in 21th century. What a lunacy.