Source and Verification Policy

Source and verification policy

Putty.info separates educational commentary from machine-verified facts such as current release numbers. This policy explains how sources are chosen and labeled.

Primary sources we prefer

• Official PuTTY project home, download/latest pages, documentation, FAQ, licence, and changelog.
• Project vulnerability/security notices when published.
• OS and cloud vendor documentation for server-side SSH behaviour.
• CVE records and vendor advisories when discussing vulnerabilities.

Verification states

Automated monitors may mark upstream pages as unverified, verified, stale, failed, or manual_review. Unverified parser output does not silently replace last-known verified release data on public version cards. If our release card cannot validate the latest page, we hide “verified download” affordances rather than inventing a version.

Linking rules

Download CTAs should reveal destination domains and resolve only to allowlisted official hosts after verification. Educational deep links may point to official HTML documentation and latest.html. We avoid third-party binary mirrors that are not part of the project’s published distribution story.

Quotations

We paraphrase for teaching and link to primary pages. Extended verbatim reproduction of official manuals is avoided. Error message strings may be quoted for matching user search intent.

When sources change

If upstream renames packages or changes verification instructions, we update download/security articles in editorial priority order. Readers should still confirm against official pages before fleet rollout.

Field notes and runbook extras

Additional operational depth for Source and Verification Policy (path /source-policy/): treat every change to authentication, forwarding, or host-key storage as a reversible change under change control. Record the PuTTY version string from Help → About, the Windows build, and whether Pageant was running. Those three facts explain a surprising fraction of “it works on my laptop” discrepancies.

When documenting the procedure for teammates, include: the saved session name, Host Name and Port from the Session panel, whether Connection type is SSH, the username, whether a PPK path is set under Connection → SSH → Auth, and whether agent forwarding is enabled. Explicitly state that Putty.info is an independent educational site and that binaries must be obtained from the official project download page. Link readers to safe download guidance, host key verification, and the official manual so they can cross-check labels that differ slightly across releases.

If you still need more diagnostics after following the sections above, reproduce the issue with logging enabled under Session → Logging to a local file you control, scrub secrets from the transcript, and compare against server auth logs for the same UTC timestamp. Avoid third-party “PuTTY fix” utilities. Prefer updating to the current stable release from official hosts, re-importing a known-good saved session, and testing from a second network path before declaring the workstation broken.

• Keep private keys passphrase-protected and backed up offline according to your organization's secret-handling policy.
• Prefer named saved sessions over ad-hoc connections for anything beyond a one-off debug.
• Disable unused tunnels and agent forwarding by default; enable them per session only when required.
• Schedule periodic key rotation and remove stale authorized_keys entries during access reviews.
• Teach new operators the difference between connection errors and authentication errors before giving them production bastion access.