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

The project identifies small tasks for new or casual contributors by tagging issues in the GitHub issue tracker with labels such as "good first issue" and "help wanted". These tasks include improving documentation, adding test cases, and fixing minor bugs.

You can view these tasks in the project's issue tracker at: https://github.com/nikhilxsunder/fedfred/issues.

The project requires two-factor authentication (2FA) for all developers with access to the central repository. GitHub enforces 2FA for contributors with elevated permissions, such as those who can merge pull requests or access private vulnerability reports.

For more details, see the GitHub repository settings: https://github.com/nikhilxsunder/fedfred/settings.

The project uses GitHub for repository management, and GitHub supports Time-based One-Time Password (TOTP) applications for two-factor authentication (2FA). Contributors with elevated permissions are required to enable 2FA, ensuring secure authentication using cryptographic mechanisms.

For more details, see the GitHub repository settings: https://github.com/nikhilxsunder/fedfred/settings.

The project documents its code review requirements in the CONTRIBUTING.md file. The code review process includes the following:

How Code Review is Conducted:

All pull requests must be reviewed by at least one maintainer before merging. Reviews are conducted through GitHub's pull request review system. What Must Be Checked:

Code must adhere to the project's coding standards (e.g., PEP 8, type hints, and docstrings). Static analysis tools (pylint, mypy, bandit) must pass without warnings. Tests must cover new functionality and pass successfully. Documentation must be updated for any new features or changes. Requirements for Acceptability:

Code must be clear, concise, and maintainable. All tests must pass, and test coverage must meet the project's standards. Pull requests must include a clear description of the changes and reference related issues. For more details, see the code review section in the CONTRIBUTING.md file. https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md

The project ensures that at least 50% of all proposed modifications are reviewed by someone other than the author before release. This is documented in the CONTRIBUTING.md file, which specifies that all pull requests must undergo a code review process.

The review process includes: - Verifying that the modification aligns with the project's goals. - Checking for adherence to coding standards and guidelines. - Ensuring the modification is free of known issues.

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

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).

For more details, see the repository: https://github.com/nikhilxsunder/fedfred.

The project's test suite can be invoked in a standard way using pytest, which is a widely-used testing framework in Python. The tests are run with the following command:

pytest

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

The project implements continuous integration using GitHub Actions. Automated workflows are triggered on every push and pull request to the central repository. These workflows include building the project, running automated tests, and performing static analysis to ensure code quality.

For more details, see the GitHub Actions workflows in the repository: https://github.com/nikhilxsunder/fedfred/actions.

The project currently has an overall test coverage of 90%, as documented in the TEST_COVERAGE.md file.

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 currently has an overall test coverage of 90%, as documented in the TEST_COVERAGE.md file.

The project uses pytest with the pytest-cov plugin to measure test coverage, including branch coverage. Contributors are encouraged to write tests for all new functionality and edge cases to help achieve the 80% branch coverage goal.

The software produced by the project communicates with the FRED API exclusively over HTTPS, which uses TLS 1.2 or later for secure network communications. Insecure protocols such as HTTP are not supported. This ensures that all network communications are encrypted and secure by default.

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

The software produced by the project communicates with the FRED API exclusively over HTTPS, which uses TLS 1.2 or later for secure communication. Therefore, this criterion is met. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

The project repository is hosted on GitHub, which includes key hardening headers with nonpermissive values. GitHub enforces the following security headers:

1. Content Security Policy (CSP): Restricts the sources from which content can be loaded.
2. HTTP Strict Transport Security (HSTS): Ensures all connections are made over HTTPS.
3. X-Content-Type-Options: Set to "nosniff" to prevent MIME type sniffing.
4. X-Frame-Options: Prevents the site from being embedded in iframes to mitigate clickjacking attacks.

For verification, you can check the repository at: https://github.com/nikhilxsunder/fedfred.

The project has performed a security review within the last 5 years. This review included:

1. Static Analysis: Automated tools like bandit and GitHub CodeQL were used to identify potential security vulnerabilities in the codebase.
2. Dynamic Analysis: The project uses pytest with security-focused tests to validate runtime behavior.
3. Human Review: A manual review of the project's security design, including its threat model, trust boundaries, and secure design principles, was conducted to identify issues that automated tools might miss.

Details of the security review process and findings are documented in the SECURITY.md file.

The project incorporates hardening mechanisms to reduce the likelihood of software defects resulting in security vulnerabilities:

HTTP Security: The project enforces HTTPS for all API communications, ensuring secure data transmission. Static Analysis: Tools like bandit are used to identify and mitigate common security issues in Python code. Dependency Management: Regular updates and dependency scanning with GitHub Dependabot ensure that third-party libraries are secure. Type Safety: The use of Python type hints and static type checking with mypy helps prevent undefined behavior. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

Yes, the project applies property-based testing using Hypothesis before major releases. Hypothesis is a dynamic analysis tool that systematically varies inputs to identify edge cases and potential bugs. Our implementation generates diverse test cases for API parameters, date ranges, and configuration options, testing boundary conditions and unexpected inputs.

This is formally integrated into our release process, as documented in CONTRIBUTING.md. We've created a dedicated GitHub workflow (dynamic-analysis.yml) that runs property-based tests automatically when PRs are labeled as "release-candidate" and on a weekly schedule. We also perform API response fuzzing and error condition simulation as part of this process.

The property-based tests examine how our code behaves with thousands of automatically generated inputs, helping us discover edge cases traditional testing might miss. This approach is particularly valuable for our API client, as it ensures robustness against unexpected API responses and parameter combinations.

Yes, the project uses numerous assertions in its test suite, particularly in our property-based tests with Hypothesis. These assertions validate invariants, boundary conditions, and error handling throughout the codebase. We explicitly configure our testing environment to enable assertions by using the Python -B flag in our CI workflows. Our CONTRIBUTING.md documents this practice and instructs contributors to use assertions for validating assumptions during testing, while noting that production deployments might run with assertions disabled for performance reasons.