Hello eerimoq

[IT-magician]

Hello eerimoq,

I hope this message finds you well. I noticed that you are no longer actively maintaining or using this project. As someone who regularly works with x.680-x.683 documents and has a strong background in text parsing, I believe I can contribute significantly to this project.

I am particularly interested in extending the current functionality to include web-based features. I have already begun some work in this area and would like to continue improving and maintaining the project.

Would you be open to granting me the necessary permissions to manage and develop this project further? This would allow me to make direct contributions without the need for continuous PR requests.

Thank you for considering my request. I am excited about the possibility of contributing to this project and helping it grow.

Best regards, taehun.kim

[decryphe]

I would second some form of new maintenance, as this project is for all intents and purposes currently unmaintained.

We also use asn1tools quite extensively at work, so I could probably dedicate a bit of time to asn1tools semi-regularly, and also run into missing functionality or bugs at times. Our Firmware devs use asn1tools, on the backend-side we use rasn, which I have contributed to, so I have some shared knowledge from multiple ASN.1 library implementations.

[eerimoq]

A new maintainer is needed, yeah :) wonder who I can trust :)

[decryphe]

I wonder if this could be combined with the efforts done over at https://github.com/librasn who have been very active.

Off the top of my head, I could see benefits in combining testing efforts between the libraries, using one to test the other and vice-versa.

Maybe @XAMPPRocky could pitch in if this would be an opportunity to combine efforts on ASN.1 libraries.

[XAMPPRocky]

Thank you for the mention. I have actually been experimenting with adding python bindings to rasn recently, it's something I've wanted to have since very early in the project. I've put up the bindings as a PR (which is still very wip, doesn't even compile), so people can look and give opinions on syntax and API design as I'm not someone who primarily writes Python.

In regards to where we could collaborate, we can work on the bindings, and asn1tools could switch to generating code which generates rasn bindings as a means of offloading the backend work of the actual encoding/decoding. But I would want to keep the python bindings for rasn as it's own independent library, as I don't want to require API capability with asn1tools, not that there's anything wrong with the API, I just want to be able to ensure the bindings can leverage both modern python idioms and rasn's functionality the best it can be. But that is why I also suggest that being able to use the library in asn1tools so that it can be offered as a different backend would enable you to significantly reduce the amount of complexity in maintaining asn1tools while preserving the API for existing users.

librasn/rasn#435

[eerimoq]

Just let me know if anyone want to become a maintainer and I'll consider it. =)

[XAMPPRocky]

FWIW in my experience if there isn't already someone who has been an active contributor who is a suitable candidate it's often better to deprecate or announce end of maintenance and let people fork the work, to prevent a supply chain vulnerabilities that may occur in trusting a new maintainer. Up to you of course, your project.