Project Abandoned? about django-fernet-fields HOT 23 OPEN

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
🎩

from django-fernet-fields.

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.

from django-fernet-fields.

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.

from django-fernet-fields.

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:

• re-encrypt your data to use django-fernet-fields instead of djfernet,
• or set settings.DJFERNET_PREFIX=djfernet to keep going

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.

from django-fernet-fields.

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

from django-fernet-fields.

@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: jazzband/help#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.

from django-fernet-fields.

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

🎩

from django-fernet-fields.

from django-fernet-fields.

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

from django-fernet-fields.

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.

from django-fernet-fields.

@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?

from django-fernet-fields.

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

from django-fernet-fields.

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!

yourlabs@3f9a5fc#diff-b9c03c4a968b6bcca2eddbf07510cd65e7df243a23db7e0dad6724085297bcae

from django-fernet-fields.

@jpic are you maintaining still this?

from django-fernet-fields.

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.

from django-fernet-fields.

guys, anyone using a package with:

• not breaking changes
• maintained
• with package on pypi released

from django-fernet-fields.

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:

• The last commit happened two years ago.
• Being a fork on GitHub, issues are disabled as they have never been enabled.
• 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.)
• GitHub PRs remain unnoticed as none of the public members of the GitHub organization actually watches the GitHub repository.
• 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.

from django-fernet-fields.

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

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"

from django-fernet-fields.

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:

• I have never stated that djfernet does not work. I am using it in quite some projects already.
• There is nothing wrong with GitLab, although the workflow stuff probably is a matter of taste. I personally think GitHub performs better with multiple workflows, but there can be multiple opinions of course.
• There have been six months since I last tried to register/login with an account on your GitLab instance. I just tried today and it seems like it has indeed been fixed now, which corresponds to the registration date shown on my user page there. (I am not sure anymore, but I tried to register explicitly last time and never got a confirmation e-mail if I am not mistaken - whether I tried to use SSO as well as today I am not sure anymore.)
• DAL and DSS are unrelated to djfernet. I have been referring to https://github.com/yourlabs/djfernet/watchers and yourlabs#1 as well as yourlabs#2, where the latter has just been merged. These PRs have been open for quite some months without any further notice. Disabled issues and not watching own repositories is the default for forks and thus a common pitfall.
• Regarding the license: I wrote this in an email to you in 2023 and was asked to create a PR for it. As I only had been aware of the (for me not working) GitLab repository, I did not yet create a PR for it. This changed now: yourlabs#3

from django-fernet-fields.

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.

from django-fernet-fields.

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

from django-fernet-fields.

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.

from django-fernet-fields.

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

from django-fernet-fields.