You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

74 lines
3.9 KiB

4 years ago
5 years ago
  1. # Contributing to ACMEd
  2. ## Testing and bug report
  3. The first way to help is to actually use the software and [report any bug you encounter](https://github.com/breard-r/acmed/issues). Do not hesitate to test the limits.
  4. ## Improving the language
  5. Since the author is not a native English speaker, some of the texts used in this project should be fixed. This is especially true on the man pages as well as the [wiki](https://github.com/breard-r/acmed-wiki).
  6. ## Package it for your favorite system
  7. A great way to contribute to the project is to package it. You can check the packages status on [Repology](https://repology.org/project/acmed/versions).
  8. ## Work on dependencies
  9. ### rust-openssl
  10. See [issue #36](https://github.com/breard-r/acmed/issues/36).
  11. ### botan and botan-sys
  12. Although Botan isn't a dependency, it is considered for the replacement of OpenSSL as the default cryptographic API (although OpenSSL will be kept as an alternative). But before this can be done, the Botan crate need to support a few features:
  13. - Implement `Clone` for `botan::Privkey`.
  14. - Access to a certificate's expiration time (via `botan_sys::botan_x509_cert_get_time_expires`).
  15. - Access to a certificate's subject's alt names.
  16. - Self-signed certificate generation (via `botan_sys::botan_x509_cert_gen_selfsigned`).
  17. - CSR (requires to add bindings to [create_cert_req](https://botan.randombit.net/handbook/api_ref/x509.html#creating-pkcs-10-requests)) with DER export.
  18. If you know C/C++ and are highly motivated:
  19. 1. Implement Botan's FFI for TLS.
  20. 2. Implement TLS bindings in the `botan-sys` crate.
  21. 3. Implement a TLS abstraction in the `botan` crate.
  22. ### attohttpc
  23. Add an optional Botan support as the cryptographic library.
  24. ### Find or create a good template engine
  25. As reported in [issue #8](https://github.com/breard-r/acmed/issues/8), there is currently no perfect template engine. A good way to help improve ACMEd would be to find or create one that supports all the listed requirements.
  26. ## Improving the code
  27. As a one-man project, it has several goals already set but not explicitly written in an issue or any other follow-up file. It will not be the case before version 1.0 is released since everything may change at any moment. Therefore, it is recommended to request change instead of implementing them, this way we can discuss how things should be made.
  28. If you really want to submit a pull request, please :
  29. - document your changes in the man pages and the `CHANGELOG.md` file
  30. - write as much tests as you can
  31. - run `cargo test` and be sure every test pass
  32. - format your code using [rustfmt](https://github.com/rust-lang/rustfmt)
  33. - be sure not to have any warning when compiling
  34. - run [clippy](https://github.com/rust-lang/rust-clippy) and fix any issue
  35. - refrain from including a new dependency (crates having `ring` in their dependency tree are a no-go, see #2)
  36. - beware of potential repercussions on the default hooks: those should remain usable
  37. Not following the rules above will delay the merge since they will have to be fixed first.
  38. ## Author vs. contributor
  39. Some people have troubles seeing the difference between an author and a contributor. Here is how it is seen withing this project.
  40. A contributor is a person who helps the project in various ways whenever she or he wants. As such, a contributor does not have any obligation other than being respectful and open-minded. People who wrote code that have been accepted are automatically listed in the [contributors page](https://github.com/breard-r/acmed/graphs/contributors). The creation of a file with the names of people contributing outside of the code base will be studied upon request from such people.
  41. An author is a person who has some responsibilities on the project. Authors are expected to contribute on a regular basis, decide architectural choices, enforce copyright issues and so on. One does not grant himself the author status, it is given by the others authors after having discussed the request.