huawei-cloud-cdn-export-obs@1.0.4
CAUTIONPublisher claims: "1. Query the Huawei Cloud CDN (Content Delivery Network) accelerated-domain list of a tenant through KooCLI (`hcloud CDN ListDomains`, the official read-only GET /v1.0/cdn/domains), with an automatic fallback to the official huaweicloudsdkcdn v1 SDK (CdnClient.list_domains) when hcloud is not installed. 2. Serialize the result into a local file — `--format json` (raw array, default) / `csv` (RFC-4180 flat table) / `md` (Markdown table whose first column is 域名) — written atomically (temp file + rename). 3. Upload the result file to a user-specified OBS bucket + object key through KooCLI's obsutil-backed OBS module (`hcloud OBS cp`), with a fallback to the official huaweicloudsdkobs v1 SDK (ObsClient.put_object) when hcloud is absent. 4. Read-back verification by default: after upload the object metadata is re-read (`hcloud OBS stat` / ObsClient.head_object) and its size compared with the local file. 5. Overwrite protection by default: an already-existing target object is refused (exit 1) unless the user explicitly passes `--overwrite`. 6. Explicit error classification: empty domain list is not an error; missing AK/SK, no permission (403), hcloud missing, KooCLI usage errors, bad local output path, and already-existing object are each reported with a dedicated hint. A write-intent guard rejects any mutating CDN operation (create / delete / update / enable / disable / refresh / preheat ...). 7. Triggers include: "CDN 列表导出 OBS", "CDN 域名列表上传 OBS", "查询 CDN 并上传 OBS", "CDN 盘点归档到 OBS", "导出 CDN 加速域名到对象存储", "cdn list export obs", "upload CDN domains to OBS", "archive CDN domains", "华为云 CDN 列表导出". 8. Offline unit tests (mocked hcloud subprocess) cover the CDN query, paging, serialization (json/csv/md), OBS upload, overwrite protection, read-back verification, error classification, SDK fallback, and the write-intent guard." Observed in sandbox: static analysis only — behavior not yet observed.
Is [email protected] safe to install?
KillerSkills analysed it statically (a sandbox run is pending) on 2026-11-05 and scored it 61/100 (Caution). It is not known to be malicious, but it has behaviour or code a security policy should decide on before install. Notable findings: Destructive file system command detected. Summary: static analysis only — behavior not yet observed.
Behavior trace
Queued for honeypot run · static analysis onlyThis version has not been detonated yet. The score above counts behavior as unknown (50/100), so it cannot read Verified until the honeypot run completes and replaces this verdict.
Static findings
What would make this Verified
19 points to 80 · weights: behavior 45%, static 25%, prompt 15%, publisher 15%- Unclaimed publisher≈ +8 on the totalClaim wlc-dev: a verified publisher gets +50 on publisher trust. It is free and usually instant with GitHub sign-in.
- Destructive file system command detected≈ +4 on the totalBuild commands from fixed arguments; do not interpolate untrusted strings into a shell.
- New publisher≈ +3 on the totalTime clears this on its own after 14 and 30 days. Claiming the handle (+50) is the fastest way past it.
- Python subprocess execution detected≈ +2 on the totalBuild commands from fixed arguments, never from interpolated strings; prefer an API client over shelling out.