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.

[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:

• https://github.com/jazzband/help/issues/336
• https://github.com/jazzband/django-dbbackup/issues/483
• https://github.com/jazzband/help/issues/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.

[thclark]

Hi @brianmay that would be a wise set of steps to start with, I think, thank you (sorry I missed the notification that you'd tagged me so have only just seen this).

I'm away this week and will be in touch when I'm back but please feel free to send the invite, or book a timeslot at the link above to go through things and we'll set up access then.

Best,

Tom

[brianmay]

OK, I think I have made the changes. I can't test it... if it isn't working (e.g. you can't do something you need to be able to do) please let me know, and I will fix.

[cmaggiulli]

I am currently leading a large project that uses guardian/DRF. We forked guardian to fix perf issues stemming from relatively large GOPs, intermingling uuid and int pks, intermingling generic and direct fk impl.

I’m maybe skilled enough to be a minor maintainer and I’m certainly willing to do so. I do not currently have the time ( or skill ) to own the project but I’m certainly willing to be an active minor maintainer

[thclark]

@brianmay thanks for the access just a quick update - I got quite ill for the last couple of months which is why I went radio silent. But just some reassurance that I've not fundamentally gone away and the project is still important to me!

[thclark]

@brianmay just a check, can you apply write access again please? I'm not sure it's taken because in this pr the checks aren't passing.

Another problem we have is that two reviewers both with write access need to review a PR - github doesn't seem to be recognising me as having write access, plus we'll need another person actively triaging who also has write access.

Perhaps we could also give @cmaggiulli write access to have an extra person triaging?

[cmaggiulli]

@thclark I'm definitely willing to. I'll monitor for @'s.

[brianmay]

All done. I think.

[cmaggiulli]

@brianmay @thclark invitation received and accepted. I’ll make sure the tests run on my local and look through some of the recently closer MRs to see if I can decipher a branching strategy / overall workflow. If there are any issues you’d like triaged let me know I will assist as directed otherwise I’ll comb through the open issues for things that appear minor. If there’s any standards or contributor processes I should follow please also let me know ( not done reading through this thread yet so maybe that’s answered ). I’m already watching the Django-guardian SO tag

Thanks!

[thclark]

We're slowly but surely getting there, I've not got an approved review up on this PR - @cmaggiulli any chance you could review that same PR? Assuming your review counds we should then be able to get it merged as a proof of concept of our workflow.

[BonaFideIT]

Hey there, thanks for your work so far. We would be interested in helping review changes in guardian. We use guardian in one of our bigger customer projects and maintain a fork to enable some features we would like to upstream. Relevant pull requests have been opened or will be opened soon.

Would it be possible to add us as a reviewer? We are able to provide authentication as a Germany based limited liability company if that helps.

django: https://code.djangoproject.com/query?reporter=BonaFideIT

django-guardian: https://github.com/django-guardian/django-guardian/pull/825

[brianmay]

@BonaFideIT I think I have given you access to reviewer.

Actually github permissions confused me, please let me know if it works.

[thclark]

@brianmay @ad-m @johnthagen

We've recently managed to get changes merged to the devel branch, but they're not released yet as there's no process set up.

I've been triaging issues (closing issues that are outdated or not enough info). But, I still can't access any repository settings, so my hands are tied in getting these changes out, and honestly this is still super frustrating.

If anyone is ready and willing to make me an admin (both on here and on pypi), I'll:

• set up an automated release process,
• add sensible labels to triage all the issues,
• and add some issue templates to help guide people making issues,
• add a roadmap and help people prioritise those issues, and
• establish a working group django-guardian working group, for example meeting quarterly for 2hrs, so we have a core group of admins who know and trust one another to take the project forward.

As a reviewer, it's clear I can help still, but we need to actively push development forward, and they need admin privilege. Otherwise there's just no agency to do anything useful.

Please????? This project is still dying and it's totally needless.

[johnthagen]

@ad-m I've reviewed @thclark's history of contributions and agree that there is enough there to give him trust as an admin of this project. I do not have the ability to that (@brianmay are you an admin or only have write access to django-guardian GitHub? Are you penguin_brian on PyPI and thus have admin rights there to give @thclark the ability to publish?)

• https://pypi.org/project/django-guardian/

I propose that @brianmay give @thclark admin rights on django-guardian as the current situation is untenable. I'd like to hear from @cmaggiulli and @BonaFideIT too.

If this is not possible and @ad-m is the only person who can make these changes and has chosen to move on (which is understandable) then I think the only option is for @thclark to fork this repo under a new django-guardian2 group. We can then move on to maintaining and publishing it there, and we leave a notice in this pinned issue pointing users to that project.

[brianmay]

I have admin for github, PyPi, and readthedocs. Anything else I have forgotten?

If you wanted to replace readthedocs with something else I would be happy with that (e.g. maybe github pages). I personally find having a separate build process a pain, and it can break without notice. In fact it looks like readthedocs builds have been broken for the last year and nobody noticed.

Will wait several days before changing permissions, to give others a chance to respond.

Currently there are three admins for all these sites:

• ad-m
• lukaszb
• me

[brianmay]

If we are going to wake this project up from the dead, might be worth saying so in this thread also: https://www.reddit.com/r/django/comments/1cgu0ex/djangoguardians_is_no_longer_being_maintained/ (is the 3rd search result in Google).

[thclark]

If we are going to wake this project up from the dead, might be worth saying so in this thread also: https://www.reddit.com/r/django/comments/1cgu0ex/djangoguardians_is_no_longer_being_maintained/ (is the 3rd search result in Google).

I already did, some months back when we were getting some momentum, but will add another comment there once we're released with the latest dependency support.

[brianmay]

@lukaszb Can you please make me an owner of the django-guardian organization? Without this I can't add @thclark to the organization, which is required to be added to the admin group.

@thclark I have given you maintain access to the project, which hopefully should be enough for now. I can give you admin to PyPI and readthedocs, I just need to get your username for these services first.

[lukaszb]

@brianmay sent invite to org owners

[brianmay]

@lukaszb Not seeing any difference. Oh I see, I think maybe you added me to the "Owners team". Not sure what this does actually. Maybe nothing, I don't think we have that team configured anywhere.

But I think my membership needs to be changed to "Owner" here: https://github.com/orgs/django-guardian/people

Does this make sense?

[BonaFideIT]

@johnthagen Thank you for asking us for our input.

As already mentioned, we would like Guardian to be properly maintained again and for there to be new versions. For this we need people who have experience with such projects, who can be trusted and who have enough time.

We are fine with @thclark becoming admin, but we would also like to point out that we are interested in a policy on PR merge (e.g. at least the tests must always run successfully) and also on release planning. We don't want the project to be taken over by just one person with full decision-making power.

In general, we should not make decisions hastily and give everyone the chance to react. We would therefore like to suggest waiting at least 1 week for questions or mentions until the person(s) can have their chance to respond.

[thclark]

@lukaszb I think @brianmay is right, it seems to be needed at the the organisation level rather than the repository level (eg to do things with github actions and with projects etc). It looks like @ad-m is the only person in the organisation though, do you have Owner privilege @ad-m?

@BonaFideIT totally agree, this isn't the kind of project where you'd want to be merging ad-hoc, you can break a lot of people's apps that way, or (worse) add holes in people's permissions layer.

Assuming that @ad-m is OK to add us as organisation co-owners, I think the best way of accelerating through this transition and settling down to normal is to establish a Working Group, which should meet quarterly for two hours - not too onerous for the maintainers but gives a huge amount of transparency and oversight as well as a regular touchpoint to move things forward.

Doodle poll - establishing a working group

For @brianmay @lukaszb @cmaggiulli @johnthagen @ad-m @BonaFideIT and anyone else who is either:

• interesting in continuing to maintain the project, or
• interested in handing over

Please feel free to fill out this doodle to choose a best time for the first working group meeting.

Agenda

• Introductions

  • 1 minute each, who you are and how you use guardian

• Oversight Policies

  • License
  • Contributing
  • Security policy and reporting process

• Release and CI workflows

  • CI requirements and triggers
  • Merge criteria and flow
  • CD / Release criteria and flow

• Other best practices

  • Code style & standards
  • Conventional commits
  • Test framework
  • Semantic versioning (already used but could be formalised)

• Release planning (2.5)

  • Contents
  • Is it urgent enough to do an ad-hoc release before putting in place all the above?

[johnthagen]

Since @ad-m may have muted this repository/thread, his GitHub profile

• https://github.com/ad-m

Has some contact information

• https://ochrona.jawne.info.pl/about/

Perhaps after a few days, someone could reach out to him directly to see if he's willing to help transition the project.

[brianmay]

@brianmay sent invite to org owners

I got confused with this response. Did he mean to say that I should send an invite? Or what? It sounds like he sent an invite, but maybe I misunderstood.

The only owner of the organization is @lukaszb. The website lists @ad-m as a member, just like me. This project was moved fromlukaszb/django-guardian, and I got invited to the new org on 2015-11-12 so that makes sense.

It is recommended practice that all orgs have at least two owners, but unfortunately we only have one.

Unfortunately, I can't invite new people to the organization, without owner access (not that I can see anyway...). And this in turn means I can't add new people to the Admin group. Hence the reason why I asked @lukaszb for help.

There might be other options we can try, but am hoping that @lukaszb will respond again...

[thclark]

@brianmay sent invite to org owners

I got confused with this response. Did he mean to say that I should send an invite? Or what? It sounds like he sent an invite, but maybe I misunderstood.

Something happened, as I can now see repository settings but there's only a few, mostly things are at the org level.

The only owner of the organization is @lukaszb. The website lists @ad-m as a member, just like me. This project was moved fromlukaszb/django-guardian, and I got invited to the new org on 2015-11-12 so that makes sense.

Ah, right, I see a slightly different view with only ad-b in it.

[lukaszb]

@brianmay yeah, I've invited you to org but also needed to change role after you've accepted invitation. Couldn't add you to owners in single step. Weird process but please check now - you should be able to perform actions you want

[brianmay]

Yes, it looks like I am an owner now.

[thclark]

Great, and I'm a member now. Thanks @brianmay and @lukaszb - Brian, if you could bump me to owner that'd be great.

[thclark]

Once again, all, please feel free to fill out the link below to help choose a time for a working group meeting

All - Please fill out this doodle to choose a best time for the first working group meeting.