Move away from defuse/php-encryption

[drzraf]

Git password is currently processed through php-encryption. It's actually more an obfuscation than actual encryption because:

• YAML and encryption key are in related directories and both must be readable by the PHP interpreter.
• Encryption key is hardcoded here
• One would just run php -r 'require("vendor/autoload.php"); var_dump(Grav\Plugin\GitSync\Helper::decrypt("gitsync-foobarencrypted"));' (even on its local system) the get the cleartext.

That leads to two observations:

• First, the key could very well be stored as base64. Less dependencies, less code, less complication, less false feeling of security.
• Even if an argument for encryption would exist, it would be really nice to use a standard algorithm.
  • Core::CURRENT_VERSION . $salt . $iv . self::plainEncrypt($plaintext, $ekey, $iv); is definitely not.
  • Any of openssl_* and sodium_* is.

That would allow provisioning these credentials using other language/libraries/deployment technologies.

[w00fz]

You are right in saying this is mostly obfuscation as well as pointing out how base64 would do the same, however this is mainly to not store the obfuscated password in a blatantly easy to identify format. Unfortunately proper encryption where we let the server decrypt for us cannot be done due to the nature of Git which is why no matter what solution to encrypt the password we find, it will always be fairly easy to decrypt. The main purpose of obfuscating the password is so that we can somewhat keep the yaml file secure from a plain password.

I'm open to PRs if you a have better implementation that can guarantee backward compatibility and cross platform availability. For example I know for a fact that openssl functions might not be available in windows system and that is definitely going to be a problem.

[drzraf]

Could you keep the issue open so that it's not missed from the radar? Even if a PR pop up, it would be to fix #142.