FileWarden - sample files for Marketplace reviewer testing
==========================================================

WHAT THIS IS
------------
Seven small files that exercise FileWarden's detection rules end to end, plus this
README. Upload them as attachments to a Jira issue on an instance with FileWarden
installed and watch what the app does to each one.

Every file is tiny, plain text, and harmless. Nothing here is a real executable, a
real credential, or a real person's data. See "SAFETY" at the bottom - please read
it before you flag anything in this zip.

What this README says is written against the app's source, and the expected strings
below were produced by running the real scanner over these exact files. Where this
README and the testing page on kuberstar.com disagree, the page is authoritative.


BEFORE YOU START - three settings facts, or nothing will appear to happen
------------------------------------------------------------------------
Files 03 through 06 are caught by CONTENT scanning, which is deliberately
conservative:

1. Content scanning is OFF by default. Turn on "Scan text attachments for secrets
   and PII", under Content security in the FileWarden admin page, first. With it
   off, files 03 through 06 are ignored and the app is working as designed.

2. Content scanning is a Pro feature. On an unlicensed instance the toggle is
   greyed out with a Pro badge and cannot be enabled - start the 30-day evaluation
   and it unlocks.

3. Content scanning does NOT run on the upload itself. The synchronous upload
   trigger has a 25-second budget, so byte-fetching work is deferred to the hourly
   background sweep. Expect a delay of up to 60 minutes, not an instant reaction.
   Only the type, size and name policy (files 01 and 02) reacts on upload.

Everything below also assumes the shipped defaults: enforcement on, monitor mode
off, grace period 0, quarantine off. Each of those settings changes what you see -
monitor mode logs instead of removing, a grace period delays the removal and posts
a warning comment first, and quarantine copies the file to a holding issue before
deleting it, which moves even file 01's removal onto the hourly sweep.

File 01 works out of the box with zero configuration. File 02 needs one setting
change, described below.


THE COMMENT
-----------
When FileWarden removes an attachment it posts one comment, built as:

  FileWarden removed the attachment "<filename>". <reason> Contact your Jira admin
  if you believe this is a mistake.

Only <reason> differs per file, so each file below gives its reason text. The
reasons are wrapped to this file's width; the real comment is a single line.

For a content-scan hit the reason names the RULE THAT MATCHED - never the matched
value. No fingerprint, no masked excerpt, no first-few-characters of the secret
appears in the comment: the comment carries the rule's human label and nothing
else. A file that trips several rules does not list them all; the reason names the
single highest-severity finding and counts the rest, as shown for 04 and 06.


THE FILES
---------

01-blocked-executable.exe
  What it is:   A plain text file named .exe. Not a binary, not an executable.
  Rule:         Type/size policy - extension blocklist. "exe" ships in the default
                blocklist, so this needs no configuration.
  Expect:       Removed on upload (synchronous path), within seconds. This is the
                fastest way to confirm the app is live.
  Reason:       Files of type .exe are not permitted by this project's attachment
                policy.

02-customer-db-dump.sql
  What it is:   A three-line SQL fixture. It creates a table and inserts one row
                with the city "Yerevan". No real data, no secrets.
  Rule:         Type/size policy - FILENAME PATTERN, admin-configured. Note that
                ".sql" is NOT in the default extension blocklist, and this file's
                contents match no content rule - it is your pattern, not the
                extension list, that catches this one.
  Expect:       NOTHING by default. To see it acted on, add the pattern
                *-db-dump.sql under "Filename patterns (one per line, * and ?
                wildcards)" in the admin page, save, then re-upload. Patterns are
                case-insensitive globs, not regular expressions. Removal is then
                immediate on upload, like 01 - a name is metadata, so no byte
                fetch is needed. This file demonstrates that the policy is
                admin-configurable; it is not a bug that it passes untouched until
                you configure it.
  Reason:       The file name "02-customer-db-dump.sql" matches a restricted
                pattern in this project's attachment policy.

03-leaked-aws-key.env
  What it is:   An .env file holding an AWS access key ID and a region.
  Rule:         Content scan -> aws-access-key (severity: critical).
  Expect:       Removed by the background sweep once content scanning is on.
  Reason:       Contained a likely secret or sensitive value (AWS access key ID).

