
Show HN: Lockbox – simple encryption with key management - starekrow
https://github.com/starekrow/lockbox
======
iandev
It looks neat. I'm sorry I don't have much feedback, but I think this line is
incorrect in your readme.

file_put_contents( "key.txt", $k->Export() );

I think you meant $key->Export(). Just a heads up to save the copy and
pasters.

~~~
starekrow
Ack. You are absolutely right, that was my own copy/paste issue. Fixed now,
thanks!

------
meritt
If you want actual adoption, you need to conform to PSR and should probably
use libsodium which is part of the core in 7.2

~~~
stephenr
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

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

~~~
stephenr
> Attention to detail leads to code quality.

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.

------
heavenlyblue
What is the supposed use-case for this library?

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

~~~
otterley
Since you're running in AWS, is there any particular reason you're not using
Parameter Store?

~~~
starekrow
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 :)

------
news_to_me
Why PHP?

~~~
starekrow
Why not? :D

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.

