search

orcasgit / django-fernet-fields

Fernet symmetric encryption for Django model fields
BSD 3-Clause "New" or "Revised" License
193 stars 80 forks source link

Project Abandoned? #28

Open robd003 opened 3 years ago

robd003 commented 3 years ago

Does anyone know if there will be updates to support Django 3.x released soon? It looks like there is activity in Pull Requests / Issues, but the package author is no where to be found. Is the project abandoned?

brad commented 3 years ago

Sorry @robd003 this is no longer maintained and needs a new owner

jrenaut commented 3 years ago

I'm a pretty mediocre coder, but I'd be interested in helping sustain the project. I own a small business and I have a bunch of small condo associations depending on this package to keep their financial data secure.

dstarner commented 3 years ago

@brad I would be willing to take lead, as we use this in production. Would we keep the project under this org, or what would your vision look like for ownership transfer?

dstarner commented 3 years ago

If there isn't a response or any effort to keep the project alive, I will fork it and create a new Pypi package to keep the project alive.

9mido commented 3 years ago

Another option would be to make this a jazzband project. That way, we could all be owners and the project is more open source and there is no worry about 1 maintainer abandoning the project.

StevenMapes commented 2 years ago

If there isn't a response or any effort to keep the project alive, I will fork it and create a new Pypi package to keep the project alive.

Did you create a new Pypi package as your fork looks like you've renamed an app but haven't updated the README and I'm currently deciding between starting a new repository based on this or using django-fernet-encrypted-fields

yourlabsopensource commented 2 years ago

I'm maintaining a fork where I merged the pull requests and released 0.7.0 with Django 4.0 support.

https://yourlabs.io/oss/djfernet https://github.com/yourlabs/djfernet https://pypi.org/project/djfernet https://djfernet.rtfd.io

Njoy :tophat:

sevdog commented 2 years ago

I'm maintaining a fork where I merged the pull requests and released 0.7.0 with Django 4.0 support.

https://yourlabs.io/oss/djfernet https://github.com/yourlabs/djfernet https://pypi.org/project/djfernet https://djfernet.rtfd.io

Njoy tophat

@yourlabsopensource your "sed" to remove the string "django-fernet-fields" has changed the salt and info used in derive_fernet_key function, thus making any existing installation of django-fernet-fields to not be compatibile with your fork!

This is not a safe update, since it cannot decrypt any already encoded data because different salt produces different keys!

https://github.com/yourlabs/djfernet/commit/3f9a5fcdb87529ed87d901b632eeeaee0c9c7c7e#diff-b9c03c4a968b6bcca2eddbf07510cd65e7df243a23db7e0dad6724085297bcae

jpic commented 2 years ago

Indeed, thanks for the heads up @sevdog! Added a setting in 0.7.4 release, hope this helps ;)

:tophat:

jpic commented 2 years ago

Decided to change default back to django-fernet-fields to make migration easier.

Really sorry for the inconvenience. The whole thing is documented in CHANGES.txt:

0.8.0

Switched back to django-fernet-fields for default salt, making it incompatible with 0.7.4! But, compatible with django-fernet-fields, so that you can migrate easily if you haven't already.

If, unfortunnately, you have already deployed this in production, you have two options:

Sorry about this laborious releases.

Also, added EncryptedBinaryField.

0.7.4

First release since fork. Unfortunnately, my sed s/django-fernet-fields/djfernet/ caused a change in the salt, make it impossible to decrypt existing data!!

Added settings.DJFERNET_PREFIX to set it to django-fernet-fields and make it compatible again through a setting.

Thanks to @sevdog for the report.

domdinicola commented 1 year ago

@jpic are you maintaining still this?

sidmitra commented 1 year ago

@brad Would you be open to helping me transfer this to jazzband. I'd be willing to take over maintenance for now. Also having a common volunteer org on projects like this would help share the load.

There's an open ticket here: https://github.com/jazzband/help/issues/241 i'm happy to do any work required for the transfer of stewardship to the jazzband org.

The guidelines are here: https://jazzband.co/about/guidelines

@jpic Appreciate your fork. Trying to figure out if it is possible to keep the "django-fernet-fields" namespace alive on github/pypi.

StevenMapes commented 1 year ago

For those looking for something that is maintained I moved over to https://pypi.org/project/django-fernet-encrypted-fields/ from this, migrated between the encryption although there's a ticket open for that to move to JazzBand as well

lucas-bremond commented 1 year ago

For those looking for something that is maintained I moved over to https://pypi.org/project/django-fernet-encrypted-fields/ from this, migrated between the encryption although there's a ticket open for that to move to JazzBand as well

@StevenMapes Can we use this as a drop-in replacement? The codebase seems to have significantly diverged from the original library.

StevenMapes commented 1 year ago

No, it's not a fork but is something separate. You have to migrate across.

I did it by running four migrations. The first renamed the original fields, the second one added the new fields with the original names, the third migration was a custom migration to read from the old column and write back to the new one. Fourth migration then dropped the renamed columns.

It's not ideal as you have to update admin references and if you then want to remove the dependency without breaking new deployments and tests you have to edit your migrations afterwards or leave the the package within your requirements file(s)

On Thu, Dec 15, 2022, 02:46 Lucas @.***> wrote:

For those looking for something that is maintained I moved over to https://pypi.org/project/django-fernet-encrypted-fields/ from this, migrated between the encryption although there's a ticket open for that to move to JazzBand as well

