Publish a signed .phar for easy inclusion

[defuse]

From my experience trying to recommend libsodium, I know that developers still expect to be able to use a library by copy/pasting code. Unfortunately, to compete with the plethora easily-copypastable bad crypto code on the internet, we have to support that style of use.

When I'm reviewing v2.0, I need to make sure that we're still competitive in that "market."

[defuse]

v2.0 doesn't make it much more complicated. We should make documentation that says how to use the library without using composer or anything like that.

[defuse]

Here's an idea: Let's do something like those javascript libraries do and make a script that packages the whole thing into one php file that you can include.

Oh wait... I think that's called a ".phar" :-)

(I think calling it a ".phar" might scare people off, though, thinking it's some special PHP thing that isn't built into the default PHP?)

(Another problem with ".phar" is that their apache might not be configured to not serve files with *.phar extensions)

[paragonie-scott]

This is a library, not an API endpoint. You can include it from a PHP script and it will execute the stub.

I can create the build script for this. I'm already doing those for another secret project, and we can use Pharaoh to verify their reproducibility.

[paragonie-scott]

#139 should solve this :)

[paragonie-scott]

https://stackoverflow.com/questions/34399117/how-to-use-php-defuse

I'm not sure how much clearer we can make things. :(

[sethbattin]

To be honest, the proper usage of this library is not clear. Although the how-to-use page shows a clear case of using the library exactly one time for a single encrypted item, it doesn't show how to integrate the library into a useful system.

The basic interfaces are straightforward (enough for me to work on #147), but the combined usage is not. Here are a few questions i had:

• How should keys be persisted? Database? Filesystem?
• How should a user associate a key with the persisted content?
• How should users store the encrypted content? For files, what names and paths?
• Should the key storage also be protected using the library? Should there be a master key for that purpose?
• How is it safe to load such a master key into the system? Config file? Environment variable?
• How many keys should be made? Per item? Per system?

I am mostly ignorant of proper security practices, so forgive me if these questions are assumed knowledge. But on the other hand, this library's goals include being difficult to misuse. So the fewer assumptions of security expertise, the better, imo.

As an example use case, I have had to work on a system that safely stored files uploaded by users. I have no illusions that we did so in a correct way, but I also don't know what I should have done differently. A complete implementation of this use case would go a long way to make the library more accessible.

[defuse]

Those are definitely questions we should address, maybe in a FAQ document.

[defuse]

The .phar stuff will make it easy to import.