Palimpsests

Miradi inayofuata mazoea bora hapa chini inaweza kujihakikisha kwa hiari na kuonyesha kuwa wamepata nishani ya mazoea bora ya Open Source Security Foundation (OpenSSF).

Hakuna seti ya mazoea yawezayo kuhakikisha kuwa programu haitakuwa na kasoro au udhaifu; hata mbinu rasmi zinaweza kushindwa ikiwa vipimo au dhana ni sahihi. Wala hakuna seti ya mazoea yawezayo kuhakikisha kuwa mradi utaendelea kuwa na jamii ya maendeleo yenye afya na inayofanya kazi vizuri. Hata hivyo, kufuata mazoea bora kunaweza kusaidia kuboresha matokeo ya miradi. Kwa mfano, baadhi ya mazoea huwezesha ukaguzi wa watu wengi kabla ya kutolewa, ambayo inaweza kusaidia kupata udhaifu wa kiufundi ambao vinginevyo ni vigumu kupata na kusaidia kujenga uaminifu na hamu ya mwingiliano wa kurudia kati ya wasanidi programu kutoka makampuni tofauti. Ili kupata nishani, vigezo vyote vya LAZIMA na LAZIMA WALA USIWAHI lazima vifuatwe, vigezo vyote vya INAPASWA lazima vifuatwe AU visivyo fufufutiliana na thibitisho, na vigezo vyote vya PENDEKEZA lazima vifuatwe AU visivyo fufufutiliana (tunataka vifikiwe angalau). Ikiwa unataka kuingiza maandishi ya thibitisho kama maoni ya jumla, badala ya kuwa maelezo ya busara kwamba hali ni inakubaliwa, anza kifungu cha maandishi na '//' ikifuatiwa na nafasi. Maoni ni karibu kupitia tovuti ya GitHub kama masuala au maombi ya kuvuta Kuna pia orodha ya barua pepe kwa majadiliano ya jumla.

