Welcome Guest, Not a member yet? Register   Sign In
Poll: What do we do with the Encrypter module?
You do not have permission to vote in this poll.
Build it into CI4 core
59.57%
28 59.57%
Doesn't matter to me
25.53%
12 25.53%
Leave it out of the core
14.89%
7 14.89%
Total 47 vote(s) 100%
* You voted for this item. [Show Results]

[done] Encrypter
#21

While encryption is a useful and sometimes necessary tool, it need not be in the core. Thanks for adding this poll option.
CI 3.1 Kubuntu 19.04 Apache 5.x  Mysql 5.x PHP 5.x PHP 7.x
Remember: Obfuscation is a bad thing.
Clarity is desirable over Brevity every time.
Reply
#22

This has certainly stirred a lot of comments, some for & some against the idea of having encryption built into CI4!
The wind is blowing 2:1 in favor of having it, but the poll is flawed in that it did not provide a "not" option in the beginning.

I did a bit of research into other frameworks' handling of encryption, and thought you might find the results interesting.
They follow, alphabetically by framework with encryption...

Laravel 5
- module Encryptions\Encrypter
- Similar to CI4 proposed, tho more methods exposed
- OpenSSL only
- Encryption\EncryptionServiceProvider classes
- Docs at https://laravel.com/docs/5.8/encryption
- very similar to what I am proposing

Yii 2
- Module yii\base\security
- openSSL based
- Encryption/decryption, key derivation, hashing & validation
- Similar to CI3 encryption

Zend 2
- Module Zend\Crypt
- symmetric encryption, bunches of classes; possibly some public/private keypait stuff
- Docs at https://docs.zendframework.com/zend-crypt/
- More complicated and far-reaching than what I am thinking of

CakePHP, FuelPHP & Symfony
- don't appear to address encryption in either the core or standard addins
Reply
#23

@ciadmin,

Thanks for the info. I'm still a fan of keeping it thin and light and if it is needed then obtaining a library/plugin should do the trick.
Reply
#24

Ah now that I read the thread, I wish I could change my vote to leave it out of the core. I was getting hashing and encryption mixed up... For example Laravel does bcrypt method, but I must have encryption wrong in my head. I like CI because how light it is. I'm a huge Laravel fan, but I am not using it for most of my production uses just because how bloated and slow it is.
I wish I could change my vote to leave it out since I initially said to put it into the core.
Reply
#25

(This post was last modified: 07-18-2019, 06:26 PM by ciadmin.)

An update: I completed a PR for a simple encrypter, and DOH - the advertised libsodium support in 7.2 isn't there!
I am putting this on the back burner again. travis-ci does NOT have builtin support for libsodium, and the guidance I have found online is unclear and contradictory.
I will chip away at the unit tests as time permits, and hope that the libsodium support improves, so that this can be reconsidered!
Reply
#26

It really should be left out, but like @php_rocs I say leave CI 4 lean and mean.

Users can always use any other class libraries out there.
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )
Reply
#27

That's good, since mostly people don't need php based encryption, they need hashing. Good hashing is already built into php now. There may be cases where you may want to encrypt cookies stored on user computers, but it's simple enough to find a decent library on packagist to handle that side of things.
Reply
#28

There is a lot of support for some (simple) encryption in the CI4 core - and that is what I had in mind.
The problem for me is that libsodium *isn't* integrated like it was supposed to be.
We could have simple encryption, OpenSSL-based only, if that would help.
What do you think?
Reply
#29

Maybe the burden for supporting would be less if a polyfill for libsodium would be suggested as an optional Composer package to be installed.

https://github.com/paragonie/sodium_compat
Reply
#30

@ivantcholakov The original post suggested we were directing developers to https://paragonie.com/project/halite, which is a superset of sodium_compat if I recall correctly. The problem now isn't a support issue from our perspective, but rather that PHP7.2 & 7.3 do not include libsodium, contrary to earlier indications Sad
Reply




Theme © iAndrew 2016 - Forum software by © MyBB