Announcement: About the development of Ktra in future

Dear all,

As you all know Ktra is now under inactive development.
I have not give it up but it is true that I cannot make time to develop for some time because of my main job is too busy.

Thus I decided to look for co-developers to continue with Ktra development.
However, it is not fixed that to make Ktra be an organized project or invite some people. This is the first attempt for me, it might puzzle you, please let me know you think.

Regards, Henrique Sasaki Yuya

Hello,

As I mentioned in #29, I intend to use ktra in production for my projects, and I'd really like to make it so using a helm deployment (or a docker-compose one) is possible and easy. I also have a few ideas to implement for our specific use case, that could be useful for everyone (my first idea, beside the customizable login prefix, would be to add a /health endpoint returning the version and maybe some extra status information, for Kubernetes based deployment "healthProbe" and "readinessProbe").

I don't have a lot of experience either contributing to open source projects, if you want to make a background check you can browse my last collaborative open experiences in

• Neovim-qt but it's been a while
• Doom Emacs
• and probably more importantly whenever I try to communicate with people. Those are all quite recent examples

Regards, Gerry

Hi,

I am willing to be a contributor.

I am planning to deploy a private registry for our company, but some features is lacking:

1. authorize call to all api including crate download endpoint. There is a rust-lang/rfc#3139 for alternative registry authorization and the corresponding implementation rust-lang/cargo#10592 is in review stage.
2. users of registry can only see/download crates that they are given access to. AFAIC, there is 2 ways to achive this goal:
   • use sparse index as described in rust-lang/rfcs#2789. In this way, there is no a list of crates and users can only access crates that they know.
   • implement a more complicated user management that allow to restrict download access. In this way, users can still see all crates but they can only download granted crates I am thinking about integrating gitlab/github/... access control, that users can only access crates granted on gitlab/github/...

I am currently working on this and has already added sparse index support as in PR #49.

I'll try to finish my OpenID PR soon-ish, got absolutely swamped with work recently so I didn't take time to finish it, I'll try to find time this week-end. It will probably only support gitlab for now (I won't have time to look into github docs to see how non-compliant they are and the changes it implies), with an update of the book.

It won't help with the download management matter (I need to read that RFC to see what it implies), but it's probably a good first step.

@gagbo I have tried your openid and fired a PR doing some refactor. The openid feature works like a charm, nice works!