Django-guardian welcomes your support

[ad-m]

In recent months, the project did not have new releases. This was due to the lack of time on the part of the current project maintainer. Even I myself do not have time, and I do not even use django-guardian in any actively developed project.

This situation is not good for the project. It is necessary to devote some time for:

• reviewing outstanding issues to resolve them,
• helping people who make pull requests to the project to bring these changes to be consistent with the whole project,
• answering questions on Stackoverflow, because they appear there.
• dropping old-versions
• etc.

Who has a certain amount of time to carry out these tasks and lead the project further?

[kiran-capoor94]

Hi, I’m new here. Let me know how I can help.

[johnthagen]

Might be worth pinning this issue for more visibility.

[brianmay]

@johnthagen I didn't know you could do that. Thanks. Now done.

@kiran-capoor94 I noted that nobody replied to your request, at least not here. If you are still interested in helping, please see the list in the first message.

In particular, there are 16 pull requests open at present. Help reviewing these and fixing them up to a acceptable standard appreciated.

[DavisRayM]

Hey 👋 , I would like to help around where I can too. Picking up a few issues and contributing code for now.

[kiran-capoor94]

@johnthagen I didn't know you could do that. Thanks. Now done.

@kiran-capoor94 I noted that nobody replied to your request, at least not here. If you are still interested in helping, please see the list in the first message.

In particular, there are 16 pull requests open at present. Help reviewing these and fixing them up to a acceptable standard appreciated.

Thanks, will review.

[megaleunam]

I would like to help with some problems. i am currently using django-guardian on a project

[ad-m]

@melvyn-sopacua , there are 13 pull requests open at present. Help reviewing these and fixing them up to a acceptable standard appreciated. Notes that you don't see problems are also support. There are also open development issues, e.g. #694. Everybody can take it and provide pull requests to solve it.

[Rainshaw]

@ad-m Maybe you can consider jazzband.co. they are almost a django community.

[thclark]

@ad-m would you like to add me as a maintainer? Maybe give me pypi access too... I could at least triage some of the issue backlog, merge a few PRs and help get a new release out supporting django 3.2?

[ad-m]

Thanks for reporting. I am glad that you want to support the project. I don't remember you, apart from the last review unfortunately.

I propose to start in small steps with PR reviews. In the case of GitHub, anyone can publish reviews. After a certain period of cooperation, we will be able to grant special powers.

[Rainshaw]

Yes, but we may need an active maintainer who is familiar with django. Join jazzband.co is really easy for this.

[thclark]

Thanks for reporting. I am glad that you want to support the project. I don't remember you, apart from the last review unfortunately.

Been around since 2018 and had a lot of use of guardian with various use cases.

I propose to start in small steps with PR reviews. In the case of GitHub, anyone can publish reviews. After a certain period of cooperation, we will be able to grant special powers.

I think I'd second @RainshawGao - joining jazzband will take a lot of effort off your shoulders, ensure that experienced people are able to help with maintenance tasks, and save vetting people yourself (which I understand why you feel the need).

Also: it's worth noting that we can't review PRs unless we're maintainers. The best we can do is chuck in a few comments into the PR conversation which is helpful but not an actual review.

[michael-k]

The best we can do is chuck in a few comments into the PR conversation which is helpful but not an actual review.

Of course it is. The only difference is that if a maintainer adds a LGTM, everybody thinks that (s)he properly reviewed the code. Whereas a LGTM from a random person doesn't tell the maintainers anything. (Was the code properly review? Does the person just want this feature?)

There's no difference between a review from a maintainer or anybody else if it contains proper feedback instead of just a LGTM.

[willstott101]

https://github.com/jazzband/django-authority it less maintained than django-guardian as far as I can tell - and that's already a jazzband project

[sevdog]

Are there any active maintainers of this project at the moment? Is there any planned upcoming release?

[belongwqz]

Such a good project has made up the short board of django authority management, but no one actually maintains it. It is a real pity. I suggest that contact the django official to see if there are resources to support it.

[vecchp]

Hi all, checking in here to see if there is anything that I can do to help move this project to jazzband or getting in touch with Django official.

[johnthagen]

Just a note, Jazzband is not necessarily a panacea to help with maintenance. Over at django-dbbackup we've been having a very hard time with the fact that Jazzband is ultimately controlled by a single person who has very limited time to address project issues. It's actually limited our ability to administer our own project. For some history, see:

• Transfer Out: django-dbbackup jazzband/help#336
• New Organization? jazzband/django-dbbackup#483
• We need more roadies in jazzband jazzband/help#196

[c1505]

Are there any trusted forks of this project that are maintained ?

[brianmay]

The problem is the lack of interested people willing to contribute. Not the lack of forks.

As per above post on moving to Jazzband, while maybe a good move, it isn't going to magically fix that.

Personally, I am only maintaining one project that uses Django, it doesn't use django-guardian, and is not likely to do so anytime in the foreseeable future. So count me out :-)

[c1505]

@brianmay if you have commit access and there is nobody maintaining this, can you write that this project is not maintained in the readme to add some more visibility ?

This is still the top recommendation for django permissions despite not being maintained. It seems like there are users that could be nudged into helping.

[thclark]

Hi @ad-m and @brianmay just touching in here - I'm still a user of django-guardian and as I said above am still very much willing to participate, as I really don't want the project to die.

Long time and experience has taught me that contributing by commenting on, updating or even creating PRs isn't a good use of extremely valuable time unless:

