Maintainership of OpenCTM itself #5
Description
For background, I’m one of the primary maintainers of the python-trimesh package in Fedora.
As a dependency for trimesh via its recommend extra, I also packaged this repository, https://github.com/trimesh/openctm, as python-openctm.
Furthermore, since we avoid bundling things that could be system libraries, I packaged https://github.com/Danny02/OpenCTM – which this Python extension includes as a git submodule and for which this Python extension is a wrapper – as a separate OpenCTM package, and the python-openctm in Fedora uses the resulting system shared library.
While reviewing and packaging OpenCTM, I submitted several issues and a number of PR’s:
- Fix possible double-free of temporary indices buffer in compressMG1.c Danny02/OpenCTM#17
- Update to the current release of rply, 1.1.4 Danny02/OpenCTM#18
- Make the Makefile.linux build system flexible enough for distribution packaging Danny02/OpenCTM#19
- Add a .desktop file and SVG icon Danny02/OpenCTM#20
- Fix out-of-bounds access when exporting an empty mesh to CTM (fix #21) Danny02/OpenCTM#22
- Make TrimString() safe for empty strings (fix #23) Danny02/OpenCTM#24
About two weeks ago, @Danny02 noticed these PR’s and sent me a very polite private email, which included a few points that I will try to paraphrase accurately:
- @Danny02 was not involved in the original OpenCTM project, and never intended https://github.com/Danny02/OpenCTM to be a primary upstream for it
- https://sourceforge.net/projects/openctm/ (which is certainly inactive) should still be viewed as the “real” upstream
@Danny02 suggested that I might want to start my own fork based on https://sourceforge.net/projects/openctm/ and collect the relevant patches there, effectively starting a maintained “friendly fork” of the original OpenCTM project. I’m not opposed to that idea in principle, but I am concerned that I do not have the time and interest to be a responsible maintainer. I’m happy to keep fixing issues with new compilers and minor bugs as I encounter them, but I’m not prepared to audit OpenCTM in detail, improve tests, study the actual CTM file format, or commit to fixing any major bugs. For me, this is just a dependency for a (weak) dependency for a package I co-maintain.
To add to this, I was contacted about a week ago by two people who discovered a couple of security vulnerabilities in OpenCTM and wanted to figure out to whom they could make a responsible disclosure.
All of this is to raise the issue of just who, if anyone, is prepared to maintain OpenCTM. I don’t know if this is something @mikedh would be willing to do under the auspices of trimesh, or not – but at least this issue provides a place to talk about it.