Ghostwriter

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The project publishes release candidates for review. Here is a recent example: https://github.com/GhostManager/Ghostwriter/releases/tag/2.2-rc1

Repository on GitHub, which uses git. git is distributed.

The project follows GitHub's guidelines for Semantic Versioning when naming versions. Each release has a unique version number and identifier (e.g., v2.2.0, v2.2.1-rc1).

https://github.com/GhostManager/Ghostwriter/releases

The project tags releases using git tags: https://github.com/GhostManager/Ghostwriter/releases

The project publishes a CHANGELOG.RST, release notes in the release descriptions, and an easier to read, searchable version on the wiki:

https://github.com/GhostManager/Ghostwriter/releases/tag/v2.2.1 https://www.ghostwriter.wiki/change-logs/28-may-2021-v2.2.1 https://github.com/GhostManager/Ghostwriter/blob/master/DOCS/CHANGELOG.RST

There have been no major vulnerabilities like this to report, but the release notes have acknowledged when changes were the result of an identified security issue in a dependency. For example:

Updated TinyMCE WYSIWYG editor and related JavaScript to v5.7.0 * Resolved potential Cross-Site Scripting vulnerability discovered in previous version

The project uses GitHub Issues as documented here: https://www.ghostwriter.wiki/known-issues-and-faq/getting-help-with-a-problem

The project uses a public Trello board to track issues and features: https://trello.com/b/sF4om6Fy/ghostwriter

The project team always acknowledges GitHub Issues, even if the issue cannot be fixed immediately. The team cannot always respond right away, but does their best to keep up with issues and respond with complete answers.

https://github.com/GhostManager/Ghostwriter/issues

The project team always acknowledges GitHub Issues, even if the enhancement cannot be implemented immediately. The team cannot always respond right away, but does their best to keep up with issues and respond with complete answers.

https://github.com/GhostManager/Ghostwriter/issues

All reports are in GitHub Issues which are searchable for later review.

https://github.com/GhostManager/Ghostwriter/issues

A process for reporting a bug or security vulnerability is outlined in the wiki: https://www.ghostwriter.wiki/known-issues-and-faq/getting-help-with-a-problem

The project team discusses these issues openly. There has been no need to discuss anything in private, but there is a method of private contact. Anyone may contact the lead developer at chris.maddalena@protonmail.com (as published on GitHub).

https://github.com/chrismaddalena

The team has responded within days of reports received in the project's lifetime. There have been no vulnerability reports in the past 6 months, but there was one Dependabot alert for TinyMCE that the team addressed immediately.

All pieces of the project that require any building are managed and built by docker-compose: https://www.ghostwriter.wiki/getting-started/installation

The project uses common tools and frameworks like Docker, Django, PostreSQL, and Redis.

All project components are open-source and freely available, including components used to build or run the project.

The project follows the Django project's recommended practices for using Django's TestCase unit tests. Test coverage is monitored using Python coverage and Codecov.

https://www.ghostwriter.wiki/development/testing-code https://app.codecov.io/gh/ghostmanager/Ghostwriter

All tests are invoked using the standard Django (or Python coverage) commands as documented by those projects and in the Ghostwriter wiki:

https://www.ghostwriter.wiki/development/testing-code

Tests are run against all code, regardless of the branch. GitHub Actions runs the full suite against all pull requests or commits to master. Further, the workflow must pass before the code can be committed.

GitHub Actions performs a complete build and install of Docker images, runs through the "getting started" instructions to prep the database, and runs all unit tests.

The project has started tracking testing coverage with Codecov so it is publicly viewable and updated with each push: https://app.codecov.io/gh/ghostmanager/Ghostwriter

Testing steps and policy is documented here: https://www.ghostwriter.wiki/development/testing-code

No part of the project requires compilation like this, so most of this is handled by the test cases.

The project uses a documented mix of pre-commit hooks, IDE settings, and linter settings (Python Black and Flake8) to ensure code quality. Quality is also being monitored by Code Factor to guide the team towards problem areas.

https://www.ghostwriter.wiki/coding-style-guide/style-guide https://www.codefactor.io/repository/github/ghostmanager/ghostwriter/issues

As mentioned above, no part of this project requires compilation, so this does not appear to be applicable. Otherwise, it is met by way of catching these common mistakes before the code is committed. Any Python compilation issues would prevent Django from functioning and prevent a release.

The project team is actively working towards providing user-friendly warnings and help messages when various runtime errors occur. For example, when attempting to generate a Microsoft Word document with Jinja2 a user may try to divide by zero. Rather than pass along the Jinja2 compilation error, the project filters it and produces a friendlier message explaining how to resolve the issue in their template.

The lead developer, Christopher Maddalena, is a security consultant with a background in Computer Science, web application security testing, and secure software development.

In addition to the lead developer, the other primary contributors also have background in information security, web application testing, secure code reviews, and more.

The project does not require much cryptography, but Django uses it for securing user passwords and sensitive information. Ghostwriter uses the latest recommended cryptography libraries for this.

Django documents it here: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/

The project does not implement its own cryptography. Only the major supported Python cryptography libraries are used.

The project uses Django's cryptography implementations which is FLOSS: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/

The project uses Django's cryptography implementations which follows these standards: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/

The project uses Django's cryptography implementations which uses the recommended, standard Python libraries and their algorithms: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/

The project uses Django's cryptography implementations which uses the recommended, standard Python libraries and their algorithms: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/

The project uses Django's security recommendations and features. Where this would most likely come into play, HTTPS traffic, the project uses an nginx server and Django manages the SSL as described here.

https://docs.djangoproject.com/en/3.2/topics/security/#ssl-https

The project uses Django's password management and user authentication mechanisms described here: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/

The project uses Django's password management and user authentication mechanisms described here: https://docs.djangoproject.com/en/3.2/topics/auth/passwords/

The project uses HTTPS and WebSockets Secure for communication. Here is the nginx.conf file for the webserver with the SSL configuration:

https://github.com/GhostManager/Ghostwriter/blob/master/compose/production/nginx/nginx.conf

The project does not send or receive cryptographic material.

There are no unpatched public vulnerabilities in the project's codebase.

The project team has addressed all reported vulnerabilities. In addition to that, the project team has paid a third party to perform a penetration test against the Ghostwriter production server and features and fixed all identified issues.

There is no sensitive information stored in the project's code repository. This is monitored using manual validation and tools like the OSSF's Scorecard (https://github.com/ossf/scorecard/).

The project uses GitHub's CodeQL app and CodeQL for VSCode:

https://github.com/github/codeql https://codeql.github.com/docs/codeql-for-visual-studio-code/setting-up-codeql-in-visual-studio-code/

GitHub's CodeQL app searches for common vulnerabilities.

None have been found, but identified vulnerabilities would be addressed with the same alacrity as mentioned previously.

The CodeQL workflow fires with each commit and pull request.

The project team tests and fuzzes Ghostwriter using Burp Suite Pro, a web application testing tool, to test changes.

The project does not contain any code written in a memory-unsafe language, but the team does fuzz the web application and back-end to identify potential issues that might cause serious errors or expose the potential for misuse of a feature.

The project team uses rulesets published by PortSwigger, the creator of Burp Suite, to fuzz the Ghostwriter server for automated dynamic testing.

None have been found, but identified vulnerabilities would be addressed with the same alacrity as mentioned previously.