fedfred

The project maintains older versions of the product and provides an upgrade path to newer versions. The CHANGELOG.md file (https://github.com/nikhilxsunder/fedfred/blob/main/CHANGELOG.md) documents all changes, including new features, bug fixes, and deprecated functionality, to help users understand what has changed between versions.

For major updates that introduce breaking changes, the project follows Semantic Versioning and includes detailed instructions in the CHANGELOG.md to guide users through the upgrade process. This ensures users can either continue using older versions or transition smoothly to newer ones.

https://github.com/nikhilxsunder/fedfred/issues

The project has not resolved any reported vulnerabilities in the last 12 months. Therefore, this criterion is marked as Not Applicable (N/A).

For future reference, the project documents vulnerability reports and credits reporters in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

The project has a documented process for responding to vulnerability reports in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

The process includes the following steps:

1. Reporting: Vulnerabilities must be reported via email to nsunder724@gmail.com, not through public GitHub issues.
2. Acknowledgment: The project team will acknowledge receipt of the report within 48 hours.
3. Verification: The team will verify the vulnerability and assess its impact.
4. Remediation: A fix will be developed and tested.
5. Disclosure: The team will coordinate with the reporter on the disclosure timeline and credit the reporter unless anonymity is requested.

This ensures a clear and structured approach to handling vulnerabilities.

The project identifies and enforces coding standards in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

The project adheres to the following coding style guides:

1. PEP 8: The official Python style guide for code readability and consistency.
2. PEP 257: For docstring conventions, including parameter descriptions, return values, and examples.
3. Type Hints (PEP 484): All functions must include type annotations for parameters and return values.

The CONTRIBUTING.md file also specifies the use of tools like pylint, mypy, and bandit to enforce these standards and ensure compliance. Contributors are required to run these tools before submitting pull requests.

The project automatically enforces its selected coding styles using the following tools, as documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

1. Pylint: Enforces PEP 8 compliance and general code quality. A minimum score of 9.0+ is required for all code.
2. Mypy: Enforces type checking to ensure compliance with PEP 484.
3. Bandit: Performs security-focused static analysis to identify common security issues.

These tools are integrated into the development workflow via pre-commit hooks and GitHub Actions workflows. All pull requests are automatically checked for compliance, and any exceptions must be explicitly documented in the code with comments explaining the rationale.

The project does not generate native binaries, as it is a Python library. Therefore, this criterion is marked as Not Applicable (N/A).

The project is a Python library and does not involve a build or installation system that generates native binaries. Therefore, this criterion is marked as Not Applicable (N/A).

The project is a Python library and does not use a build system that involves recursive builds or subdirectory dependencies. Therefore, this criterion is marked as Not Applicable (N/A).

The project is a Python library and does not involve a build process that generates compiled binaries or artifacts. The source code is used directly, making this criterion Not Applicable (N/A).

The project provides an easy way to install and uninstall the software using commonly-used conventions:

Using pip: The software can be installed and uninstalled via the Python package manager pip, which is widely used in the Python ecosystem.

Installation: pip install fedfred Uninstallation: pip uninstall fedfred Using conda: The software is available on Conda-Forge, allowing installation and uninstallation via the conda package manager.

Installation: conda install -c conda-forge fedfred Uninstallation: conda remove fedfred Detailed installation instructions are documented in the README.md file: https://github.com/nikhilxsunder/fedfred/blob/main/README.md and the installation.rst file in the documentation: https://nikhilxsunder.github.io/fedfred/installation/.

The installation system for end-users MUST honor standard conventions for selecting the location where built artifacts are written to at installation time. For example, if it installs files on a POSIX system it MUST honor the DESTDIR environment variable. If there is no installation system or no standard convention, select "not applicable" (N/A). [installation_standard_variables]

The project provides a quick and straightforward way for developers to install all necessary dependencies and set up the development environment using commonly-used conventions. This is documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

Development Setup:

1. Using Poetry:

   • Clone the repository: git clone https://github.com/nikhilxsunder/fedfred.git
   • Navigate to the project directory: cd fedfred
   • Install dependencies: poetry install
   • Run tests: poetry run pytest

2. Using Conda:

   • Clone the repository: git clone https://github.com/nikhilxsunder/fedfred.git
   • Navigate to the project directory: cd fedfred
   • Create a Conda environment: conda create -n fedfred-dev python=3.9
   • Activate the environment: conda activate fedfred-dev
   • Install dependencies: pip install -e ".[dev,types]"
   • Run tests: pytest

These steps ensure that developers can quickly set up the environment and run tests to start contributing to the project.

The project lists its external dependencies in a computer-processable way using pyproject.toml and poetry.lock files. These files are compatible with the Poetry package manager and specify all required dependencies, including their versions and groups (e.g., main, dev).

The pyproject.toml file can be found at: https://github.com/nikhilxsunder/fedfred/blob/main/pyproject.toml.
The poetry.lock file can be found at: https://github.com/nikhilxsunder/fedfred/blob/main/poetry.lock.

The project monitors its external dependencies for known vulnerabilities using automated tools and processes:

GitHub Dependabot: Automatically scans dependencies for vulnerabilities and creates pull requests to update them when issues are detected. CodeQL: Performs security analysis on the codebase, including dependency vulnerabilities. Poetry: Dependency management ensures that only compatible and secure versions of packages are installed. These tools are integrated into the project's workflows and run regularly to ensure that vulnerabilities are detected and addressed promptly. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

The project meets this criterion by using standard Python package management systems, such as pip and poetry, to manage external dependencies. All reused components are listed in the pyproject.toml and poetry.lock files, making it easy to identify and update them. These files ensure that dependencies are managed in a centralized and consistent manner.

Additionally, the project uses GitHub Dependabot to automatically monitor and suggest updates for dependencies when vulnerabilities or new versions are detected. For more details, see the pyproject.toml file: https://github.com/nikhilxsunder/fedfred/blob/main/pyproject.toml.

The project avoids using deprecated or obsolete functions and APIs by adhering to modern Python standards and regularly updating its dependencies. The project uses tools like pylint, mypy, and bandit to identify deprecated or unsafe code patterns. Additionally, dependency updates are managed through poetry and monitored using GitHub Dependabot to ensure compatibility with the latest versions of libraries.

For more details, see the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

The project applies an automated test suite on each check-in to the shared repository for the main branch. This is implemented using GitHub Actions workflows, which run the test suite automatically on every push and pull request. The test suite uses pytest and generates a report on test success or failure.

For more details, see the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md and the GitHub Actions workflows in the repository: https://github.com/nikhilxsunder/fedfred/actions.

The project includes regression tests for bugs fixed within the last six months as part of its automated test suite. All new functionality and bug fixes are required to have corresponding tests, as documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

Additionally, the CHANGELOG.md file (https://github.com/nikhilxsunder/fedfred/blob/main/CHANGELOG.md) tracks bug fixes, and the associated tests are added to the tests directory to ensure coverage and prevent regressions.

The project currently has an overall test coverage of 40%, as documented in the TEST_COVERAGE.md file: https://github.com/nikhilxsunder/fedfred/blob/main/TEST_COVERAGE.md. While the project does not yet meet the 80% statement coverage requirement, efforts are underway to improve test coverage, with a goal of achieving at least 80% overall coverage.

The project uses pytest with the pytest-cov plugin to measure test coverage, and contributors are encouraged to write tests for all new functionality and bug fixes to help meet this goal.

The project has a formal written policy requiring that tests for all new functionality be added to the automated test suite. This policy is documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

The policy states:

• All new functionality must include appropriate tests in the automated test suite.
• Tests should cover both success and error conditions, including edge cases.
• Pull requests without adequate test coverage will not be merged.

This ensures that the test suite remains comprehensive and up-to-date as the project evolves.

https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md

Yes, the project uses maximum strictness with warnings where practical. We enforce a high pylint score (9.0+), use strict type checking in mypy (with most error flags enabled), and run thorough security checks with bandit. These strict settings are enforced in CI for all PRs, and our CONTRIBUTING.md document explicitly requires all new code to pass these strict checks.

The project implements secure design principles as outlined in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md. These principles include:

1. Fail-Safe Defaults: The API client enforces secure defaults, such as HTTPS for all communications and strict parameter validation.
2. Complete Mediation: All API requests verify authentication and authorization, ensuring no bypassable access points.
3. Economy of Mechanism: The codebase is modular and avoids unnecessary complexity, focusing on simplicity and maintainability.
4. Separation of Privilege: The project recommends storing API keys in environment variables or secure vaults, separate from application code.
5. Open Design: The project is open source, relying on proper key management and secure practices rather than obscurity.

These principles ensure that the software is secure by design and adheres to best practices for secure development.