Tunafuraha kutoa habari katika lugha nyingi, hata hivyo, ikiwa kuna mgongano au kutokuwa na usawa kati ya tafsiri, toleo la Kiingereza ni toleo lenye mamlaka.
Ikiwa huu ni mradi wako, tafadhali onyesha hadhi ya nishani yako kwenye ukurasa wa mradi wako! Hadhi ya nishani inaonekana kama hii: Kiwango cha nishani kwa mradi 13534 ni gold Hapa ni jinsi ya kuiweka:
Unaweza kuonyesha hali ya nishani yako kwa kuweka hii katika faili yako ya markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/13534/badge)](https://www.bestpractices.dev/projects/13534)
au kwa kuweka hii katika HTML yako:
<a href="https://www.bestpractices.dev/projects/13534"><img src="https://www.bestpractices.dev/projects/13534/badge"></a>


Hizi ni vigezo vya kiwango cha Dhahabu. Unaweza pia kuangalia vigezo vya kiwango cha Kupita au Fedha.

Baseline Series: Kiwango cha Msingi 1 Kiwango cha Msingi 2 Kiwango cha Msingi 3

        

 Misingi 5/5 ●

  • Jumla

    Kumbuka kwamba miradi mingine inaweza kutumia jina sawa.

    Layered local-LLM inference engine for agentic workloads: Ollama and llama.cpp behind one abstraction, context-memory (sink/window/evict + block retrieval), encrypted audit log. Native L3 serving layer in progress.

    Tafadhali tumia muundo wa maneno ya leseni ya SPDX; mifano ni pamoja na "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", na "(BSD-2-Clause OR Ruby)". Usitumie alama za nukuu za moja au mbili.
    Ikiwa kuna lugha zaidi ya moja, ziorodhe kama thamani zilizotengwa kwa koma (nafasi ni za hiari) na ziorodhe kuanzia iliyotumiwa zaidi hadi iliyotumiwa kidogo. Ikiwa kuna orodha ndefu, tafadhali orodhesha angalau tatu za kawaida zaidi. Ikiwa hakuna lugha (k.m., huu ni mradi wa nyaraka tu au wa majaribio tu), tumia herufi moja "-". Tafadhali tumia herufi kubwa za kawaida kwa kila lugha, k.m., "JavaScript".
    Common Platform Enumeration (CPE) ni mpango wa kuweka majina yenye muundo kwa mifumo ya teknolojia ya habari, programu, na vifurushi. Inatumika katika mifumo na hifadhidata nyingi wakati wa kuripoti udhaifu.

  • Mahitaji ya awali


    Ya kutosha kwa nishani!

    Mradi LAZIMA ufikie kiwango cha nishani ya fedha. [achieve_silver]

  • Usimamizi wa mradi


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na "bus factor" ya 2 au zaidi. (URL inahitajika) [bus_factor]
    "Bus factor" (pia inajulikana kama "truck factor") ni idadi ya chini ya washiriki wa mradi ambao wanapaswa kutoweka ghafla kutoka kwenye mradi ("kupigwa na basi") kabla ya mradi kusimama kwa sababu ya ukosefu wa wafanyakazi wenye elimu au wenye uwezo. Zana ya truck-factor inaweza kukadiria hii kwa miradi kwenye GitHub. Kwa maelezo zaidi, angalia Kutathmini Bus Factor ya Hifadhi za Git na Cosentino et al.

    The project's bus factor is 2. Two people are significant contributors, each able to keep the project going on their own: the maintainer (@andreysparish) and the co-maintainer (@olksandrvertel-arch). Both hold repository-admin rights and can independently review, merge, and release; the co-maintainer has 35+ commits, including the hardware-isolation test suite and the role of independent PALA-1 verifier. Losing either one would not halt the project. Roles and the split of work are documented in docs/GOVERNANCE.md, and the contribution history is visible in the repository.
    URL (required) — the contributors graph is the most direct evidence of a bus factor ≥ 2:
    https://github.com/Assault-Consulting/Palimpsests/graphs/contributors


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na angalau wachangiaji wawili wasiohusika. (URL inahitajika) [contributors_unassociated]
    Wachangiaji wanahusianishwa ikiwa wanalipwa kufanya kazi na shirika moja (kama mwajiriwa au mkandarasi) na shirika lile linapata faida kutokana na matokeo ya mradi. Misaada ya kifedha haihesabiwi kuwa kutoka shirika sawa ikiwa inapitia mashirika mengine (k.m., misaada ya sayansi inayolipwa kwa mashirika tofauti kutoka serikali ya kawaida au chanzo cha NGO haifanyi wachangiaji kuhusianishwa). Mtu ni mchangiaji muhimu ikiwa amefanya michango isiyojulikana kwa mradi katika mwaka uliopita. Mifano ya viashiria vizuri vya mchangiaji muhimu ni: ameandika angalau mistari 1,000 ya msimbo, amechangia commits 50, au amechangia angalau kurasa 20 za nyaraka.

    Unassociated significant contributors in the past year: (1) Oleksii Turak, independent developer, no relationship with Assault Consulting — author of the fifth independent PALA-1 verification: a from-spec Perl 5 verifier with a hand-rolled NIST-validated AES-GCM implementation, ~2,300 lines (verifier + methodology + run record), merged 2026-08-18 (docs/specs/pala-1/independent-runs/turak/); (2) Sharyar Naseem, independent — the fourth independent verification run and a merged feature contribution (export seq-range bounds, PR #135, 2026-08-14). The two contributors are not associated with each other or with Assault Consulting; neither is paid by Assault Consulting. Andrii Sparysh and Oleksandr Verteletskyi (Assault Consulting) are counted as one associated group and excluded. Evidence: https://github.com/Assault-Consulting/Palimpsests/graphs/contributors


  • Mengine


    Ya kutosha kwa nishani!

    Mradi LAZIMA ujumuishe tamko la leseni katika kila faili ya chanzo. Hii YAWEZA kufanyika kwa kujumuisha yafuatayo ndani ya maoni karibu na mwanzo wa kila faili: SPDX-License-Identifier: [maneno ya leseni ya SPDX kwa mradi]. [license_per_file]
    Hii pia YAWEZA kufanyika kwa kujumuisha tamko katika lugha asilia ikitambulisha leseni. Mradi pia YAWEZA kujumuisha URL thabiti inayoelekeza kwenye maandishi ya leseni, au maandishi kamili ya leseni. Kumbuka kwamba kigezo cha license_location kinahitaji leseni ya mradi iwe mahali pa kawaida. Angalia mafunzo haya ya SPDX kwa maelezo zaidi kuhusu maneno ya leseni ya SPDX. Kumbuka uhusiano na copyright_per_file, ambayo yaliyomo yake kwa kawaida yangetangulia maelezo ya leseni.

    Every file in the Palimpsests repository has an explicit SPDX license statement. Most source files include an inline # SPDX-License-Identifier: [expression] comment near the top of the file; the remaining files are covered by a catch-all annotation in REUSE.toml (path = "**"). The project uses two licenses, each declared per file with the correct SPDX expression: the main codebase is Apache-2.0, while the PALA-1 specification and its reference implementations are dedicated to the public domain as CC0-1.0 (so a third party can implement the format without being bound by Apache terms). The repository is compliant with version 3.3 of the REUSE Specification: reuse lint reports 206/206 files with license information. The full license texts are stored in the standard location under LICENSES/ (Apache-2.0.txt and CC0-1.0.txt), and the conventional LICENSE file remains at the repository root.


 Udhibiti wa Mabadiliko 4/4 ●

  • Hifadhi ya chanzo ya kudhibiti toleo ya hadharani


    Ya kutosha kwa nishani!

    Hifadhi ya chanzo ya mradi LAZIMA itumie programu ya kawaida ya kudhibiti toleo linalosambazwa (k.m., git au mercurial). [repo_distributed]
    Git haihitajiki kihususa na miradi inaweza kutumia programu ya udhibiti wa toleo iliyokusanyika (kama subversion) na sababu.

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


    Ya kutosha kwa nishani!

    Mradi LAZIMA utambulishe kazi ndogo ambazo zinaweza kufanywa na wachangiaji wapya au wa mara kwa mara. (URL inahitajika) [small_tasks]
    Utambulisho huu kwa kawaida unafanyika kwa kuweka alama masuala yaliyochaguliwa katika kifuatiliaji cha masuala kwa lebo moja au zaidi ambazo mradi unatumia kwa madhumuni hayo, k.m., up-for-grabs, first-timers-only, "Marekebisho madogo", microtask, au IdealFirstBug. Kazi hizi mpya hazihitaji kujumuisha kuongeza utendaji; zinaweza kuwa kuboresha nyaraka, kuongeza hali za majaribio, au chochote kingine kinachosaidia mradi na kusaidia mchangiaji kuelewa zaidi kuhusu mradi.

    The project maintains a good first issue label that marks starter tasks suitable for new or casual contributors — small, self-contained work such as documentation fixes, CLI polish, and additional test cases (the label and its initial set of tasks were curated on 2026-08-14). These tasks do not require adding core functionality, so they can be picked up by contributors who are not yet familiar with the codebase. They are discoverable as a filtered list of open issues carrying the label (see URL).
    met_url:
    https://github.com/Assault-Consulting/Palimpsests/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22


    Ya kutosha kwa nishani!

    Mradi LAZIMA uhitaji uthibitishaji wa mambo mawili (2FA) kwa wasanidi programu ili kubadilisha hifadhi ya kati au kupata data nyeti (kama ripoti za faragha za udhaifu). Utaratibu huu wa 2FA YAWEZA kutumia taratibu bila taratibu za usimbuaji kama SMS, ingawa hii hairuhusiwi. [require_2FA]

    GitHub requires 2FA as of March 2023. [osps_ac_01_01]


    Ya kutosha kwa nishani!

    Uthibitishaji wa mambo mawili (2FA) ya mradi INAPASWA kutumia taratibu za usimbuaji ili kuzuia ujigeuzi. Uthibitishaji wa 2FA unaotegemea Huduma ya Ujumbe Mfupi (SMS), peke yake, HAUKIDHI kigezo hiki, kwa kuwa haufichui. [secure_2FA]
    Utaratibu wa 2FA unaokidhi kigezo hiki unaweza kuwa programu ya Nywila ya Mara Moja Inayotegemea Muda (TOTP) ambayo inazalisha kiotomatiki msimbo wa uthibitishaji unaobadilika baada ya muda fulani. Kumbuka kwamba GitHub inasaidia TOTP.

    Two-factor authentication for the project's maintainers is provided by a Time-based One-Time Password (TOTP) authenticator application, not SMS. TOTP is a cryptographic mechanism — an HMAC-based one-time code derived from a shared secret and the current time — so it does not carry the impersonation risk of unencrypted SMS-based 2FA. All maintainers with write/admin access to the central GitHub repository authenticate with app-based TOTP (and/or hardware security keys); none rely on SMS.


 Ubora 7/7 ●

  • Viwango vya msimbo


    Ya kutosha kwa nishani!

    Mradi LAZIMA uandike mahitaji yake ya kukagua msimbo, pamoja na jinsi ukaguzi wa nambari unafanywa, nini lazima ichunguzwe, na nini kinachohitajika ili ikubalike. (URL inahitajika) [code_review_standards]
    Angalia pia two_person_review na contribution_requirements.

    Code review requirements are documented in docs/REVIEW.md, with the contributor workflow in CONTRIBUTING.md and merge authority in GOVERNANCE.md. The document covers all three required elements. How review is conducted: every change — code and documentation — lands through a pull request that a non-author must approve before merge; main is branch-protected, so required green checks plus one non-author approval are enforced, not merely requested. What must be checked: the reviewer confirms that tests ship with behavior and that coverage stays above the gate (statement ≥ 90%, branch ≥ 80%), that ruff lint is clean, that any new dependency is justified, that security-sensitive paths (audit chain, key management, the crypto boundary, untrusted-input deserialization, the capability boundary) receive extra scrutiny against SECURITY.md / THREAT_MODEL.md / ASSURANCE-CASE.md, that public API/CLI and wire-format changes are deliberate and respect the format freeze, and that documentation matches the change; changes affecting released artifacts additionally require byte-verification and a green reproducible-build job. What is acceptable: approval means the reviewer believes the change is correct, tested, within the project's security and design boundaries, and free of known issues that would argue against inclusion — a reviewer who is unsure asks rather than approves, and author confidence alone is not grounds to merge.
    met_url:
    https://github.com/Assault-Consulting/Palimpsests/blob/main/docs/REVIEW.md


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na angalau 50% ya marekebisho yote yaliyopendekezwa kupitishwa kabla ya kutolewa na mtu mwingine isipokuwa mwandishi, ili kuamua ikiwa ni marekebisho ya manufaa na huru ya masuala yaliyojulikana ambayo yangepingana na ujumuishaji wake [two_person_review]

    Every proposed modification to Palimpsests is reviewed by a non-author before release, which far exceeds the 50% threshold. main is branch-protected: direct pushes are blocked, and every change — code and documentation alike — must go through a pull request that receives at least one approval from a person other than the author, plus a green required status check (ci-complete: lint, tests, and coverage across macOS/Linux/Windows), before it can be merged. These protections have been enforced since 2026-07-11 (documented in GOVERNANCE.md), which is the measurement anchor for the review-coverage figure: every merge from that date forward is non-author reviewed, so the reviewed fraction is effectively 100% and monotonically rising. The requirement is documented in GOVERNANCE.md and CONTRIBUTING.md.


  • Mfumo wa ujenzi unaofanya kazi


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na ujenzi unaorudiwa. Ikiwa hakuna ujenzi unaofanyika (k.m., lugha za uandishi ambapo msimbo wa chanzo unatumika moja kwa moja badala ya kukusanywa), chagua "haihusiki" (N/A). (URL inahitajika) [build_reproducible]
    Ujenzi unaorudiwa unamaanisha kwamba pande nyingi zinaweza kwa uhuru kurudia mchakato wa kuzalisha taarifa kutoka faili za chanzo na kupata matokeo sawa ya biti-kwa-biti. Katika hali fulani, hii inaweza kutatuliwa kwa kulazimisha mpangilio fulani wa aina. Wasanidi wa JavaScript wanaweza kuzingatia kutumia npm shrinkwrap na webpack OccurrenceOrderPlugin. Watumiaji wa GCC na clang wanaweza kupata chaguo la -frandom-seed kuwa na manufaa. Mazingira ya ujenzi (ikijumuisha zana) kwa kawaida yanaweza kufafanuliwa kwa pande za nje kwa kubainisha hash ya usimbuaji ya chombo maalum au mashine ya kawaida ambayo wanaweza kutumia kwa kujenga upya. Mradi wa majengo yanayorudiwa una nyaraka za jinsi ya kufanya hivi.

    Palimpsests has a reproducible build, so this is Met rather than N/A: the project publishes distribution artifacts, and both the sdist (.tar.gz) and the wheel (.whl) are bit-for-bit reproducible — building the same commit produces identical bytes. Determinism is achieved by building with hatchling via PEP 517 (fixed archive-member order, no wall-clock build time stamped into output), pinning SOURCE_DATE_EPOCH to the commit date, and fixing LC_ALL=C.UTF-8, TZ=UTC, and umask 0022. This is enforced on every push and pull request by the reproducible-build job in .github/workflows/ci.yml, which runs scripts/check_reproducible_build.sh to build the artifacts twice and fail if they differ; the job is a required check in the ci-complete gate. The release workflow builds published artifacts with the same pinned SOURCE_DATE_EPOCH/locale/umask, so released files are the reproducible ones. A step-by-step reproduction recipe is documented (docs/REPRODUCIBLE-BUILD.md) so any third party can independently rebuild a release and verify it by hash. Reproducibility covers the Python distribution artifacts; the optional native (llama.cpp) path links against a separately installed C library and is out of scope.
    https://github.com/Assault-Consulting/Palimpsests/blob/main/docs/REPRODUCIBLE-BUILD.md


  • Seti ya majaribio otomatiki


    Ya kutosha kwa nishani!

    Seti ya majaribio LAZIMA iweze kuitwa kwa njia ya kawaida kwa lugha hiyo. (URL inahitajika) [test_invocation]
    Kwa mfano, "make check", "mvn test", au "rake test" (Ruby).

    The test suite is invoked in the standard way for Python: python -m pytest (equivalently pytest) from the repository root, with pytest configured in the standard [tool.pytest.ini_options] section of pyproject.toml. This is the conventional Python test invocation, documented in CONTRIBUTING.md and used unchanged by the CI workflow. URL: https://github.com/Assault-Consulting/Palimpsests/blob/main/pyproject.toml


    Ya kutosha kwa nishani!

    Mradi LAZIMA utekeleze ujumuishaji wa kuendelea, ambapo msimbo mpya au uliobadilishwa unajumuishwa mara kwa mara katika hifadhi ya msimbo ya kati na majaribio ya kiotomatiki yanafanywa kwenye matokeo. (URL inahitajika) [test_continuous_integration]
    Katika hali nyingi hii inamaanisha kwamba kila msanidi programu anayefanya kazi kikamilifu kwenye mradi anajumuisha angalau kila siku.

    The project uses continuous integration. On every push to main and every pull request, GitHub Actions runs the automated test suite (pytest) and the linter (ruff) across a matrix of three operating systems (Linux, macOS, Windows) and two Python versions (3.11, 3.12). New and changed code is integrated into main frequently via pull requests, with the tests run automatically on each. Branch protection requires the checks to pass before merge. URL: https://github.com/Assault-Consulting/Palimpsests/blob/main/.github/workflows/ci.yml


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na seti ya majaribio ya kiotomatiki ya FLOSS ambayo inatoa angalau 90% ya ufikio wa tamko ikiwa kuna angalau zana moja ya FLOSS ambayo inaweza kupima kigezo hiki katika lugha iliyochaguliwa. [test_statement_coverage90]

    A FLOSS coverage tool exists for the selected language (coverage.py, run via pytest-cov), so N/A does not apply and the project meets the bar directly. The automated pytest suite achieves 90.3% statement coverage measured over the whole src/palimpsests package; only if TYPE_CHECKING: blocks and raise NotImplementedError lines are excluded, per the standard coverage convention. The single module that reads low — the in-process ctypes backend llamacpp_backend.py, which can only run with the optional [native] extra against a real GGUF model on GPU hardware and therefore cannot be exercised in CI — is counted, not omitted: the overall figure clears 90% with it included, and that backend is validated separately on hardware (benchmarks/RUNBOOK.md). Coverage is computed on every push and pull request (pytest --cov --cov-report=json) and enforced by scripts/coverage_gate.py, which fails the build below 90% statement (and 80% branch). The coverage job is a required check in the ci-complete gate, so coverage cannot silently regress below the bar.


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na seti ya jaribio zilizofanywa kiotomatiki za FLOSS ambazo zinatoa angalau asilimia 80 ya uangaliaji wa tawi ikiwa kuna angalau zana moja ya FLOSS inayoweza kupima kigezo hiki katika lugha iliyochaguliwa. [test_branch_coverage80]

    A FLOSS coverage tool exists for the selected language (coverage.py, run via pytest-cov with branch coverage enabled), so N/A does not apply and the project meets the bar directly. The automated pytest suite achieves 82.4% branch coverage measured over the whole src/palimpsests package, with branch = true set in the coverage configuration; only if TYPE_CHECKING: blocks and raise NotImplementedError lines are excluded, per the standard convention. The hardware-only in-process ctypes backend llamacpp_backend.py — runnable only with the optional [native] extra against a real GGUF model on GPU hardware, so not exercisable in CI — is counted, not omitted: the overall figure clears 80% with it included, and that backend is validated separately on hardware (benchmarks/RUNBOOK.md). Branch coverage is computed on every push and pull request and enforced together with statement coverage by scripts/coverage_gate.py, which fails the build below 80% branch (and 90% statement). The coverage job is a required check in the ci-complete gate, so branch coverage cannot silently regress below the bar.


 Usalama 5/5 ●

  • Tumia mazoea mazuri ya msingi ya usimbuaji

    Kumbuka kwamba programu fulani haihitaji kutumia taratibu za usimbuaji. Ikiwa mradi wako unazalisha programu ambayo (1) inajumuisha, inaamilisha, au inafanya usimbuaji kuwa hai, na (2) inaweza kutolewa kutoka Marekani (US) kwenda nje ya Marekani au kwa raia asiye wa Marekani, inaweza kuwa ni lazima kisheria kuchukua hatua chache za ziada. Kawaida hii inahusisha tu kutuma barua pepe. Kwa maelezo zaidi, tazama sehemu ya usimbuaji ya Kuelewa Teknolojia ya Chanzo Wazi & Udhibiti wa Usafirishaji wa Marekani.

    Ya kutosha kwa nishani!

    Programu iliyozalishwa na mradi LAZIMA isaidie itifaki salama kwa mawasiliano yake yote ya mtandao, kama vile SSHv2 au zaidi, TLS1.2 au zaidi (HTTPS), IPsec, SFTP, na SNMPv3. Itifaki zisizo salama kama vile FTP, HTTP, telnet, SSLv3 au mapema zaidi, na SSHv1 LAZIMA zizimwe kwa chaguo-msingi, na kuzimwa tu ikiwa mtumiaji anaisanidi mahususi. Ikiwa programu iliyozalishwa na mradi haiesaidii mawasiliano ya mtandao, chagua "haihusiki" (N/A). [crypto_used_network]

    Where the software makes network communication, it uses secure protocols only. Outbound network access (e.g. talking to model/back-end endpoints and to release/publishing infrastructure) goes through httpx over HTTPS/TLS — TLS 1.2+ as negotiated by the platform's TLS stack — and release publishing uses HTTPS with OIDC Trusted Publishing and Sigstore. The project does not implement or default to any insecure protocol (no plain HTTP fetch-and-trust, no FTP/telnet/SSLv3/SSHv1); an insecure transport is not enabled anywhere by default. The core product is a local-first, on-device inference engine, so most operation involves no network at all, and what network communication exists is over TLS.


    Ya kutosha kwa nishani!

    Programu iliyozalishwa na mradi LAZIMA, ikiwa inasaidia au inatumia TLS, isaidie angalau toleo la TLS 1.2. Kumbuka kwamba kabla ya TLS kuitwa SSL. Ikiwa programu haitumii TLS, chagua "haihusiki" (N/A). [crypto_tls12]

    The software uses TLS and supports TLS 1.2 or later. All HTTPS communication goes through httpx, which uses Python's standard TLS stack (OpenSSL via the ssl module); on the supported Python versions (3.11+) that stack negotiates TLS 1.2 and 1.3 and treats older SSL/TLS versions as disabled by default. The project does not force, pin, or fall back to any pre-1.2 protocol (no SSLv3/TLS 1.0/1.1), so TLS 1.2+ is the effective floor for every TLS connection it makes.


  • Utoaji salama dhidi ya mashambulizi ya mtu-katikati (MITM)


    Ya kutosha kwa nishani!

    Tovuti ya mradi, hifadhi (ikiwa inapatikana kupitia wavuti), na tovuti ya kupakua (ikiwa ni tofauti) LAZIMA ijumuishe vichwa muhimu vya kuimarisha na thamani zisizo na ruhusa. (URL inahitajika) [hardened_site]
    Kumbuka kwamba GitHub na GitLab zinajulikana kukidhi hii. Tovuti kama vile https://securityheaders.com/ zinaweza kuangalia hii haraka. Vichwa muhimu vya kuimarisha ni: Sera ya Usalama wa Maudhui (CSP), Usalama wa Usafiri wa HTTP Mkali (HSTS), X-Content-Type-Options (kama "nosniff"), na X-Frame-Options. Tovuti za wavuti zilizo za tuli kabisa bila uwezo wa kuingia kupitia kurasa za wavuti zinaweza kuacha baadhi ya vichwa vya kuimarisha na hatari ndogo, lakini hakuna njia ya kuaminika ya kugundua tovuti kama hizo, kwa hivyo tunahitaji vichwa hivi hata kama ni tovuti za tuli kabisa.

    The project website (https://palimpsests.dev) returns the four key hardening headers with nonpermissive values on every response, configured in site/vercel.json. Content-Security-Policy: default-src 'self' with object-src 'none', frame-ancestors 'none', base-uri 'self', and upgrade-insecure-requests. Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (two years). X-Content-Type-Options: nosniff. X-Frame-Options: DENY. It additionally sets Referrer-Policy and a restrictive Permissions-Policy. An external scan (securityheaders.com, 2026-08-14) grades the site A, with all key headers present; the only item below A+ is 'unsafe-inline' in script-src/style-src, tracked as a site improvement. The source repository and the download site are hosted on GitHub (and the package is published to PyPI), which are known to meet this criterion.


  • Masuala mengine ya usalama


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe umefanya ukaguzi wa usalama ndani ya miaka 5 iliyopita. Ukaguzi huu LAZIMA uzingatie mahitaji ya usalama na mpaka wa usalama. [security_review]
    Hii YAWEZA kufanywa na wanachama wa mradi na/au tathmini huru. Tathmini hii YAWEZA kusaidiwa na zana za uchambuzi za tuli na zenye nguvu, lakini lazima pia kuwe na ukaguzi wa binadamu ili kutambua matatizo (hasa katika muundo) ambayo zana haziwezi kugundua.

    The project performed an internal security review in July 2026 — within the last 5 years — documented in docs/security/AUDIT-2026-07.md. It was a human review (manual examination of the audit subsystem, key management, process lifecycle, native backend, KV store, context memory, and CLI), supported by Bandit SAST and dependency/workflow review, covering the full source tree at a pinned commit plus the CI workflows and the published PyPI artifact. The review explicitly considered both the security requirements and the security boundary: the assets and properties to protect, the trust boundaries (the filesystem and the Python→C hand-off), and attacker capabilities are documented in docs/THREAT_MODEL.md, and the audit assessed the design against them — including validating the project's stated "honest boundary" (what the tamper-evident anchor does and does not guarantee; e.g., an attacker holding both the key and keychain-write access is explicitly out of scope). The review produced concrete findings (H1–H2, M1–M4, L1–L3) with severity and remediation status; most were fixed in PR #47, and the remaining items are tracked as explicit, boundary-scoped decisions.


    Ya kutosha kwa nishani!

    Taratibu za kuimarisha LAZIMA zitumike katika programu iliyozalishwa na mradi ili kasoro za programu ziwe na uwezekano mdogo wa kusababisha udhaifu wa usalama. (URL inahitajika) [hardening]
    Taratibu za kuimarisha zinaweza kujumuisha vichwa vya HTTP kama Sera ya Usalama wa Maudhui (CSP), bendera za mkusanyaji ili kupunguza mashambulizi (kama vile -fstack-protector), au bendera za mkusanyaji ili kuondoa tabia isiyofafanuliwa. Kwa madhumuni yetu upendeleo mdogo hauhesabiwi kuwa utaratibu wa kuimarisha (upendeleo mdogo ni muhimu, lakini tofauti).

    The software uses hardening mechanisms so that a defect is less likely to become a security vulnerability. The primary mechanism is language choice: all code the project produces is written in a memory-safe language (Python), eliminating whole classes of defect-to-vulnerability paths (buffer overflows, use-after-free). The single memory-unsafe boundary — the third-party llama.cpp C library — is isolated behind an optional [native] extra, and the untrusted-input surface in front of it (the KV-state validator guarding load_state) is coverage-guided fuzzed with Atheris, so malformed input is rejected before any byte reaches C. Additional mechanisms: SQL is parameterized throughout (no injection); there is no unsafe deserialization (pickle/eval/shell=True are absent); cryptographic keys come from a CSPRNG (secrets.token_bytes); the at-rest audit store is encrypted (SQLCipher/AES-256) with the key held in the OS keychain, and the design fails closed — it refuses to open rather than fall back to plaintext if SQLCipher is unavailable; the audit chain's canonical serialization is length-prefixed so field boundaries cannot be forged; provider exception text is clipped before it enters the log to prevent secret leakage; and the CI/release pipeline runs with least-privilege permissions, SHA-pinned actions, and OIDC-scoped publishing. These mechanisms, and the security argument for them, are documented in docs/ASSURANCE-CASE.md, with the asset-to-mechanism mapping in docs/THREAT_MODEL.md. As a local-first library with no network service of its own, HTTP transport-hardening headers do not apply to the software itself; the project website's hardening headers are covered separately under hardened_site.
    https://github.com/Assault-Consulting/Palimpsests/blob/main/docs/ASSURANCE-CASE.md


 Uchanganuzi 2/2 ●

  • Uchambuzi wa msimbo wa nguvu za ziada


    Ya kutosha kwa nishani!

    Mradi LAZIMA utumie angalau zana moja ya uchambuzi wenye nguvu kwa toleo lolote lililopendekezwa kuu la uzalishaji wa programu iliyozalishwa na mradi kabla ya kutolewa kwake. [dynamic_analysis]
    Zana ya uchambuzi wa nguvu inachunguza programu kwa kuitekeleza na ingizo maalum. Kwa mfano, mradi YAWEZA kutumia zana ya fuzzing (k.m., American Fuzzy Lop) au kitafutaji cha programu ya wavuti (k.m., OWASP ZAP au w3af). Katika hali fulani mradi wa OSS-Fuzz unaweza kuwa tayari kutumia majaribio ya fuzz kwenye mradi wako. Kwa madhumuni ya kigezo hiki zana ya uchambuzi wa nguvu inahitaji kubadilisha ingizo kwa njia fulani kutafuta aina mbalimbali za matatizo au kuwa seti kiotomatiki ya majaribio yenye angalau asilimia 80 ya ukaguzi wa tawi. Ukurasa wa Wikipedia kuhusu uchambuzi wa nguvu na ukurasa wa OWASP kuhusu fuzzing hutambulisha baadhi ya zana za uchambuzi wa nguvu. Zana za uchambuzi ZINAWEZA kuzingatia kutafuta udhaifu wa usalama, lakini hii haihitajiki.

    The project applies a dynamic analysis tool — Atheris, the Python binding for libFuzzer — as coverage-guided fuzzing. The harness (fuzz/fuzz_state_blob.py) targets the security-critical untrusted-input boundary: NativeSession.load_state, the pure-Python frame parser standing between arbitrary bytes and the C KV-state deserializer (llama_state_seq_set_data). It enforces the invariant that a malformed blob is rejected in Python (raising StateBlobError, with the backend never called) and never reaches C; any other outcome is a finding. Fuzzing runs in .github/workflows/fuzz.yml: a short deterministic regression pass on every push and pull request to main (so a previously found crash cannot silently return), plus a longer time-budgeted run nightly and on demand. Because every change to main is fuzzed and releases are cut from main, at least one dynamic analysis tool has been applied to the code before each release. Assertions are enabled during the run (the harness executes under CPython without -O). The one memory-unsafe component — the third-party llama.cpp C library — is outside the project's own code; the harness deliberately fuzzes the project's guard in front of it. (Independently, the project's automated test suite also exceeds 80% branch coverage, which on its own satisfies this criterion.)
    https://github.com/Assault-Consulting/Palimpsests/blob/main/fuzz/README.md


    Kwa shida ya kutosha kwa nishani.

    Mradi INAPASWA kujumuisha madai mengi ya muda wa kutekeleza katika programu inayozalisha na kuangalia madai hayo wakati wa uchambuzi wenye nguvu. [dynamic_analysis_enable_assertions]
    Kigezo hiki hakipendekezi kuwezesha madai wakati wa uzalishaji; hilo ni kabisa kwa mradi na watumiaji wake kuamua. Lengo la kigezo hiki ni badala yake kuboresha ugunduzaji wa hitilafu wakati wa uchambuzi wa nguvu kabla ya kusambazwa. Kuwezesha madai katika matumizi ya uzalishaji ni tofauti kabisa na kuwezesha madai wakati wa uchambuzi wa nguvu (kama vile majaribio). Katika hali fulani kuwezesha madai katika matumizi ya uzalishaji ni busara sana (hasa katika vipengele vya uadilifu wa juu). Kuna hoja nyingi dhidi ya kuwezesha madai katika uzalishaji, k.m., maktaba hazipaswi kuvuruga waita, uwepo wao unaweza kusababisha kukataliwa na maduka ya programu, na/au kuamilisha madai katika uzalishaji kunaweza kufunua data za faragha kama vile funguo za faragha. Kumbuka kwamba katika usambazaji mwingi wa Linux NDEBUG haijafafanuliwa, hivyo C/C++ assert() kwa chaguo-msingi itawezeshwa kwa uzalishaji katika mazingira hayo. Inaweza kuwa muhimu kutumia utaratibu tofauti wa madai au kufafanua NDEBUG kwa uzalishaji katika mazingira hayo.

    The project deliberately enforces validation and invariants with explicit exceptions (raise, ~113 across the codebase) rather than assert, because assert is stripped under -O and must not be relied on for checks that need to always execute. These checks run unconditionally, including during fuzzing. The project does not add a large number of dedicated assert-style assertions solely for dynamic analysis, so this SHOULD is not claimed as met.



Unaweza kutumia zana na mifumo ya AI kupendekeza mabadiliko kupitia URL rahisi, kama vile https://www.bestpractices.dev/sw/projects/13534/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Angalia mfumo wetu wa mapendekezo ya otomatiki kwa jinsi ya kufanya hivyo. Data hii inapatikana chini ya Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Hii inamaanisha kuwa Mpokeaji wa Data anaweza kushiriki Data, na au bila marekebisho, mradi Mpokeaji wa Data anapatanisha maandishi ya mkataba huu na Data iliyoshirikiwa. Tafadhali tambua andreysparish na wachangiaji wa nishani ya Mazoea Bora ya OpenSSF.

Ingizo la nishani ya mradi linamilikiwa na: andreysparish.
Ingizo liliundwa siku 2026-07-08 10:49:53 UTC, iliyosasishwa mara ya mwisho siku 2026-08-23 07:20:40 UTC. Ilipata mara ya mwisho nishani ya kupita siku 2026-07-08 11:51:23 UTC.