Contributing to Themis #
Themis is an open-source, Apache 2 licensed software, maintained by Cossack Labs for building reliable cryptography in our products: Acra, Hermes and Toughbase. You can hack it in any way you want and contribute things back if you need something more than what we provide.
As a development company, we focus on implementing features that are important to our products but would gladly spend some time to make Themis useful for everybody.
Every commit that goes into the master branch is audited and reviewed by somebody from Cossack Labs, don’t be surprised if the review takes longer than you expect.
I’d like to help somehow, but don’t know what will be useful. What should I do? #
Issues marked as “enhancement” are a great place to start.
If you’d like to work on independent parts, like implement a useful new method or build a language wrapper for a language or platform we don’t have and don’t even plan yet – just go ahead and let us know when you finish.
If you’d like to participate in the core development more closely, get in touch.
Development quickstart #
Getting ready #
Read the Themis architecture section of the documentation, make sure that you understand everything (or at least you start thinking you understand everything).
Brace yourself for a lengthy session of reading the source code.
Writing code #
Themis Core is written in portable C so we kindly ask you to stick to the coding style you see.
The same goes for the language wrappers written in high-level languages.
Themis Core uses object-oriented design patterns.
The first parameter in most calls is an object context pointer passed back and forth through all calls of related functions (object methods).
Each object has a “constructor” –
themis_object_create()method that allocates an object in the memory, initialises it, and returns the pointer to it.
Each object also has a “destructor” –
themis_object_destroy()method that accepts an object context pointer, correctly destroys its members, and frees the memory.
Keep the code working for everyone.
We wrote high-level wrappers and examples in the way we think would be the most beneficial to the end-users. However, we’re boring system-level programmers who could’ve missed some important style-related things.
Feel free to introduce stylistic or ergonomic changes to anything in the high-level area, just make sure that they work the way they were supposed to initially and any existing application code does not break.
Submitting changes #
Fork the repository on GitHub and
git clonethe master branch.
Modify the source to fix or improve something. Supply the change with a test if you can.
Create a GitHub pull request (or send us as a patch via email, if you insist).
Wait for the team members to review, accept or discuss the changes you’re proposing.
In a perfect world, you would also raise an issue in GitHub Issues to make sure no duplicate work takes place, but that’s up to you :)