Keelcroft / GitHub Issues Sync for Jira / Privacy

Privacy Policy

Effective 27 September 2026. GitHub Issues Sync for Jira is published by Keelcroft. Privacy contact: support@keelcroft.com.

October 27 release-candidate update, DEV 2.22; production pending. This prepared update describes the next release. Optional auto-create, comments and assignee data flows below apply only when enabled by an administrator. Marketplace Privacy & Security publication and production rollout are pending; this is not a claim that the candidate is already released.

Scope

This policy explains how GitHub Issues Sync for Jira processes information when installed in Jira Cloud. The app runs entirely on Atlassian Forge. There is no vendor-hosted backend: Forge calls GitHub directly, and no customer data is relayed through infrastructure operated by Keelcroft. The app contains no advertising, no external analytics, and no AI services.

Information transferred to GitHub

Only the fields a project administrator has enabled for the Jira to GitHub direction, for manually linked pairs or issues that match the administrator's optional automatic-creation rule. Without a trigger label, only new issues created after sync was enabled qualify; a chosen trigger label can also include older issues.

• The issue summary, written as the GitHub issue title.
• The issue status, translated to open or closed through the status map you set.
• The issue labels.
• The issue description as plain text, only if you switch it on. It is off by default.
• The mapped assignee, only if enabled using explicit Jira account ID to GitHub login pairs supplied by an administrator. The app manages the first GitHub assignee, preserves additional assignees and blocks unassignment if it would remove them.
• New comments added after linking, if comment copying is enabled in that direction, including the text, source author's display name/login and a source marker. Restricted and internal Jira comments and pull-request comments are excluded. Comment edits and deletions are not mirrored.

Titles, descriptions, labels, comments and author names may contain personal information. Jira account IDs and GitHub logins are personal data too. Anything copied to a public GitHub repository is public; otherwise it is visible to people who can access that repository. The app does not copy files/attachments, worklogs, arbitrary custom fields, reporters, watchers or native priority. It does not convert Markdown into Jira rich text or search the user directory.

Comment reads are bounded to five pages of 100 per platform per pass, with incomplete histories failing closed. At most 10 comments per direction are copied per pass and source text beyond 30,000 characters is visibly shortened. New connections default comments to both directions; legacy connections with no comment setting remain off on save unless explicitly enabled.

Information transferred to Jira

The mirror of the above, for enabled GitHub to Jira directions: issue title, open or closed state, labels and optionally the body as plain text, the explicitly mapped first assignee and new issue comments with source author names/markers. Auto-create can create a matching Jira issue when its configured rule permits it.

Signed inbound GitHub webhook payloads can contain issue and comment content, author names and assignee information even when those fields are not selected for copying. Forge processes the payload to validate and route the event; it does not persist the raw body in the app's durable queue or event journal. Issue/comment content is read transiently during a sync pass. Comments are not retained as a separate app archive; copies written to Jira or GitHub remain on those platforms.

Information stored by the app

• Connection settings: the GitHub API URL, repository owner and name, field/status maps, optional assignee mappings containing Jira account IDs and GitHub logins, comment and auto-create rules, conflict policy, enable boundary and webhook identifier.
• Link records: the Jira issue ID and key, the GitHub issue number and URL, per-field content digests, agreement state, timestamps and non-content diagnostics. SHA-256 digests are not encryption or anonymization: low-entropy values, such as a small set of statuses, can be guessed and compared with a digest.
• An event journal recording the origin of each change, the identifiers of the two records involved, the outcome, which fields were written, and any verification mismatch. It does not store issue content, which is why a replay always re-reads both platforms rather than reusing a stored copy.
• Comment-copy claims: an opaque key derived from link/platform/comment identifiers and a timestamp, not comment text. Claims are normally removed after a pass. A stale claim can be reclaimed after 10 minutes; this is not a guaranteed automatic deletion TTL.

Credentials

The GitHub personal access token you supply, and the webhook signing secret this app generates, are written to Atlassian Forge encrypted secret storage. They are never returned to the app's user interface, never written to a log, and never sent anywhere other than the GitHub endpoint below. The interface only ever reports whether a token is present.

External destinations

• api.github.com — reading and writing issues and enabled comments/assignees, checking connection health and managing the repository webhook.
• A host your own administrator adds — GitHub Enterprise Server only, through Atlassian's customer-managed egress controls. The app cannot add hosts itself; live Enterprise Server behavior remains unverified.

This release adds no new egress destination or Jira scope. Assignee mapping does not require the read:jira-user user-directory scope.

Authorization and retention

Creating, changing, enabling or disabling a connection, checking health, repairing a webhook, linking, unlinking and replaying all require Jira project administrator rights, re-checked on the server for each request using the signed project context. Connections are project-scoped. Background processing runs as the app and does not perform a fresh initiating-user permission check on every queued step; teammate permission behavior has not been live-verified.

• Connection settings, optional assignee mappings, link records and lookup entries are durable with no automatic TTL. They remain until the relevant settings are replaced/manually removed, a pair is unlinked, or Forge storage is deleted following uninstall. Unlink removes the pair/indexes, not the connection/mappings or journal history.
• Event journal entries expire 90 days after their latest write.
• Comment-copy claim metadata has the cleanup/reclaim behavior described above, not a 10-minute automatic-deletion promise.
• Pause clears the webhook signing secret and attempts webhook deletion, but retains the stored personal access token, settings/mappings, links and history. There is no general disconnect/delete-connection UI.
• Uninstall initiates removal of this installation's Forge data under Atlassian's 0–28-day hosted-storage retention/deletion window; it is not immediate erasure or deletion limited to one project. It does not delete issues/comments already copied or revoke your GitHub token.

Contact

Send privacy, access or deletion questions to support@keelcroft.com. Report suspected vulnerabilities to the same address with the subject line “Security”. Include the Jira site, but never send passwords or API tokens.