From 26f49e68198b73a897f719ce50d236bc94c0ca80 Mon Sep 17 00:00:00 2001 From: FenjuFu <92919259+FenjuFu@users.noreply.github.com> Date: Thu, 27 Aug 2026 15:07:42 +0800 Subject: [PATCH] docs(governance): add DPGA policy evidence Validated documentation, links, markdown checks, and CI. --- CODE_OF_CONDUCT.md | 15 +- README.md | 12 ++ docs/CONTENT_SAFETY.md | 220 ++++++++++++++++++++++++++++ docs/PRIVACY_AND_DATA_GOVERNANCE.md | 187 +++++++++++++++++++++++ 4 files changed, 432 insertions(+), 2 deletions(-) create mode 100644 docs/CONTENT_SAFETY.md create mode 100644 docs/PRIVACY_AND_DATA_GOVERNANCE.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index f1dc7ad0..4eba979d 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -29,5 +29,16 @@ project spaces. ## Reporting -Report conduct issues privately to the maintainers through a private maintainer -channel. Do not use public issues for personal or sensitive reports. +Report conduct issues privately to +[ifly_opensource@iflytek.com](mailto:ifly_opensource@iflytek.com) with the subject +`SkillHub Code of Conduct report`. Do not use public issues for personal, sensitive, +or confidential reports. + +Reports are handled under the iFLYTEK community +[incident resolution procedures](https://github.com/iflytek/community/blob/master/code-of-conduct/coc-incident-resolution-procedures.md). +Information is shared only with people who need it to review the report, protect +participants, or comply with law. Retaliation for a good-faith report is prohibited. + +People materially affected by a conduct decision may request an impartial review +through the appeal process in the +[Content Safety Policy](docs/CONTENT_SAFETY.md#appeals). diff --git a/README.md b/README.md index 3a01513a..150c2729 100644 --- a/README.md +++ b/README.md @@ -66,6 +66,18 @@ with the Skill's source and the problem it solves, or submit a PR by following t - 🛠️ **[Developer Docs](https://zread.ai/iflytek/skillhub)** — Architecture, API reference, local development, deployment and operations - 🐍 **[Python Examples](./examples/python)** — Search, download, and publish skills from Python via the REST API +## Governance and Safety + +- **[Privacy and Data Governance](docs/PRIVACY_AND_DATA_GOVERNANCE.md)** — + Data categories, operator responsibilities, retention, portability, and incident + handling for public and self-hosted instances +- **[Content Safety](docs/CONTENT_SAFETY.md)** — Package safety expectations, + review and reporting controls, appeals, and child-safety responsibilities +- **[Code of Conduct](CODE_OF_CONDUCT.md)** — Community standards and the private + reporting channel +- **[Security Policy](https://github.com/iflytek/.github/blob/main/SECURITY.md)** — + Private vulnerability reporting and coordinated disclosure + ## Highlights - **Self-Hosted & Private** — Deploy on your own infrastructure. diff --git a/docs/CONTENT_SAFETY.md b/docs/CONTENT_SAFETY.md new file mode 100644 index 00000000..6637b5e9 --- /dev/null +++ b/docs/CONTENT_SAFETY.md @@ -0,0 +1,220 @@ +# Content Safety Policy + +Last updated: August 18, 2026 + +## Purpose and scope + +SkillHub accepts, stores, reviews, and distributes agent skill packages. Packages +can contain instructions, scripts, documentation, examples, images, and other files +that influence an AI agent or execute on a user's computer. Profiles, namespace +descriptions, reviews, reports, ratings, and release notes also contain user-supplied +content. + +This document describes the project's content-safety expectations, available +technical and governance controls, and the responsibilities of people who publish, +review, operate, and install skills. + +The SkillHub maintainers do not operate or moderate every independently hosted +instance. Each operator must assess its users, jurisdiction, deployment model, and +risk; publish enforceable rules and a reporting channel; configure appropriate +controls; and staff its own review, appeal, and emergency processes. + +## Baseline rules + +SkillHub instances should not knowingly publish or distribute content or packages +that: + +- violate applicable law or another person's intellectual-property, privacy, or + other rights; +- sexually exploit or endanger children, including child sexual abuse material; +- credibly threaten, harass, or promote violence or hateful abuse against people; +- expose personal, confidential, or authentication data without authorization; +- contain malware, credential theft, destructive payloads, unauthorized access, + persistence, evasion, or instructions intended to defeat security controls; +- impersonate people or organizations, facilitate fraud, or intentionally present + deceptive or materially misleading claims; +- secretly collect, transmit, or use data beyond the skill's documented purpose; +- conceal important external services, downloads, commands, permissions, or side + effects from reviewers and users; or +- bypass an instance's review, scanning, namespace, visibility, or access-control + rules. + +Context matters. Legitimate security research, education, documentation, and +defensive automation can discuss or test risky behavior without promoting harm. +Reviewers should consider purpose, provenance, permissions, likely impact, and +applicable law instead of relying on keywords alone. + +## Content and package risks + +A skill may instruct an agent to read or modify files, run commands, call external +services, install dependencies, browse websites, or handle sensitive inputs. +Documentation and examples may be inaccurate or omit important consequences. +Images and archives may contain hidden payloads. Ratings or social signals do not +prove that a package is safe, lawful, accurate, or suitable for a particular use. + +Publishers must accurately describe required permissions, external recipients, +dependencies, expected side effects, supported environments, and known limitations. +Installers must review package contents and apply least privilege before execution. + +## Available technical and governance controls + +SkillHub includes controls that an operator can combine according to its risk: + +- package limits and file-type validation, including size, file-count, extension, + and selected file-signature checks; +- a configurable security scanner that can inspect uploaded packages and produce + findings for reviewers; +- namespace and platform review workflows with approve, reject, withdraw, and + promotion decisions; +- user reports and administrator actions such as hiding, archiving, rejecting, or + yanking content and versions; +- platform and namespace RBAC for publishing and governance actions; +- public, namespace-only, and private visibility; and +- audit records and notifications for relevant governance activity. + +The implementation and operating guidance are documented in the +[scanner guide](security-scanning.md), +[review guide](skillhub/en/guide/review.md), and +[security architecture](../document/docs/04-developer/architecture/security.md). + +## Important limitations + +These controls reduce risk but do not certify a package as safe or compliant: + +- scanner operation is configurable, and an operator can run SkillHub without an + enabled scanner; +- optional LLM-backed analysis depends on the service selected by the operator and + can create additional privacy and reliability risks; +- static, behavioral, metadata, and model-based analysis can produce false + positives and false negatives; +- a successfully scanned package can still be misleading, vulnerable, or + malicious in context, or unsuitable for a specific environment; +- privileged publication paths require operator governance and periodic review; + and +- independently hosted instances can configure different review, visibility, and + enforcement practices. + +Operators must disclose which controls are active. A package that fails scanning +or review should remain unavailable for ordinary installation until the failure +is resolved through a documented process. Scanner failure must not be treated as +proof that a package is safe. + +## Publisher responsibilities + +Before submitting a skill, a publisher should: + +- inspect every included file and remove secrets, personal data, build artifacts, + and unrelated binaries; +- document commands, network destinations, external downloads, required + permissions, and persistent changes; +- pin or constrain dependencies where practical and preserve their license notices; +- provide evidence for security, compliance, or standards claims instead of relying + on labels alone; +- test failure and rollback behavior in an isolated environment; +- avoid manipulative instructions designed to override system, user, or operator + safety controls; and +- update or withdraw a package when a material risk is discovered. + +## Operator safeguards + +Before opening an instance to publishers or installers, an operator should: + +- define permitted and prohibited content, reviewers, escalation owners, and + emergency contacts; +- enable scanning and human review appropriate to the instance's exposure and + package risk; +- restrict direct-publish and governance roles, log their use, and review them + regularly; +- isolate scanning and package inspection from production secrets and sensitive + networks; +- rate-limit uploads, downloads, reports, and automated activity; +- preserve only the evidence needed for review and protect reporter identities; +- provide a visible reporting channel and an impartial appeal route; and +- train reviewers to handle malware, privacy, child-safety, fraud, and + intellectual-property reports safely. + +## Reporting + +For a skill or profile visible in a SkillHub instance, use that instance's report +feature or contact the operator identified in its published policies. Include the +package coordinate and version, the reason for concern, the time observed, and the +minimum context needed to investigate. Do not execute a suspected malicious package +or resend illegal, exploitative, personal, or confidential material through an +unprotected channel. + +For abusive or harassing conduct on SkillHub project-managed community surfaces, +report privately to +[ifly_opensource@iflytek.com](mailto:ifly_opensource@iflytek.com) under the +[Code of Conduct](../CODE_OF_CONDUCT.md). Report upstream security vulnerabilities +privately to [security@iflytek.com](mailto:security@iflytek.com) under the +[iFLYTEK organization security policy](https://github.com/iflytek/.github/blob/main/SECURITY.md). +Do not disclose vulnerabilities or personal data in a public issue. + +## Review, action, and notice + +An operator's documented process should: + +1. triage imminent danger, child-safety concerns, credible malware, exposed + credentials, and active security incidents for urgent specialist handling; +2. preserve only the evidence needed for a proportionate review; +3. assess the package, context, applicable rule, law, provenance, permissions, and + likely user impact; +4. take proportionate action, such as rejecting a version, hiding or yanking a + package, restricting an account, revoking a token, or escalating to an authorized + specialist; +5. record the rule, evidence, and rationale and notify affected people when lawful + and safe; and +6. provide an appeal route and use confirmed incidents to improve controls. + +SkillHub's review guide recommends completing routine package reviews within 24 +hours to avoid blocking publishers. That recommendation is not a historical average +for safety reports and is not an emergency-response guarantee. The upstream project +does not yet have enough comparable safety reports to publish a meaningful average +assessment or action time. Each operator must publish targets appropriate to its +risk, staffing, and legal obligations, with an urgent path for imminent harm and +child safety. + +## Appeals + +A publisher, reporter, account holder, or other person materially affected by a +governance decision should be able to request review through the instance +operator's private channel. The request should identify the original decision and +give a reason for review, such as significant new evidence, a material procedural +error, a conflict of interest, or a clearly disproportionate action. + +Appeals should be handled by a person who did not make the original decision and +has no conflict of interest. The reviewer may uphold, modify, or reverse the action, +or require a new investigation. Temporary protective measures may remain in place +while needed to protect people, systems, evidence, or legal obligations. + +For Code of Conduct decisions on project-managed community surfaces, send an appeal +to [ifly_opensource@iflytek.com](mailto:ifly_opensource@iflytek.com) with the +subject `SkillHub Code of Conduct appeal`. Include the original case reference, +the outcome being challenged, and the reason for review. Appeal information must +be limited to people who need it. Retaliation for a good-faith report or appeal +is prohibited. + +## Children and young people + +SkillHub is a general-purpose developer and enterprise collaboration tool, not a +child-directed service. An operator that permits use by children or processes their +data must perform an age-appropriate risk assessment, use any legally required +parental or guardian consent, minimize collection and profiling, restrict contact +and high-risk package capabilities, provide child-accessible notices and reporting, +and route serious concerns to trained personnel and appropriate authorities. + +If those protections cannot be provided, the instance should not be offered to +children. The project Code of Conduct separately protects community participation +from harassment regardless of age. + +## Privacy and policy review + +Package inspection, reports, audit logs, and investigations can expose sensitive +information. They must follow the +[Privacy and Data Governance Policy](PRIVACY_AND_DATA_GOVERNANCE.md) and the +instance's own privacy notice and retention schedule. + +Material changes to this policy are made through the repository's public review +process. Operators should periodically test their controls, review incident trends, +and update their policy when the product, threat model, law, or operating context +changes. diff --git a/docs/PRIVACY_AND_DATA_GOVERNANCE.md b/docs/PRIVACY_AND_DATA_GOVERNANCE.md new file mode 100644 index 00000000..3632e31d --- /dev/null +++ b/docs/PRIVACY_AND_DATA_GOVERNANCE.md @@ -0,0 +1,187 @@ +# Privacy and Data Governance Policy + +Last updated: August 18, 2026 + +## Purpose and scope + +SkillHub is open-source software for publishing, reviewing, discovering, and +installing reusable agent skill packages. This document describes the project's +privacy and data-governance expectations and the controls available to people who +operate SkillHub instances. + +The SkillHub maintainers publish source code and project infrastructure. They do +not operate or control every independently hosted instance. The organization or +person operating an instance determines why and how personal data is processed in +that environment and is responsible for publishing an instance-specific privacy +notice, selecting lawful processing grounds, handling data-subject requests, and +complying with applicable law. + +The public SkillHub service also publishes an in-product +[privacy notice](https://skill.xfyun.cn/privacy). This project document supplements +that notice for source-code reviewers and self-hosted operators. It is not legal +advice and does not certify that every deployment is automatically compliant with +any law. + +## Applicable law + +Privacy and data-protection obligations depend on the operator's legal entity, +where the instance and its users are located, the people it serves, the data in +skill packages, and the infrastructure and integrations selected by the operator. + +Before processing personal data, each operator must: + +- identify and document the domestic and international laws that apply; +- determine and record the lawful basis for each material processing purpose; +- complete any required privacy, child-safety, security, or transfer assessment; +- reflect those obligations in notices, contracts, procedures, and configuration; + and +- avoid or redesign processing that cannot be operated lawfully. + +Open-source availability and configurable controls support implementation. They +do not replace an operator's legal analysis or operational responsibilities. + +## Data the software can process + +The exact data depends on the authentication, storage, email, observability, +scanner, and deployment options selected by the operator. A SkillHub instance can +process: + +- account and identity data, such as username, email address, avatar, OAuth + provider identifiers, account status, platform roles, and namespace membership; +- authentication and security data, such as session identifiers, password hashes, + API token metadata, login events, IP addresses, device or browser information, + and password-reset records; +- skill package content, including `SKILL.md`, scripts, documentation, images, + examples, license files, archives, and version metadata; +- collaboration and governance data, such as namespaces, reviews, review comments, + promotion requests, reports, ratings, stars, notifications, and audit records; +- usage and operational data, such as searches, downloads, request identifiers, + timestamps, errors, metrics, traces, application logs, and security findings; + and +- configuration and connection data for object storage, identity providers, email, + monitoring, and optional scanning services. + +A skill package, review comment, profile, log entry, or security report can contain +personal, confidential, or authentication data even when a field is not labelled +as personal data. Operators and publishers must classify data according to its +actual content and use. + +## Roles and responsibilities + +For an independently operated instance, the instance operator normally decides the +purposes and means of processing and must document its role under applicable law. +Publishers and namespace administrators are responsible for the content they upload +and the access decisions they make. External identity, storage, email, monitoring, +and scanner providers may process data under their own terms and assigned roles. + +The upstream SkillHub maintainers generally cannot access, correct, export, or +delete data held by an independently operated instance. Requests concerning an +instance must go to the operator identified in that instance's privacy notice. + +## Purpose limitation and data minimization + +Data should be collected only when needed to authenticate users, enforce access +rules, publish and distribute skill packages, operate review and governance +workflows, secure and troubleshoot the instance, and meet documented legal duties. + +Operators, administrators, and publishers should: + +- avoid placing secrets or unnecessary personal data in skill packages, README + files, examples, namespace profiles, reviews, or report details; +- use pseudonymous or organization-scoped identifiers where practical; +- configure the shortest retention and least visibility needed for each purpose; +- redact sensitive values before sending packages or findings to an external + scanner, model, log sink, or support channel; +- restrict privileged roles and review them regularly; and +- document the source, purpose, recipients, lawful basis, and retention period for + each material category of personal data. + +## Storage, access, and isolation + +SkillHub supports authenticated access, platform and namespace RBAC, public, +namespace-only and private visibility, audit logs, hashed API tokens, PostgreSQL, +Redis, and local or S3-compatible object storage. These capabilities are building +blocks, not a secure deployment by themselves. + +Operators are responsible for: + +- disabling development authentication and replacing example credentials before + exposing an instance; +- using HTTPS for external traffic and protected networks for internal services; +- applying least-privilege roles to users, services, databases, caches, and object + stores; +- encrypting sensitive data and backups according to their threat model and legal + obligations; +- storing secrets in an appropriate secrets manager rather than source code, skill + packages, client-side configuration, or logs; +- testing namespace and object-storage isolation for their configuration; +- restricting and monitoring access to packages, audit data, logs, traces, backups, + and security findings; and +- applying supported security updates and maintaining a recovery process. + +## External services and international transfers + +OAuth providers, S3-compatible storage, email services, monitoring systems, +mirrors, and optional scanner integrations can receive data from a SkillHub +instance. An operator that enables an external service must assess its privacy and +security terms, hosting locations, retention, subprocessors, training-data rules, +and cross-border transfer mechanism. + +The optional scanner can process uploaded skill archives and findings. If an +operator enables an external or LLM-backed scanner, that disclosure must be covered +by the instance's privacy notice and data-flow review. A service does not become +private merely because SkillHub can integrate with it. + +## Retention, deletion, and portability + +The open-source project does not impose one retention period on independently +operated instances. Each operator must publish periods that are no longer than +necessary for its purposes and legal duties. + +A deletion process should cover account and namespace records, package objects, +reviews, reports, ratings, notifications, security findings, caches, audit records, +logs, traces, exports, and backups. Where immediate backup deletion is not +practical, deleted data should be isolated from normal use and expire under a +documented schedule. Operators must also account for copies already disclosed to +external providers or downloaded by authorized users. + +Operators should provide authenticated channels for access, correction, deletion, +restriction, objection, and portability requests where applicable. Requests should +be verified, recorded, completed within legally required time limits, and denied +only on a documented basis. + +Skill packages can be downloaded as archives and installed through the CLI. Public +APIs expose package and metadata workflows. Operators should separately document +which instance records can be imported or exported, their non-proprietary formats, +version compatibility, and any PII excluded from an export. + +## Security and incident handling + +Security vulnerabilities in the upstream project must be reported under the public +[iFLYTEK organization security policy](https://github.com/iflytek/.github/blob/main/SECURITY.md) +and its detailed +[community security policy](https://github.com/iflytek/community/blob/master/SECURITY.md). +Send vulnerability details privately to +[security@iflytek.com](mailto:security@iflytek.com), not in a public issue. + +Instance operators remain responsible for monitoring their environments, +maintaining an incident-response plan, preserving proportionate evidence, rotating +affected credentials, applying fixes, and notifying users or authorities where +required. + +## Project and instance contacts + +- Report an upstream security vulnerability privately to + [security@iflytek.com](mailto:security@iflytek.com). +- Send questions about this project policy to + [ifly_opensource@iflytek.com](mailto:ifly_opensource@iflytek.com). Do not include + personal data or confidential incident details in a public GitHub issue. +- Contact the operator named in an instance's privacy notice for data-subject + requests or incidents involving that instance. + +## Governance and changes + +Privacy-impacting changes should be reviewed for data minimization, access and +namespace boundaries, package visibility, external disclosures, retention, +logging, deletion, and portability. Material changes to this document are made +through the repository's public review process, and the file history records them.