The Orekit team is committed to creating high quality software and providing users and contributors with the best possible support within its means. Wanting to do so is good; verifying by objective facts that it is done is better! That is why the CII self-assessment program seems very interesting to me. Out of curiosity, I tried to evaluate the practices of the Orekit project. It’s not so bad!
But these are only the criteria for the bronze level. Beyond that, there are the silver and gold levels.
If you do not agree with my self-assessment, please do not hesitate to suggest corrections.
Have a nice day!
Looks worthwhile. Thanks for filling it out. Looks like the things we’re missing are a published procedure for reporting security issues and a developer who understands software security. The former seems like a good idea and is a relatively easy update to the readme. The latter seems subjective, do we just read the linked paper and then check the box?
Made the modification to the Readme.
In the case of Orekit, a “simple” library which runs without any privilege and does not process sensitive data, many of the practices recommended by the CII Best Practices Program or by Saltzer and Schroeder seem out of scope to me.
Therefore, from my point of view, we just need at least one contributor who is aware of best coding practices and who monitors vulnerabilities affecting Java. The design and code quality of Orekit proves that the team knows the best coding practices. And if I’m not mistaken, you do the vulnerability monitoring since you’ve already reported two vulnerabilities affecting Orekit. For me, the requirements on this point are therefore fulfilled.
I will update the form.
Yes! I am proud to announce that Orekit follows the best practices!