# Reporting a security problem in WLD

> **This policy is served by every installation and, since 2026-09-29, linked
> from the footer of every marketing-site page.** It has not been submitted to
> any disclosure directory. The response times under *What happens next* are
> commitments — decided by the owner on 2026-09-25 — though no real report has
> tested them yet, and the contact address is the company's general one until
> a dedicated `security@` mailbox exists (see *About the address*). Please do
> report anyway — the address is read. The mailbox and any directory listing
> are the owner's to arrange; nothing in this repository waits on them.

If you have found something, write to **jari.laurila@jalacons.com** and put
*security* in the subject line. You do not need permission first, you do not
need to be a customer, and you will not be asked to sign anything before the
report is read.

Please do not open a GitHub issue for it. Issues are the wrong place for a
finding that is not fixed yet, and in this repository they are the wrong place
in a second way: it is private, so an issue reaches fewer people than an email
and takes longer to do it.

## What to send

Enough to reproduce it. In practice that is:

- what you did, in the order you did it — a URL, a request, a payload;
- what happened that should not have;
- the version, which every installation prints in the footer of every page and
  on the sign-in page. It reads `WLD 2.1.3` — the release tag and nothing else.
  If you can sign in, **Settings → System settings** also carries the branch and
  the full revision; if you cannot, that same footer line holds the revision in
  its `title` attribute, which is worth sending, because two images built from
  one tag on different days are the same line of text and only the revision
  tells them apart;
- whether you needed an account, and if so what kind.

A proof of concept is welcome and never required. A vague report with a real
finding in it is worth far more than no report.

## What happens next

> **Decided by the owner on 2026-09-25** (issue #20 item 0). The times in
> this table are commitments, recorded the same way the five-year support
> period below was recorded on 2026-09-23.

| | |
|---|---|
| Acknowledgement that a person has read it | 3 working days |
| First assessment — is it real, how bad, what is affected | 10 working days |
| Fix or documented mitigation, for anything critical or high | 30 days |
| Fix, for everything else | the next release |
| Public description, by default | 90 days after the report, or when the fix ships, whichever is first |

If a date is going to be missed you will be told before it is missed, and why.
If we disagree about severity you will be told that too, with the reasoning,
rather than the report simply going quiet — a report that goes quiet is how a
researcher learns to publish first next time.

Credit is offered by name for anything reported here, unless you would rather
not be named. Nothing here is a bug bounty: there is no money.

## What we ask of you

- Test against your own installation, or against the public demo. Do not test
  against another company's data.
- Stop at the point where you have demonstrated the problem. Reading one record
  that proves the access control is wrong is a proof of concept; reading the
  table is not.
- Do not run denial-of-service tests, do not spam, and do not use social
  engineering against anybody at Jalacons or at a customer.
- Give us the time above before publishing. If the finding is being exploited
  already, say so — that changes the clock for everybody and we would rather
  know on day one.

Report in good faith within those lines and we will not pursue a claim against
you over the testing, and will say so to anyone who asks.

## What is in scope

WLD itself: the Django application, its templates and static files, the
container images, the nginx configuration and the deployment scripts in this
repository.

Out of scope, because they are somebody else's to fix: the hosting provider's
infrastructure, third-party services WLD integrates with (Zoho, Procountor, the
distributor APIs), and findings that amount to a missing hardening header with
no demonstrated consequence. Report those anyway if you think they matter;
they simply will not be treated as vulnerabilities in WLD.

## Which versions get fixes

Security fixes are made on the most recent release and shipped as a new one;
`CHANGELOG.md` records what each release contained and `dev-docs/RELEASING.md`
describes how one is made. **A version is supported for five years from its release.** Within that
period security fixes are made and shipped; after it, an installation still on
that version is asked to move to a supported one before a fix can be given.

Five years is what the Cyber Resilience Act expects unless the product's
expected lifetime is shorter, and an ERP that a company runs its production on
does not have a shorter one. Decided by the owner on 2026-09-23. (issue #20 item 2)

Jalacons hosts WLD as a service and operates every installation, but they do
not all run the same release: a customer's installation moves to a new release
when its upgrade is scheduled with that customer, so an earlier supported
release can be in service beside the current one. A security fix is made on
the current release, and an installation on an earlier one receives it by being
upgraded to a release that contains it, which Jalacons arranges with the
customer. The period above is what a customer can rely on, rather than a
promise to maintain old branches in parallel.

## About the address

`jari.laurila@jalacons.com` is the company's general business address, already
published on the marketing site. It is used here because it is a mailbox that is
demonstrably read, which is the only property that matters for a disclosure
contact, and because inventing an alias that nobody has agreed to monitor would
have been worse than useless. **A dedicated `security@jalacons.com`, routed to
whoever is on call, should replace it**; when it does, it needs changing in two
places — `CONTACT` in `core/security_txt.py`, which is what `/.well-known/`
serves, and the address written above in this file. Forgetting the second is a
failing test rather than a policy that sends half its readers to a dead mailbox:
`core.tests_security_txt.SecurityPolicyFileTests` asserts the two agree. Every
installation serves the new address on its next deployment.

There is no PGP key. If you need to send something you would rather not put in
plain mail, say so in the first message and we will agree a channel.

## Where this is published

Every WLD installation serves the machine-readable pointer at
`/.well-known/security.txt` (RFC 9116) and this document at
`/.well-known/security-policy.txt`. Both are served without a sign-in, because
the person who needs them does not have an account. On the marketing site, the
footer of every page links the policy as **Security**, beside the privacy
notice.