luckyframework / luckyframework/avram
Add attribute encryption
- Dominant language
- Crystal
- Stars
- 183
- Forks
- 67
- PR merge metrics
- No merged PRs in 30d
Description
The [lucky_encrypted](https://github.com/microgit-com/lucky_encrypted) shard depends heavily on Lucky and Avram. I'm wondering if it wouldn't have a better place in Avram. It's tiny, literally just one file, and I strongly believe this type of functionality belongs there. Rails 7 will have it (https://github.com/rails/rails/pull/41659), so why not Lucky?
I'd propose to keep it simple and extend functionality when and if required. So starting with something like:
```crystal
module Avram
module Encrypted
class String
include Lucky::AllowedInTags
...
module Lucky
include Avram::Type
...
end
end
end
end
```
Then usage would be:
```crystal
class User < BaseModel
table do
column email : Encrypted::String
end
end
```
That would leave the door open to add more encrypted types later on. Just like Andrew Kane's [Lockbox gem allows](https://github.com/ankane/lockbox#types):
```crystal
class User < BaseModel
table do
column email : Encrypted::String
column age : Encrypted::Int16
column married_at : Encrypted::Time
column settings : Encrypted::JSON
...
end
end
```
I'd also use a dedicated encryption key for easier key rotation. And key rotation itself is something that we can implement later.
Contributor guide
Research direction
Start by reviewing the linked lucky_encrypted shard and Avram's existing Avram::Type integration. Confirm how an Encrypted::String column would work in the User table example, and define the dedicated encryption-key behavior before considering support for additional encrypted types or key rotation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- crystal
- Domain
- database, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100