fedfred

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.

prerelease versions exist, 0.0.7 to 0.03. https://pypi.org/project/fedfred/#history

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

https://pypi.org/project/fedfred/#history

project uses git tags for each version. https://github.com/nikhilxsunder/fedfred/tags

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

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

https://github.com/nikhilxsunder/fedfred/pulls Github provides and issue tracker with pull requests

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

no bugs reported yet. https://github.com/nikhilxsunder/fedfred/issues

No enhancement requests yet. https://github.com/nikhilxsunder/fedfred/issues

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

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

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

No vulnerabilities reported yet, but actively monitoring.

Yes, the project uses Poetry as its build system. The pyproject.toml file defines all dependencies and build requirements, while poetry-core serves as the build backend. Running poetry build automatically builds both wheel and source distributions.

This satisfies the requirement for having a reproducible build system that can rebuild the software from source code.

Yes, the project uses Poetry, which is a common modern Python packaging and dependency management tool. Poetry handles building source distributions and wheels according to Python packaging standards (PEP 517/518).

Yes, the project is buildable using only FLOSS tools. The entire toolchain consists of open source software: Poetry (MIT license) for dependency management and package building pytest (MIT license) for testing Sphinx (BSD license) for documentation generation Python (PSF license) as the programming language

Yes, the project uses pytest, an open source testing framework, for automated testing. The test suite is included in the repository in the tests directory. Instructions for running the tests are documented in the README.md file under the "Testing" section, and tests also run automatically via GitHub Actions workflows.

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

Yes, the project maintains comprehensive test coverage of core functionality and edge cases. We use pytest-cov to measure coverage and have established a minimum goal of 80% overall coverage. Coverage reports are generated during CI runs, and the README documents how contributors can check coverage locally.

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.

Yes, the project has a documented policy requiring tests for new functionality. This policy is explicitly stated in our README.md file under the Testing section: "All new features must include appropriate tests"

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

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

Yes, the project uses multiple linting and static analysis tools to catch code quality issues: pylint for general code quality and adherence to PEP 8 mypy for type checking bandit for security vulnerability detection

These tools are configured in pyproject.toml and are referenced in the CONTRIBUTING.md as part of the CI process.

Yes, the project actively addresses warnings from linting tools. Our CI process runs pylint, mypy, and bandit on all code. We maintain a policy (documented in CONTRIBUTING.md) requiring all new code to be warning-free. Legitimate warnings are fixed, and false positives are explicitly suppressed with explanatory comments. Our current codebase has fewer than 10 total warnings, all of which are documented exceptions.

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.

Yes, our primary developer Nikhil Sunder understands secure software design principles as documented in our SECURITY.md file and has completed LFD121. They enforce security best practices through our code review process, static analysis tools, and secure development guidelines documented in CONTRIBUTING.md.

Yes, our primary developer is knowledgeable about common vulnerabilities in API client libraries and Python applications. We've documented these vulnerabilities and their specific mitigations in our SECURITY.md file, including issues like insecure API key handling, parameter injection, certificate verification bypass, insecure deserialization, and dependency chain vulnerabilities. We implement specific mitigations for each vulnerability type in our codebase.

The project does not depend on cryptographic algorithms or modes with known serious weaknesses. It uses secure cryptographic libraries provided by Python's standard library or well-maintained third-party libraries, such as cryptography or hashlib, which default to secure algorithms like SHA-256 or AES-GCM.

For more details on the project's security practices, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

Yes, FedFred uses multiple mechanisms to counter MITM attacks. All package downloads are delivered over HTTPS through PyPI and GitHub, which use TLS to prevent interception. This secure delivery mechanism is documented in our SECURITY.md file along with recommended installation methods. We're also implementing GPG signing for releases to provide additional verification options.

Yes, the project never relies solely on unsigned hashes. All downloads use HTTPS (TLS), and we provide GPG signatures for our releases. Users are instructed to verify these signatures in our SECURITY.md file, and we've implemented an automated workflow (sign-release.yml) that creates detached GPG signatures for all release artifacts.

Yes, our project has no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. We maintain a strict policy of addressing security issues within 60 days as documented in our SECURITY.md file. We use automated scanning tools (Dependabot, CodeQL) to detect vulnerabilities, and we have a clear process for handling security reports. Our security policy documents our commitment to prompt vulnerability remediation.

there are no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days in the FedFred codebase.

All keys are stored as repository secrets and no private keys have been leaked.

Yes, the project runs multiple static code analysis tools before major releases. We use pylint for general code quality (configured with a minimum score of 9.0/10), mypy for static type checking with strict settings, and bandit for security-focused analysis. These tools are configured in our pyproject.toml file, automated via GitHub Actions workflows, and enforced through pre-commit hooks. All code must pass static analysis before it can be merged to the main branch or included in a release.

Yes, the project uses Bandit, a security-focused static analysis tool specifically designed to detect common vulnerabilities in Python code. Bandit is configured in our development environment, integrated into our pre-commit hooks, and runs automatically in our CI/CD pipeline. This helps us identify security issues early in the development process, as documented in our CONTRIBUTING.md file.

Yes, the project uses Bandit, a security-focused static analysis tool specifically designed to detect common vulnerabilities in Python code. Bandit is configured in our development environment, integrated into our pre-commit hooks, and runs automatically in our CI/CD pipeline. This helps us identify security issues early in the development process, as documented in our CONTRIBUTING.md file.

Yes, the project runs static code analysis on every commit and daily. Our CodeQL workflow runs comprehensive security-focused static analysis on every push to the main branch, every pull request, and on a daily schedule at midnight UTC. This ensures continuous code quality checks even during periods with fewer commits.

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.

Python is memory safe.

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.

No medium to high severity vulnerabilities exist yet.