The Cardano lsm-tree project is committed to ensuring the security of its software and the privacy of its users. We value the contributions of the security community in helping us identify and address vulnerabilities in our code. This Security Vulnerability Disclosure Policy outlines how security vulnerabilities should be reported and how we will respond to and remediate such reports.

If you discover a security vulnerability in lsm-tree, we encourage you to responsibly disclose it to us. To report a vulnerability, please use the security advisory form on GitHub to draft a new Security advisory.

Please include as many details as needed to clearly qualify the issue:

• A description of the vulnerability and its potential impact.
• Steps to reproduce the vulnerability.
• The version of lsm-tree where the vulnerability exists.
• Any relevant proof-of-concept or exploit code (if applicable).

1. Acknowledgment: The team acknowledges the receipt of your report within 3 business days by commenting on the issue reporting it or replying to email.

2. Validation: The team investigates the issue and either reject or validate the reported vulnerability.

   a. Rejection: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as Won't fix.

   b. Acceptance: If the team accepts the report, a CVE identifier will be requested through GitHub and a private fork opened to work on a fix to the issue

3. Resolution: The team works to resolve the vulnerability in a timely manner. The timeline for resolution will depend on the complexity and severity of the vulnerability, but we will strive to address critical vulnerabilities as quickly as possible.

4. Collaboration: While working on a fix, the team maintains open and transparent communication with the reporter throughout the process, providing updates on the status of the vulnerability and any steps taken to remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.

5. Fixing Issue: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.

   a. Mitigation: Depending on the severity and criticality of the issue, the team can decide to disclose the issue publicly in the absence of a fix if and only if a clear, simple, and effective mitigation plan is defined. This must include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).

   b. Fix: When a fix is available and approved, it should be merged and made available as quickly as possible:

   • All commits to the private repository are squashed into a single commit whose description should not make any reference that it relates to a security vulnerability
   • A new Pull Request is created with this single commit
   • This PR's review and merging is expedited as all the work as already been done

6. Release: The team creates and publish a release that includes the fix

7. Announcement: Concomitant to the release announcement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.

   a. Credit: The team publicly acknowledges the contributions of the reporter once the vulnerability is resolved, subject to the reporter's preferences for attribution.

8. Disagreements: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.

We kindly request that reporters adhere to responsible disclosure practices, which include:

• Do not disclose the vulnerability publicly: Please refrain from posting details of the vulnerability on public forums or social media until it has been resolved.
• Do not exploit the vulnerability: Do not attempt to exploit the vulnerability to cause harm or gain unauthorized access to systems.
• Work with us: Allow us a reasonable amount of time to investigate and address the vulnerability before publicly disclosing any details.

We will not pursue legal action against individuals who report security vulnerabilities to us.

To report a security vulnerability, please use the security advisory form on GitHub. Should you experience any issues reporting via GitHub or have other questions, please contact security@intersectmbo.org.

This Security Vulnerability Disclosure Policy may be updated or revised as necessary. Please check the latest version of this policy on the Open-Source-Office repository.

The lsm-tree project greatly appreciates the assistance of the security community in helping us maintain the security of our software while upholding the highest standards of privacy. Together, we can work to identify and address vulnerabilities, ensuring a safer and more secure experience for all users.

The lsm-tree library (and its child library blockio) are not designed for or expected to be used at a security boundary. Legitimate security vulnerability concerns would involve leveraging exploits through the public API of the library. Corrupting process memory or local disk files without going through the public API is not considered a security vulnerability. In particular, directly modifying the local on-disk data structures as a preparatory step within a vulnerability report is invalid, because it involves the attacker already being within the same security compartment as the software being attacked.

• The local data files are to be considered to be within the lsm-tree security compartment (i.e. protected by OS security and file system and user permissions). Thus deliberate corruption of the local on-disk data files are not a security vulnerability (any more than deliberate corruption of the process memory would be). Moreover, sessions (i.e., databases), snapshots, or any part thereof should not be copied across from untrusted sources to be used as local on-disk data. It should be assumed that such copies can be deliberately tampered with. This is also not a security vulnerability because it crosses a security boundary.

• The snapshot export/import feature is not currently intended to be used across a security boundary to import untrusted snapshots. It is only intended to allow archiving snapshots outside of the current session, for example on different file system volumes, but still within the same security compartment. The snapshot format is also not intended as an external interchange format. Use cases that require importing whole tables should do so via the other APIs: make an empty table and add elements in batches. Alternatively, a new import/export feature could be implemented that is intended to be used to import untrusted snapshots. This would involve code changes and would be less efficient since it would need to re-construct the table from scratch (validating the internal format is a fools errand).