hcaptcha-rs

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 9974 ni passing 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/9974/badge)](https://www.bestpractices.dev/projects/9974)
au kwa kuweka hii katika HTML yako:
<a href="https://www.bestpractices.dev/projects/9974"><img src="https://www.bestpractices.dev/projects/9974/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 2/5

  • Jumla

    Kumbuka kwamba miradi mingine inaweza kutumia jina sawa.

    hcaptcha-rs is a library to verify hcaptcha responses.

    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


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

  • Usimamizi wa mradi


    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.


    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.

  • Mengine


    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.

    https://github.com/jerus-org/hcaptcha-rs/blob/main/CONTRIBUTING.md
    https://github.com/jerus-org/hcaptcha-rs/blob/main/hcaptcha/src/lib.rs
    https://github.com/jerus-org/hcaptcha-rs/blob/main/.circleci/config.yml
    https://github.com/jerus-org/hcaptcha-rs/blob/main/renovate.json.license
    https://github.com/jerus-org/hcaptcha-rs/blob/main/.vscode/launch.json.license
    https://github.com/jerus-org/hcaptcha-rs/blob/main/.vscode/settings.json.license
    The project applies per‑file licensing via SPDX headers in source and config files (e.g., “SPDX-License-Identifier: MIT OR Apache-2.0”), and uses REUSE‑style sidecar “.license” files for non‑commentable assets. CONTRIBUTING.md documents the requirement and provides the exact header snippet; representative files across Rust and YAML show the headers, and sidecar files cover JSON/VS Code assets.


 Udhibiti wa Mabadiliko 4/4

 Ubora 5/7

  • Viwango vya msimbo


    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.

    https://github.com/jerus-org/hcaptcha-rs/blob/main/CONTRIBUTING.md#pull-request-guidelines
    https://github.com/jerus-org/hcaptcha-rs/blob/main/CONTRIBUTING.md#coding-standards
    https://github.com/jerus-org/hcaptcha-rs/blob/main/GOVERNANCE.md#process-requirements
    https://github.com/jerus-org/hcaptcha-rs/blob/main/.circleci/config.yml
    The project documents clear code‑review standards and enforces them in CI. All changes must land via pull request; direct commits to main are prohibited. PRs must be focused, have descriptive commits with DCO sign‑off, include tests, and pass formatting and clippy with zero warnings. Review is required by a maintainer, and merges occur only when CI is green (build, doctests, lints, multi‑suite tests). Governance further codifies the requirement that CI checks pass and that review is part of the standard process.



    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]

    • URL:
    https://github.com/jerus-org/hcaptcha-rs/blob/main/CONTRIBUTING.md#pull-request-guidelines
    https://github.com/jerus-org/hcaptcha-rs/blob/main/GOVERNANCE.md#process-requirements
    • Justification: The GitHub Ruleset “Protect the Main Branch” enforces PRs on main and requires at least one approval from someone other than the author (applies to admins), with CI checks required before merge. CONTRIBUTING and Governance documents also require review for every change, so two‑person review is both documented and technically enforced.


  • Mfumo wa ujenzi unaofanya kazi


    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.

    The project has established reproducible builds. Multiple parties can independently rebuild crate packages and verify bit-for-bit identical results given the same inputs.

    Implementation:
    • Deterministic build process: CI uses SOURCE_DATE_EPOCH (fixed to last commit timestamp), RUSTFLAGS path remapping (--remap-path-prefix), and CFLAGS remapping for C dependencies to eliminate host-specific paths and timestamps.
    • Locked dependencies: Cargo.lock is committed, ensuring consistent dependency versions.
    • Specified build environment: Builds run in pinned Docker container images (jerusdp/ci-rust:1.88-wasi). The exact image, toolchain version, and environment variables are documented.
    • Verification support: SHA256 checksums of packaged crates are computed and attached to each GitHub release, allowing users to verify their local builds match official releases.

    Documentation:
    • Rebuild instructions with exact commands and environment variables: docs/REPRODUCIBLE_BUILDS.md
    • CI configuration: .circleci/config.yml (see set_repro_env command and compute_checksums_and_upload job)
    • Container pin file for future digest-based pinning: ci/container-pins.yaml

    URL: https://github.com/jerus-org/hcaptcha-rs/blob/main/docs/REPRODUCIBLE_BUILDS.md


  • Seti ya majaribio otomatiki


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

    https://github.com/jerus-org/hcaptcha-rs/blob/main/CONTRIBUTING.md
    CONTRIBUTING.md line 85 documents test invocation: cargo test --all



    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.

    https://dl.circleci.com/status-badge/redirect/gh/jerus-org/hcaptcha-rs/tree/main
    CircleCI runs comprehensive CI pipeline including tests on every commit. CircleCI badge displayed in README.



    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]


    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]

 Usalama 4/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.

    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]

    https://github.com/jerus-org/hcaptcha-rs/blob/main/SECURITY.md
    SECURITY.md section "Security expectations and scope" documents that "network calls target hCaptcha servers over HTTPS via reqwest" and section "Cryptography note" states "TLS and certificate validation are delegated to well-vetted dependencies (reqwest/rustls or native-tls)." All network communication to the hCaptcha API uses HTTPS with TLS provided by industry-standard libraries (rustls by default, or native-tls as an option), ensuring cryptographic protection of network traffic.



    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]

    https://github.com/jerus-org/hcaptcha-rs/blob/main/hcaptcha/Cargo.toml
    https://github.com/jerus-org/hcaptcha-rs/blob/main/Cargo.toml
    The project uses reqwest 0.12.24 with rustls-tls (default) or native-tls backends for HTTPS. Workspace Cargo.toml specifies reqwest with http2 feature enabled (line 48), ensuring HTTP/2 support. Both rustls (current versions support TLS 1.2 and 1.3) and native-tls delegate to platform TLS libraries that support TLS 1.2+. The library does not configure minimum TLS versions below 1.2, relying on secure defaults from reqwest and its TLS dependencies.


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


    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.

    Found all required security hardening headers.
    https://github.com/jerus-org/hcaptcha-rs
    https://docs.rs/hcaptcha
    This project does not operate or control its own project website or web application; it uses GitHub for the repo and docs.rs for documentation. The “hardened_site” (gold) criterion applies to project‑run sites/apps where the project can configure headers and defenses (e.g., HSTS, CSP, SRI, secure cookies, no mixed content). Since no such site exists under project control, this is Not Applicable. If a site is added later (e.g., GitHub Pages with a custom domain or another host), we can implement and document HSTS (preload where possible), strict CSP (no inline script/styles), SRI on third‑party assets, secure cookies with SameSite, and CI checks for mixed content.


  • Masuala mengine ya usalama


    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.

    Status: Not yet (planned)
    https://github.com/jerus-org/hcaptcha-rs/blob/main/SECURITY.md
    https://github.com/jerus-org/hcaptcha-rs/blob/main/.circleci/audit.yml
    https://github.com/jerus-org/hcaptcha-rs/blob/main/ARCHITECTURE.md
    We have not yet completed an independent/security‑specialist review. Dynamic analysis (Miri + libFuzzer) and documented security practices are in place, but a formal review with public results is pending. Plan: engage an external reviewer to assess the core crate, dependency risk, misuse‑resistance of APIs, CI/supply‑chain controls, and fuzzing coverage; fix findings; publish a summary report (SECURITY-REVIEW.md) and reference it from SECURITY.md. Target window: January–February 2026 (publish summary no later than March 15, 2026). After the report is published, we will mark this criterion Met.



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

    https://github.com/jerus-org/hcaptcha-rs/blob/main/.circleci/audit.yml
    https://github.com/jerus-org/hcaptcha-rs/blob/main/SECURITY.md
    https://github.com/jerus-org/hcaptcha-rs/blob/main/CONTRIBUTING.md
    https://github.com/jerus-org/hcaptcha-rs/blob/main/hcaptcha/src/request.rs
    The project applies multiple hardening measures: memory‑safe Rust with no unsafe blocks in the core crate; strict input validation for all externally supplied values; secrets are excluded from logs/tracing (e.g., request.rs instruments spans with skip(secret)); HTTPS/TLS via reqwest with verified certificates; CI runs clippy with zero‑warning policy and doctests; weekly dynamic analysis includes Miri (UB/memory safety) and a libFuzzer target for response parsing (see .circleci/audit.yml). SECURITY.md documents trust boundaries and non‑logging of secrets; CONTRIBUTING.md codifies the “no unsafe unless strictly justified” rule and CI gates.


 Uchanganuzi 2/2

  • Uchambuzi wa msimbo wa nguvu za ziada


    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.

    https://github.com/jerus-org/hcaptcha-rs/blob/main/.circleci/audit.yml
    Weekly dynamic analysis via Miri (Rust interpreter detecting undefined behavior and memory errors) and libFuzzer (fuzz testing response parser). Configured in CircleCI audit workflow.



    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.

    Miri and fuzz tests run with debug assertions enabled (Rust default for test/dev builds)



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 Jeremiah Russell na wachangiaji wa nishani ya Mazoea Bora ya OpenSSF.

Ingizo la nishani ya mradi linamilikiwa na: Jeremiah Russell.
Ingizo liliundwa siku 2025-01-31 12:51:53 UTC, iliyosasishwa mara ya mwisho siku 2025-12-16 08:03:23 UTC. Ilipoteza mara ya mwisho nishani ya kupita siku 2025-12-12 12:44:22 UTC. Ilipata mara ya mwisho nishani ya kupita siku 2025-12-12 12:45:03 UTC.