Please report suspected, undisclosed vulnerabilities privately to the Apache Software Foundation Security Team at security@apache.org. The Security Team will triage the report and coordinate with the Apache TsFile PMC.

Do not open a public GitHub issue, discussion, or pull request for a suspected vulnerability. Public disclosure before a fix is available may put users at risk. Please follow the ASF vulnerability handling process and coordinate disclosure with the Security Team until a fix and advisory have been published.

Send one plain-text, unencrypted email for each vulnerability. Include as much of the following as possible:

• the affected TsFile release(s), commit, component, and language implementation;
• a description of the vulnerability, its impact, and the required attack conditions;
• the relevant configuration, operating system, architecture, and runtime versions;
• steps to reproduce the issue and a minimal proof of concept or sample file, if available; and
• relevant logs, stack traces, crash dumps, or sanitizer output.

The security address is only for undisclosed vulnerabilities. Use the public Apache TsFile issue tracker for ordinary bugs, build problems, feature requests, and questions about already published vulnerabilities.

Apache TsFile is a file format and a set of in-process libraries and command-line tools. It is not a network service or a security boundary. TsFile does not provide authentication, authorization, tenant isolation, or sandboxing. An application embedding TsFile is responsible for those controls and for restricting the library's filesystem and network access.

This model applies to the TsFile format readers and writers, the Java and C++ implementations, the C API, the Python and Go bindings, and command-line tools distributed by this repository.

TsFile data and metadata may come from untrusted sources. Readers must treat serialized lengths, offsets, counts, schemas, statistics, encoding and compression identifiers, and compressed payloads as attacker-controlled. The same principle applies to other serialized input accepted by a TsFile tool, such as CSV or TSV data imported by a command-line tool.

In contrast, callers are responsible for satisfying documented API preconditions. In-memory objects, pointers, buffer sizes, callbacks, runtime configuration, the process class path or dynamic library search path, and explicitly installed extensions are trusted inputs. Passing invalid native pointers or violating an API's ownership and lifetime requirements is outside this security model.

Processing an attacker-controlled file is security-relevant when it results in arbitrary code execution, exploitable memory corruption, disclosure of unrelated process data, or access outside resources selected by the caller. A malformed or unsupported file may otherwise be rejected at any point.

TsFile is optimized for large time-series datasets and supports compression. A valid or maliciously crafted file may require substantial CPU time, memory, or output space. Applications that accept files from untrusted sources should impose limits appropriate to their environment, including input size, decompressed size, memory, processing time, concurrency, and result size. Applications with a strong isolation requirement should parse untrusted files in a suitably restricted process.

A clean error while parsing malformed input, or a crash, assertion failure, out-of-memory condition, or sanitizer finding without a demonstrated security-boundary impact, is normally a robustness issue rather than a vulnerability. The same applies to resource consumption proportional to the input or its declared decompressed size. Reports that demonstrate disproportionate resource amplification or a meaningful availability impact across an actual untrusted boundary may be security issues and will be evaluated case by case.

Some TsFile implementations can use configurable filesystem, compression, or encryption code from the application's runtime environment. Applications must secure their software supply chain, configuration, class path, and dynamic library search path. Installing or selecting such code grants it the privileges of the TsFile process; these extension mechanisms are not sandboxes.

Do not assume that a TsFile is confidential or authentic merely because it can be read successfully. Unless a supported protection mechanism is explicitly and correctly configured, files should be treated as plaintext and unauthenticated. Checksums used to detect accidental corruption are not a substitute for cryptographic authenticity.

Storage permissions, key management, transport security, provenance checks, and access control are the responsibility of the embedding application and its deployment environment.

Examples of findings that should be reported privately include:

• arbitrary code execution while processing attacker-controlled input;
• exploitable memory corruption or out-of-bounds access that exposes unrelated process data;
• reads or writes outside caller-designated resources caused by serialized file contents;
• bypass of a documented security guarantee; and
• remotely triggerable denial of service with significant, disproportionate impact.

Issues that require control of the host, process, trusted runtime configuration, class path, dynamic library search path, or valid native pointers generally do not cross a boundary provided by TsFile.