• one has the actual agency to drive the project forward in ways that only official maintainers can (merging, fixing CI/CD, updating code standards and build tools etc etc), or
• one has the confidence that this will be done (eg it's a well established project with sponsorship and several active maintainers who are paid to do it)

Generally OSS projects fail for one of three reasons

1. Owners move onto other projects and it becomes a burden (totally understandable!)
2. Owners want to continue and could make time available but can't afford it (eg freelancers time is valuable and if nobody pays why on earth should they bother)
3. Owners want to continue but can't make time available because they have a job whose description no longer covers this activity.

I feel like there's a mix of all three here but would be interested to hear what your thoughts are?

These reasons can be fixed by

• (1) is best fixed by transferring the project another person or organisation. Octue (more below) is willing to be that organisation.
• (2) is best fixed by generating sponsorship - this in itself is mega hard but see below.
• (3) is best fixed by either transferring the project per (a) or adding additional maintainers (not the same as contributors)

Suggestions

• (1) Octue (more below) is willing to be that organisation. If transferred we would make sure the project is funded (sparsely but enough), overhaul it and reboot regular maintenance.
• (2) I'm fairly confident I can get one of my clients to sponsor you to the tune of a developer-day per month or maybe two, which should be enough to keep ticking reasonably well.
• (3) As per (1), failing that I'm hiring a backend dev right now and can allocate a couple of developer-days per month of their time to maintaining the project (I would also do a day per month for the first few months to get them running well with it)

Solutions (1) and (3) will require ownership-level permissions on both GitHub and PyPi so that we have the agency required to run the project well.

About Octue

You should be incredibly reluctant to give maintenance/ownership privilege to anyone in light of the increasing number of package ecosystem based attacks (and when you're running an app explicitly about security, even more so!). So please do your research first into who people are (you can see my linkedIn here!)to gain a level of confidence (or at least a name you can give to the FBI if things go south!!!) and I'm happy to have a few calls to look at a roadmap for what might be done, and build confidence.

Octue (octue.com) is an Open-Source Software company (not technically a nonprofit but we operate as one) founded in 2013. Our mission is to help scientists and engineers work more effectively with data, and we predominantly work in the renewables and climate space. We work with the International Energy Agency and the International Electrotechnical Commision on matters related to data standardisation and open source.

We currently use django-guardian in multiple applications and we sponsor maintenance on the django-guardian integration for django-unfold.

You can see on github.com/octue that we maintain a number of open-source projects which we fund on a consultancy model (working mostly with engineering companies and universities working in the wind sector), and we're working toward sustainable solutions for funding our OSS efforts.

Of particular relevance will be our django-gcp project which is most like django-guardian, albeit many fewer stars!

Next Steps

If you'd like help in any of the ways suggested (or a mixture, or none but you have another idea of how we could help) please do book a time to talk about it.

Whilst thinking about and googling around this subject today I came across this useful article. Whether me or other people, it's a really useful guide.

[brianmay]

I am somewhat conflicted. I got access to this project by accident - IIRC I complained once to often about problems packaging it for Debian. Which was a dependency of another Python package that I used at the time. As a result, I have never been very interested in it, although I did give releases for a while.

I have not looked at it for years. As a result, I am not familiar at all with the code base. I am not sure I am a good candidate for establishing trust for a future owner. For that matter, just because I have write access to the project, and have had write access for years, does that you really mean you can trust me? Even if you can trust me, can you trust me to keep my account secure? Can I really be trusted to hand this other to somebody else who can be trusted?

There are currently 3 admins + 1 with write access. Do we trust all of these people? Really?

The recent XZ attack has shown that attackers are prepared to spend years generating good commits in order to to establish trust before implementing malicious code. But would they really gain anything from attacking this project? Can't affect OS level systems. Maybe if there was a website the attacker knew used django-guardian, and they were targetting that website. But risky, while spending time establishing trust, the website could be changed not to rely on django-guardian anymore. With django-guardian in limbo for so long, this would be completely justified.

It is perhaps worth noting, that I imagine if one python package had malicious code, with Python's runtime model, it would be easy for it to monkey patch other Python code. Can you do this without it being obvious? Maybe with obfuscated code.

The general idea of having the "django-guardian" organisation is that it is possible to transfer ownership to a new owner.

The advantage of this is that this happens transparently, no need for users to worry.

The disadvantage of this is that this happens transparently, users may not even be aware that ownership has changed. There is no opportunity for users to review changes since the ownership has changed.

i.e. the exact same advantage is the serious disadvantage also.

Even if users were arare that the ownership had changed, would they do any checks? We could make it easier by providing a link to https://github.com/django-guardian/django-guardian/compare with the versions filled in. Users would need to check these are the correct versions.

But you could add information to the top of README.md and CHANGES and other obvious places (which probably is a good idea regardless), and people will do automatic updates and not even notice.

Maybe I am dreaming, but I am more and more inclined to think for a project like django-guardian, users really need to be doing a diff of every single update. Maybe tooling needs to be improved to make this easier. That way:

• We have a lot of eyeballs looking at the code for potential malicious code.
• django-guardian is IMHO very much opinionated piece of code. It would be too easy I think for somebody to make an innocent looking change that really suits their use case, but silently breaks existing code. Reviewing the code means maximum chance of picking this up.

Having said all of the above, I am inclined to think that a dead project is perhaps the worst possible compromise, security wise. If somebody does insert malicious code, there isn't going to be anybody to notice.

How about:

• I give @thclark write access to the project, I think this should allow him to merge pull requests.

• For the "devel" branch, I turn on "Require a pull request before merging", so all changes need to have a transparent pull request.

• Also turn on "Require status checks to pass before merging", "Require conversation resolution before merging". These seem like good things to have.

• I could also set "Require approvals" to 2, so somebody else has to approve the pull request also. I think the rules are anybody can approve except the last person who pushed. So the person merging can approve also. But as much as this might be a good thing, need to be sure it is not a blocker also.

• Another possibility might be "Require review from Code Owners", but would need to specify a code owner here.

In maybe a years time (for example), we can review, and upgrade/downgrade as required.