Libellus Potionis

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

    Libellus Potionis is a privacy-first, free, open-source, ad-free alcohol-consumption tracker that helps users monitor, pace, and manage their drinking habits entirely offline. It needs no invasive device permissions — no camera, microphone, or location access — and works completely without network connectivity.

    Key features

    • Intelligent logging: predefine custom beverages or use internationally common presets, and log drinks instantly or retroactively with precise timestamp corrections.
    • Concurrent limit tracking: set three simultaneous boundaries — a daily limit (grams of pure alcohol), a rolling 7-day weekly limit (grams), and a maximum number of drinking days per week — with visual progress bars in real time.
    • Blood-alcohol (BAC) estimation: enter your body weight for a live BAC approximation based on the established Widmark formula.
    • Addiction-counseling reports: generate a clear, well-organized two-page PDF report designed for consultations and counseling appointments.
    • Data portability: export your complete dataset as a standard CSV file for external processing (e.g. in LibreOffice Calc), or create secure JSON backups to migrate data between devices.
    • Granular adjustments: customize your "day start" time so late-night drinks count toward the correct evening, and define custom evaluation start dates for clean restarts.

    A comprehensive User's Guide is fully accessible in-app. The app is available on F-Droid.

    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.

    Libellus Potionis is a privacy-first, offline, ad-free Android app for tracking, pacing, and managing alcohol consumption. It requests no network permission and no camera/microphone/location access; all data stays on the device in the app's private, sandboxed storage, encrypted at rest (AES-256-GCM via the Android Keystore), with an optional biometric lock. It is Free Software under GPL-3.0-or-later, developed openly on Codeberg and distributed through F-Droid. The project is deliberately maintained as a teaching-quality codebase: every source file carries a license header and KDoc, and a release gate (tools/release-check.sh) enforces documentation, version consistency, English-only source, and translation completeness. Quality is guarded by a broad automated test suite (JVM unit tests plus instrumented Room-migration, Compose-UI, and locale tests) and by Android Lint and Kotlin compiler warnings promoted to build-breaking errors.

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

    Not met. The project currently has a single maintainer, so its bus factor is 1. Achieving a bus factor of 2 or more requires a second, significantly involved maintainer. This is tracked as an open item in docs/ROADMAP.md ("Working toward the OpenSSF gold badge").



    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.

    Not met. The project currently has a single significant contributor (the sole maintainer), so it does not have two unassociated significant contributors. This will be satisfied by bringing on a second, independent significant contributor; tracked in docs/ROADMAP.md ("Working toward the OpenSSF gold badge").


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

    Met. The same header that provides the copyright statement in each hand-authored source file also provides a licence statement — the GNU GPL v3-or-later grant text — which is a fuller form than an SPDX-License-Identifier line. It is present in every Kotlin, Gradle KTS, Python, shell, ProGuard, XML (resources and manifest), version-catalog, and configuration source file. The excluded categories are identical to copyright_per_file: generated files, vendored third-party files, third-party fonts, and pure data/binary assets.


 Udhibiti wa Mabadiliko 4/4

  • Hifadhi ya chanzo ya kudhibiti toleo ya hadharani


    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.

    The project uses Git, the most widely used distributed version control system, hosted on Codeberg (Forgejo). Repository: https://codeberg.org/godisch/potillus



    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.

    Met. Small tasks for new or casual contributors are identified in the tracker with the "good first issue" label and described in CONTRIBUTING.md ("Good first issues"), which highlights native-speaker translation review of the machine-generated locales, documentation, and test cases as good entry points. URL: https://codeberg.org/godisch/potillus/issues?labels=1948199



    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]

    Met. Write (push) access to the canonical repository (hosted on Codeberg) requires two-factor authentication as a documented project policy: docs/GOVERNANCE.md ("Repository access and account security") states that any account with write access MUST have cryptographic 2FA enabled. Currently the sole maintainer is the only account with write access and has 2FA enabled; the policy binds any future account granted write access. Codeberg additionally blocks plain-password HTTP/S git operations once 2FA is enabled, so access requires a token or SSH key. The forge offers no per-project 2FA enforcement toggle, so the requirement is enforced by written policy. Reference: https://codeberg.org/godisch/potillus/src/branch/main/docs/GOVERNANCE.md



    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.

    Met. The project's 2FA policy (docs/GOVERNANCE.md, "Repository access and account security") mandates a cryptographic method — a TOTP authenticator app or a hardware security key — and explicitly excludes SMS. The maintainer's Codeberg 2FA uses such a cryptographic method. Reference: https://codeberg.org/godisch/potillus/src/branch/main/docs/GOVERNANCE.md


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

    CONTRIBUTING.md ("Code review requirements", Section 2) documents the project's code review process: how review is conducted (every change is reviewed before merge by the maintainer as reviewer and sole merger; the reviewer runs the build, the test suite, and tools/release-check.sh locally since there is no CI service yet), an explicit checklist of what must be checked (scope/privacy fit, architecture rules, coding and KDoc conventions, warnings-as-errors, mandatory tests, localization completeness, per-file licensing, DCO sign-off, and schema-freeze rules), and the acceptance criteria required for a change to be merged. URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md



    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]

    The project currently has a single maintainer who authors and reviews all changes, so fewer than 50% of modifications are reviewed by a person other than the author. The review process and checklist are documented (CONTRIBUTING.md, "Code review requirements"); satisfying this criterion requires a second, independent reviewer. Tracked in docs/ROADMAP.md ("Working toward the OpenSSF gold badge").


  • 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 Android build is reproducible. F-Droid builds the app from source and verifies that the result is bit-for-bit identical to the maintainer-signed APK before publishing it (F-Droid's Reproducible Builds process). This is documented in SECURITY.md ("Verifying releases"), and the F-Droid build recipe (fdroid/de.godisch.potillus.yml) pins the build and the allowed APK signing key, so anyone can rebuild from a release tag and compare against the published APK. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.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).

    The test suite is invoked in the standard way for a Gradle/Android project: ./gradlew test runs the JVM unit tests and ./gradlew connectedCheck runs the instrumented tests on a device or emulator. This conventional invocation is documented in CONTRIBUTING.md (Section 5, "Testing strategy", and the change-submission checklist in Section 2). URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md



    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.

    Not currently implemented. The project is maintained by a single developer who builds and runs the full test suite and release gate (tools/release-check.sh) locally before each release, but there is no central CI service running automated tests on every change. This criterion is SUGGESTED at passing and a MUST at gold; the planned remediation is a Woodpecker pipeline (.woodpecker.yml) on Codeberg that runs the JVM unit tests (and lint/ktlint) on each push and reports success or failure — the same work as the silver automated_integration_testing item. Tracked in docs/ROADMAP.md.



    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]

    The JVM unit-test suite reaches ~97% statement (line) coverage, measured with Kover over the unit-testable code. Android-runtime-bound code (Compose UI, Room database/DAOs, DataStore preferences, Keystore, PDF/WebView rendering, and MediaStore import/export) is excluded from this figure and verified instead by the instrumented suite (src/androidTest). A build-breaking 90% line floor is enforced by the koverVerify Gradle task in the release gate (make cover-check). Methodology: CONTRIBUTING.md §5; scope/enforcement: app/build.gradle.kts.



    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]

    Branch coverage is ~80% (Kover, unit-testable scope), with a 75% regression floor enforced via koverVerify. The remaining branches lie in Android-/Compose-adjacent code (ViewModel StateFlow assembly, resource-bound error mapping); reaching the ≥80% gold threshold is a tracked roadmap goal.


 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]

    Not applicable. The application performs no network communication: it does not declare the INTERNET permission, works entirely offline, and transmits no data. There are therefore no network protocols whose security could be assessed.



    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]

    Not applicable. The application does not use TLS because it performs no network communication at all (no INTERNET permission, offline-only). There is no TLS configuration or version to assess.


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

    Not met. The criterion requires the repository and download sites to send four key hardening headers (CSP, HSTS, X-Content-Type-Options: nosniff, X-Frame-Options). The download site (F-Droid) sends all four. The repository host (Codeberg) sends strong HSTS (max-age two years, includeSubDomains, preload) and X-Frame-Options, but not CSP or X-Content-Type-Options. These headers are set by Codeberg, not by the project, and cannot be configured from the repository. Tracked in docs/ROADMAP.md; remediation is to request the missing headers from Codeberg or mirror on a compliant platform.


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

    A security review was performed in 2026 and is recorded in docs/ASSURANCE_CASE.md ("Security review record"). It takes into account the security requirements (SECURITY.md, "Security model") and the security boundary (the threat model and trust boundaries in the assurance case), combining that analysis with an Android-focused code/QA pass over the security-relevant areas (at-rest Keystore encryption, input and backup/import validation, CSV-injection neutralization, the permission surface and exported components, and the FLAG_SECURE / allowBackup / R8 hardening). No unresolved high-severity issues are known; residual risks are stated explicitly. URL: https://codeberg.org/godisch/potillus/src/branch/main/docs/ASSURANCE_CASE.md



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

    Met. Release builds apply R8 code shrinking and obfuscation (isMinifyEnabled = true) with resource shrinking and the optimizing ProGuard configuration. The manifest sets android:allowBackup="false" to prevent backup-based data exfiltration, and the app applies WindowManager FLAG_SECURE by default from cold start to block screenshots, screen recording, and Recents-thumbnail exposure. The permission set is minimal (no network or telephony; only USE_BIOMETRIC) and only the launcher activity is exported. These complement the hardware-backed Keystore at-rest encryption and the warnings-as-errors/lint gate. URL: https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts


 Uchanganuzi 1/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.

    No dedicated dynamic analysis tool (fuzzer, sanitizer, or scanner) is applied before releases, and branch coverage is not yet measured, so the "automated test suite with ≥80% branch coverage counts as dynamic analysis" allowance cannot yet be claimed. The instrumented tests do exercise the app on a device/emulator, but without a measured ≥80% branch-coverage figure this does not yet meet the criterion. Remediation is tied to the Kover branch-coverage work in docs/ROADMAP.md; alternatively a dedicated dynamic tool could be added.



    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.

    Not met (SHOULD). The criterion targets fault detection during dynamic analysis (testing), not production. The produced code contains a small number of always-on Kotlin preconditions (require/check/error) that are checked whenever the code runs, including under the test suite, but not "many". Remediation (tracked in docs/ROADMAP.md): add invariant assertions in the JVM-testable domain and data layers using Kotlin assert(), which Gradle's unit-test task runs with assertions enabled (-ea) by default, so they are checked during dynamic analysis while remaining disabled in ART release 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 Martin A. Godisch na wachangiaji wa nishani ya Mazoea Bora ya OpenSSF.

Ingizo la nishani ya mradi linamilikiwa na: Martin A. Godisch.
Ingizo liliundwa siku 2026-07-04 04:21:04 UTC, iliyosasishwa mara ya mwisho siku 2026-07-07 03:30:36 UTC. Ilipata mara ya mwisho nishani ya kupita siku 2026-07-04 08:45:54 UTC.