I hadn't actually considered adoption at any scale - I just thought the overall approach was cool, and the code might be useful to folks looking for this exact thing. The PSRs were lurking in the back of my thoughts during the cleanup for publication, though. Argh. They're a bit outside my normal coding style.
Re: libsodium, there will be optional support for it at some point precisely because it's going into the core, but I try to do all my components like this with no required dependencies. I'm not even entirely satisfied with Lockbox requiring the openssl extension, but that's far preferable to yet another homespun AES implementation.
I can basically understand if you said "you need to support composer (be on packagist).
But seriously? The only psr that would apply is autoloading (which it does use) and code style.
Given the amount of random fucking shit people include via language level package managers, if your concern is "oh the braces are in the wrong spot" I think you need to re-evaluate your priorities
The single biggest stereotype held against the PHP community is they are a bunch of shitty amateur programmers whose programming ability barely extends beyond copy-pasting stackoverflow. Very few of the language-centric criticisms are valid these days.
Granted a lot of these criticisms are often levied by trendy kids reinventing the wheel with Ruby, MongoDB, NodeJS, Go, Docker, etc (2008-2017 roughly), but unfortunately they tend the tone for tech as a whole, so PHP still has this very negative reputation even though we tend to get more shit done, make more money, and spend less time learning the latest new fad.
Adhering to PSRs goes a long way to combat that stereotype by having a consistent look and feel to open source packages. Attention to detail leads to code quality. Initiatives like phptherightway really help out the community by putting people on the right track from day #1.
I agree there's a ton of utter shit out there on packagist and I avoid 99.9% of it like the plague for this very reason.
I agree. But the PSR's approach things the wrong way IMO.
The style related PSR's should be exactly two rules:
1. Choose an existing/define a formatting style for the project.
2. Ensure the style is enforced, ideally using a code style formatting tool like phpcs, your IDE, etc
Thats it. Claiming that a project isnt up to scratch because it doesnt conform to an abritrary style that was created literally by what was most common in the member projects at the time, is frankly ridiculous.
Their subsequent decisions show a frankly laughable approach to development. Psr-whatever that defines a logging interface. Every man and his dog uses integer levels, usually the syslog 0-7 range.
This makes it extremely simple to ignore/filter out logs above a given priority.
What do they decide to do? Fuck it, make the defined log levels strings. Why? Because an existing project happened to already use integers that didnt adhere to syslog, and they didn't want to deal with it.
So fuck it, lets have a shittier, less sensible "standard" just so fucking monolog can keep using 400 to mean error or whatver it is.
Readability is good, standardisation is good. The latter should be a project level decision, and honestly ive never seen anyone who's picked a standard - any standard - that meant readability was a problem.
Sometimes you need your secrets to be secure, it can be some passphrases or encryption keys for your apps. This might give you an idea https://www.vaultproject.io/
I use it to store database passwords and AWS API keys on EC2 instances that are running web servers. When combined with a dead simple key distribution client/server setup, you can sleep a bit better knowing that even if someone managed to copy the entire hard drive, they wouldn't get your keys. Of course, if they get root on the box in operation it's all over, but anything short of that should be survivable. It beats the hell out of writing them all in the clear to "config.php" and checking that in with the rest of your site source.
I've also used similar code to manage an encrypted file store for a small business - since each file gets its own locks (essentially a cryptographic ACL) and each attached key is publicly identified, it's easy to see who can read (or change) any given file. Being able to remove lockboxes without decrypting the data means that a sysadmin can strip access from someone who leaves the company without needing an all-powerful "root" key.
When I did the first pass at this architecture about 6 years ago, we had a few servers in a rack at a local datacenter as well as virtual servers at Rackspace and AWS.
Since then, I haven't shed the habit of designing for the general case (this is also known as avoiding vendor lock-in :)
More seriously, because LAMP stacks are ubiquitous, well understood and well supported by vendors. Also, the output of this code is trivial to use or replicate in most other languages - in fact, I've got some fragments of C source lying around for a similar system, that was intended for a command-line tool that would interoperate with a distant ancestor of Lockbox.
That concern for future interop possibilities is the main reason it stores secrets in JSON - which is one reason, along with abysmal character encoding practices by many developers, that the key and ciphertext is all ASCII-safe. A 30% bump in output size is more than offset by never having to care what transport those strings are moving through.
file_put_contents( "key.txt", $k->Export() );
I think you meant $key->Export(). Just a heads up to save the copy and pasters.