@StevenMapes https://github.com/StevenMapes Can we use this as a drop-in replacement? The codebase seems to have significantly diverged from the original library.

— Reply to this email directly, view it on GitHub https://github.com/orcasgit/django-fernet-fields/issues/28#issuecomment-1352486927, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPLQGRZHSM3YOV66OSEVKDWNKBBJANCNFSM4VSO3IMA . You are receiving this because you were mentioned.Message ID: @.***>

domdinicola commented 1 year ago

guys, anyone using a package with:

stefan6419846 commented 5 months ago

I am looking for a reliable solution on this topic as well.

From my experience, jazzband proved to be unreliable in the past as well due to basically being a one-man show for setup-specific stuff and not much recent activity. Nevertheless, jazzband does not help much unless there actually is an active maintainer and ideally active contributors regarding to issues/PRs etc.

On the other hand, there are some forks or successors like django-fernet-encrypted-fields (which is part of jazzband). I am currently using djfernet due to mostly being a drop-in replacement for django-fernet-fields, but it has its own limits/issues at the moment:

jpic commented 5 months ago

The last commit happened two years ago.

And yet, PyratzLabs is still relying on DjFernet daily as dependency of DjWebdApp, the Django Web3 framework behind many successful crypto projects which are all under active maintenance.

Being a fork on GitHub, issues are disabled as they have never been enabled.

Because our hacker club is not hosting projects en GitHub anymore, we prefer GitLab, because of GitLab-CI, which allows us to run dedicated CI runners on extremely powerful and dedicated hardware sponsored by our company, which we need, because of all the OSS we maintain yourlabs.io/oss . Also, the GitHub Actions runner has always been a pain to work with compared to GitLab-CI.

It seems like the primary approach is the own GitLab instance (with corresponding CI) instead of GitHub. (The last time I tried, I could not register on the GitLab instance.)

That's funny, because I just used one of my old GitHub bot accounts to login on the GitLab instance @ yourlabs.io and it worked on the first try after just a click: https://yourlabs.io/mrsbot

2024-04-28-112432_759x669_scrot

So, I have no idea what you are referring to, can you show us what exactly happens when you click "GitHub" on this page? https://yourlabs.io/users/sign_in And then when you click here ? https://yourlabs.io/oss/djfernet/-/issues/new

GitHub PRs remain unnoticed as none of the public members of the GitHub organization actually watches the GitHub repository.

I merged, fixed, and released a bunch of PRs on DAL a month ago, and have been merging MRs on DSS a couple of weeks ago. I'm not sure what you're referring to, but this vague criticism is far from constructive.

Apart from the sed issue mentioned and fixed above, something went wrong with the license statements during the migration process. The metadata previously had the "BSD License" inside the trove classifiers and the BSD-3-Clause license file; djfernet removed the trove classifier while keeping the license file, but added the license field as "MIT" to the metadata which does not make much sense indeed.

And unless you're really, really bad at computers, it would have taken less time to submit a PR on the repo than writing this comment which usefulness remains to prove.

I'm most definitely not saying you should use our fork, we're just definitely maintaining one for our business purposes, and if you're not happy with it and particularly if you don't want to contribute "because it's not on github or whatnot" then go ahead and maintain yours instead of slandering.

You can also reach us at yourlabs.chat , go with "SSO with GitLab" and then once on our gitlab "SSO with GitHUB"

stefan6419846 commented 5 months ago

Sorry for upsetting you with my comment, but I just wanted to summarize the current situation as I have experienced in the past. I did not intend by any means to blame anyone as this is still FOSS and I cannot expect anything from anyone.

On the other hand, some of your other statements are just wrong or angry accusations I do not think should be part of such a discussion:

jpic commented 5 months ago

I'm not saying you said it's not working, I'm saying no commits doesn't mean broken, and that if it was broken I would know already, I've deployed it last week with Django 5 even.

The gitlab is indeed perfectly working, I did fix a configuration in my mailbox which was preventing me from having GitHub notifications last month or something like that.

I didn't remember that I had let Pull Requests on that repository, I think it was an experiment of mine, so I just found out by investigating and trying to figure what you were talking about. So, I'm taking care about them now.

Nonetheless, I'm fine letting this repo live on GitHub like our legacy software now that someone has contributed github actions for the tests. I'm not really keen on maintaining that because I really dislike it, but if you are up for it I have nothing against it. As such, I've open all github features on my github fork and will archive the gitlab one in the mean time, as long as the community maintains the github actions, meaning: as soon as github actions are a pain to fix the software I'll maintain it on gitlab again.

it seems like it has indeed been fixed now

Not sure what this is supposed to mean, but all I can state is that we have not done anything on the gitlab now, and we have no knowledge of any incident with GitHub SSO that we use on a daily basis. Email registration requires administrator validation because of all the bots (thousands) that register on it, perhaps you have received an email from GitLab telling you that your account was pending validation.

Anyway, we're all good then, and as many fellow GitHubers, you know that I reply to emails, in your case in ~5 hours and then had no further news from you, and most often than not am I granted with a "thanks for the fast reply", when missing notifications, which should be fixed in my mailbox since last month. Sorry for the inconvenience.

domdinicola commented 3 months ago

hey hey https://github.com/jazzband/django-fernet-encrypted-fields :)

stefan6419846 commented 3 months ago

django-fernet-encrypted-fields does not seem to be really active either and apparently does not provide any tagged releases or changelog, which does not look right as well.

domdinicola commented 3 months ago

https://pypi.org/project/django-fernet-encrypted-fields/#history