Kjell Tore Guttormsen
28a420ab97
Fase 3 (AAA+ på publisert flate). Tre av planens premisser falt på måling og er rettet FØR handling, ikke etterpå: * GOVERNANCE-raden hadde feil tiltak. Planen sa «skriv den»; org-ops D11 sier én kanonisk fil som hvert repo LENKER, og filen er nå publisert (målt: HTTP 200 på open/repo-standard). Å skrive vår egen ville gjort oss til kopi nr. 12 av en fil D11-bølgen holder på å rydde vekk. README lenker den, i samme form som repo-mailbox bruker, og bus-faktor 1 står uttalt i den kanoniske teksten. * Release-objektet for v1.0.0 FINNES allerede på open/ (id 155, CHANGELOG-kropp, siden rendrer) — det som mangler er vedlegg, ikke objektet. * WARN RELEASE-STALE fyrer ikke, og kan ikke: regelen sammenligner utgivelse mot tagg og er strukturelt blind for repo med null utgivelser (org-ops hovedbok #18). Gaten var OK/20 sjekker FØR arbeidet startet, så den kan ikke tjene som verifikasjon for denne fasen. Bevisene er Forgejo-APIet, filinnholdet og ren-klon-kjøringen. A5-defekten rettet: env.template:21 sa at credential resolves via DefaultAzureCredential. Den har aldri gjort det — backends.py:149 konstruerer ManagedIdentityCredential eller AzureCliCredential, og Learns MAF-veiledning navngir den spesifikke credentialen NETTOPP for å unngå probing. En operatør som kopierte templaten ble fortalt at feil identitet ville bli brukt. To load-bearing gater (Iron Law: begge røde før fiksen, 2 failed / 7 passed): 1. env.template navngir de credentials backends.py faktisk konstruerer, og ingen linje utgir DefaultAzureCredential for å være mekanismen. LINJEFORANKRET, ikke delstreng: backends.py NAVNGIR klassen fire ganger i kommentarene som begrunner hvorfor den ikke brukes, så en fil-bred substring-gate ville vært rød på nøyaktig den prosaen den beskytter (repoets 08-09-klasse, fjerde gang). 2. README-ens wheel-filnavn bærer versjonen bygget stempler på fila. Uten den ville en versjonsbump stille etterlatt en publisert install-kommando som peker på en fil som ikke finnes. Hver positiv assert er paret med en KONTROLL på at det søkes etter noe som finnes — en ekstraktor som stille finner null lager en gate som bare kan bli grønn. MUTASJONER MÅLT MOT HELE SUITEN, begge røde på riktig test og på INGEN annen: gjeninnfør den usanne credential-påstanden (2 røde, 844 grønne) · la wheel-filnavnet drifte til 1.0.0 (1 rød, 845 grønne). Restaurert fra scratchpad + shasum -c mellom hver. Bumpen selv var den andre mutasjonen: pyproject 1.0.0 → 1.1.0 gjorde README-gaten rød alene, før README ble rettet. SECURITY.md: varslingsfrist (minst én minor-release og aldri under 30 dager mellom kunngjøring og fjerning, med sikkerhetskritisk fjerning som uttalt unntak). Støttetabellen er bevisst VERSJONSFRI — et release-nummer skrevet der ville drevet ved neste tagg, altså samme defektklasse som gate 2 fanger. CLAUDE.md beholdt på flaten med en engelsk innramming øverst (operatørvalg): den sier hva fila er for en fremmed. Innholdet er repoets sterkeste bevis på at hver beslutning er målt; å fjerne det ville fjernet bevis, ikke friksjon. Versjon 1.1.0 — synket i pyproject, __init__, test_smoke og README-kommandoen. 1.0.0-treet kan ikke produsere en kjørbar wheel (force-include kom etter taggen, målt: git show v1.0.0:pyproject.toml har den ikke), så en wheel hengt på den utgivelsen ville vært nøyaktig den usanne påstanden denne fasen finnes for å fjerne. Operatøren valgte bumpen framfor et vedlegg som ikke virker. 846 passed / 4 skipped (fra 837). ruff + format + mypy rene. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011ckyg3Pc6k7FRuR6fDGQLJ
2.6 KiB
2.6 KiB
Security Policy
Reporting a Vulnerability
We take security seriously. If you discover a security vulnerability, please report it responsibly.
Please do NOT report security vulnerabilities through public issues.
How to Report
Email: hello@fromaitochitta.com
Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Any suggested fixes (optional)
What to Expect
- Acknowledgment within 48 hours
- Regular updates on progress
- Credit in the fix announcement (if desired)
Supported Versions
Support follows the tags, not a calendar, and the table is deliberately version-free — a release number written here would drift the moment the next tag lands.
| Version | Security fixes | What that means |
|---|---|---|
| Newest tagged release | ✅ best-effort | Fixes land on main and ship in the next tag |
| Every earlier tag | ❌ | Earlier tags are never re-released. Upgrade, or fork and patch |
There is no long-term-support branch and no backporting. One maintainer, best-effort.
Deprecation Notice Period
When a supported surface is removed, or a dependency stops receiving security fixes:
- The deprecation is announced in
CHANGELOG.mdunder the release that introduces it, and repeated in the release notes on the forge. - At least one minor release — and no fewer than 30 days — passes between that announcement and the removal, so anyone reading the changelog has a version to move to before the old one goes.
- The stated exception is a security-critical removal. If leaving a surface in place is itself the risk, it goes in the next release and the changelog says plainly why the notice period was not used. This has not happened so far.
This is a notice period, not an SLA. See the organisation governance for what this project does and does not promise.
Security Best Practices
When using portfolio-optimiser:
- Keep dependencies updated
- Use environment variables for sensitive configuration — never commit secrets
- Prefer the local-only backend profile; the framework makes no silent network egress
- Follow the principle of least privilege for any data-source credentials
Scope Note
portfolio-optimiser is a technical framework. Deploying organizations own their own data protection, risk, and compliance assessments (DPIA/ROS). The framework ships technical prerequisites (local-only mode, provenance, no silent egress) but makes no compliance guarantees.