04-customer-pii.csv
  What it is:   A CSV with one fake customer row: name, SSN, card number, email.
  Rule:         Content scan -> credit-card + us-ssn + email. The card is confirmed
                by a Luhn checksum, not just its shape.
  Expect:       Removed by the background sweep. Demonstrates PII detection, not
                just secret detection. Three rules match, but - as described under
                THE COMMENT - the reason names only the first and counts the other
                two.
  Reason:       Contained a likely secret or sensitive value (Credit card number)
                (and 2 other findings).

05-deploy-key.pem
  What it is:   An RSA private key in PEM format.
  Rule:         Content scan -> private-key (severity: critical).
  Expect:       Removed by the background sweep.
  Reason:       Contained a likely secret or sensitive value (Private key block).

06-ci-tokens.txt
  What it is:   A CI environment snippet with three different credential shapes.
  Rule:         Content scan -> github-pat + generic-secret (a high-entropy
                assignment, gated by a Shannon entropy floor) + slack-token.
  Expect:       Removed by the background sweep. Demonstrates that one file can
                trip multiple independent rules, and that each rule is counted
                once, not once per occurrence.
  Reason:       Contained a likely secret or sensitive value (GitHub personal
                access token) (and 2 other findings).

07-clean-release-notes.txt
  What it is:   Ordinary release-notes prose. No secrets, no PII.
  Rule:         None. This is the POSITIVE CONTROL.
  Expect:       NOTHING. This file must survive completely untouched - not removed,
                not quarantined, not commented on - even with content scanning fully
                enabled and every other file in this zip being acted on. If 07 is
                touched, that is a false positive and a real bug. Please test it
                alongside the others rather than skipping it; a scanner that catches
                everything is not the same as a scanner that is correct.


THIS README IS THE EIGHTH FILE, AND IT IS ALSO CLEAN
----------------------------------------------------
README.txt is itself a .txt file, so it is scannable: the content scanner would
read it like any other text attachment. It is written to contain nothing that trips
a rule - it describes the sample values by shape rather than quoting them, which is
why you will not find a literal key, card number or SSN anywhere in this text.

So if you drag the whole extracted folder onto an issue, all eight files are
uploaded and exactly the predicted ones are acted on. This README, like 07, must
survive untouched. Nothing in this zip is removed that this README does not
predict.


SAFETY - everything sensitive-looking in this zip is FAKE
---------------------------------------------------------
No file here contains a live credential, a real secret, or any real person's data.
Specifically:

* The AWS access key ID in 03 is the AKIA-prefixed example key published in
  Amazon's own public documentation. It is a documented non-functional placeholder
  and has never been valid against any AWS account.

* The card number in 04 is the industry-standard Visa test number that every
  payment gateway documents. It is Luhn-valid by construction - which is exactly
  why it is useful here, because it proves the checksum path runs - but it belongs
  to no issuer and no account.

* The SSN, name, and email in 04 are invented. The SSN is a nine-digit value in the
  standard three-two-four grouping and is not issued to anyone. "Jane Roe" is a
  placeholder name, and the address uses example.com, the domain IANA reserves for
  documentation. No real individual is represented.

* The private key in 05 is a throwaway RSA keypair generated solely for this zip.
  Its public half was never deployed anywhere, it authorizes access to nothing, and
  it will never be used again. It is key-shaped bytes and nothing more.

* The three credentials in 06 are randomly generated strings matching the published
  FORMAT of a GitHub personal access token, a Slack bot token, and a generic
  high-entropy assignment. They were never issued by GitHub or Slack and authorize
  nothing.

The point of the zip is that these values are realistic enough to trip real
detection rules while being safe enough to email, archive, and commit. If your own
secret scanner alerts on the sample files, that is the sample set doing its job.


WHERE THESE BYTES GO
--------------------
Nowhere outside Atlassian. FileWarden declares no external permissions at all: an
attachment's bytes are fetched from the Jira REST API and scanned in-process on
Atlassian's own infrastructure, and no part of a file is sent to any third party or
to us.

The matched value never leaves the scanner either. It is not written to the Jira
comment, which carries only the rule's label as shown above; it is not written to
the audit log, which stores that same reason string; and the app's own logs record
only which rule ids matched and how many, never the value or the file's contents.
