SECURITY.md

The Land development team and the community of contributors are deeply committedto the security of all software components within the Land Code Editorecosystem. We value the community's efforts in identifying and responsiblydisclosing security vulnerabilities. This document outlines the unified securitypolicy and reporting process forthis specific Element, which is an integralpart of the broader Land project.

Your vigilance and responsible reporting help us maintain a safe and trustworthyenvironment for all users and developers. Please adhere to this policy to ensurethat your findings are addressed effectively and efficiently.

• Proactive Security: We strive to build security into our software from theground up.
• Responsible Disclosure: We encourage private reporting of vulnerabilitiesto prevent premature public exposure that could put users at risk.
• Timely Response: We are committed to acknowledging, investigating, andaddressing reported vulnerabilities in a timely manner.
• Transparency: We aim to be transparent about vulnerabilities once they areresolved, often through security advisories and crediting reporters.
• Collaboration: We believe in working collaboratively with securityresearchers and the community.

This security policy applies to vulnerabilities discovered within:

1. The codebase of this specific Land Element repository. This includes allsource code, build scripts, and configuration files contained herein.
2. Direct dependencies explicitly managed and bundled by this Element.
3. The interaction points and APIs this Element exposes to other LandElements or to the end-user through the Land application.

Vulnerabilities in third-party libraries that are general dependencies (e.g., awidely used open-source library not uniquely modified or configured by thisElement) should ideally be reported to the maintainers of those libraries first.However, if such a vulnerability directly and significantly impacts the securityof this Element or the Land ecosystem through its usage in this Element, pleasereport it to us as well. We will assess how to mitigate it within our project(e.g., by updating the dependency, applying a workaround, or temporarilydisabling affected functionality).

Examples of vulnerabilities relevant to Land Elements might include (but arenot limited to):

• Remote Code Execution (RCE): If an Element allows untrusted input toexecute arbitrary code.
• Privilege Escalation: If an Element allows an unprivileged component orextension to gain higher privileges within the Land application or on theuser's system.
• Information Disclosure: If an Element improperly exposes sensitive userdata, configuration details, or system information.
• Cross-Site Scripting (XSS): Particularly relevant for UI-focused Elements(likeSky orWind's preload environment if it renders HTML content) whereuntrusted data could be injected into web views.
• Denial of Service (DoS): If an Element can be made unresponsive or crashdue to specially crafted input or excessive resource consumption.
• Path Traversal/Arbitrary File Access: For Elements interacting with thefilesystem (likeRiver,Sun, orMountain's FS handlers), ensuring thatpath inputs are properly sanitized.
• Insecure IPC/Communication: For Elements involved in inter-processcommunication (Vine,Track,Echo,Mist), vulnerabilities in theprotocol or handling of messages.
• Sandbox Escapes: For Elements designed to run untrusted code (likeCocoon or a futureGrove), vulnerabilities that allow code to escape itsintended sandbox.
• Authentication/Authorization Flaws: If any Element implements accesscontrol mechanisms, flaws in these systems.
• Data Integrity Issues: If an Element allows unauthorized modification ofcritical data or configuration.

We are committed to providing security updates for the following versions ofthis Land Element:

Please ensure you are testing against and reporting vulnerabilities for asupported version. Reports for unsupported versions might not be prioritized oraddressed. If unsure, please report against theCurrent branch.

IMPORTANT: DO NOT report security vulnerabilities through public GitHubissues, pull requests, or discussion forums for this repository.

Public disclosure of a vulnerability before a fix is available can put the Landecosystem and its users at risk.

To report a security vulnerability, please send a detailed email to ourcentral security address:

➡️Security@Editor.Land ⬅️

Please make sure your email includes:

1. Subject Line: Clearly indicate it's a security vulnerability report and,if known, the affected Element. Example:Security Vulnerability Report: [Element Name] - [Brief Vulnerability Type]
2. Element Name: The specific Land Element repository this vulnerabilitypertains to (e.g., "Wind", "Mountain", "Cocoon").
3. Affected Version(s): The specific version(s) or commit hash(es) of theElement where the vulnerability was identified.
4. Vulnerability Type: A classification of the vulnerability (e.g., RCE,XSS, Path Traversal, Information Disclosure).
5. Detailed Description: A clear, concise, and comprehensive explanation ofthe vulnerability. What is it? How does it work?
6. Steps to Reproduce (Proof of Concept): This is crucial. Providedetailed, step-by-step instructions that allow us to reproduce thevulnerability reliably.
   • Include any necessary setup, configuration, specific inputs, or codesnippets.
   • A minimal, self-contained Proof of Concept (PoC) is highly preferred.
7. Potential Impact: Describe the potential consequences if thisvulnerability is exploited (e.g., "An attacker could read arbitrary files,""This could lead to application crash," "Sensitive user tokens could bestolen").
8. Environment Details (if relevant): Operating System, browser version(for UI elements), specific configurations of Land or the Element.
9. Your Contact Information: Your name/alias and an email address forfollow-up communication. This is essential for us to ask clarifyingquestions.
10. Disclosure Intentions: Please state if you have any intentions ortimelines for public disclosure. We strongly prefer to coordinate disclosureonce a fix is available.
11. Credit/Acknowledgement: Let us know if and how you would like to becredited if the vulnerability is confirmed and fixed.

Providing as much detail as possible will help us investigate and respond morequickly.

Upon receiving your private vulnerability report atSecurity@Editor.Land, we will follow thisprocess:

1. Acknowledgement (within 3 business days): We will send an emailacknowledging receipt of your report.
2. Initial Triage & Validation (within 7-10 business days ofacknowledgement):
   • Our security team and relevant Element maintainers will review your reportto understand and attempt to reproduce the vulnerability.
   • We will make an initial assessment of the vulnerability's validity andpotential severity.
   • We may contact you for additional information or clarification during thisphase.
3. In-Depth Investigation & Remediation Planning:
   • If the vulnerability is confirmed, we will conduct a more thoroughinvestigation to understand its full scope and impact.
   • We will prioritize the vulnerability based on its severity and beginplanning and developing a fix. The timeline for a fix can varysignificantly based on complexity.
4. Communication & Updates: We will strive to keep you informed of ourprogress, especially regarding significant milestones like confirmation, fixdevelopment, and planned release of the fix.
5. Fix Development & Testing: A patch will be developed, reviewed, andtested.
6. Coordinated Disclosure: Once a fix is ready and deployed (e.g., mergedtoCurrent or included in an upcoming release), we will coordinate withyou on the public disclosure of the vulnerability.
   • This may involve a GitHub Security Advisory, release notes, andappropriate credit to you as the reporter (if desired).
   • We generally request a period of 90 days for remediation before publicdisclosure, but this can be negotiated based on the circumstances.

We will treat your report and all communications as confidential. We will notshare information about the vulnerability with third parties without yourpermission, except as necessary to investigate and remediate the issue (e.g.,with core maintainers of an affected upstream dependency).

• Denial of Service (DoS) on Public Infrastructure: Please do not performDoS testing against any public Land project infrastructure (e.g., websites,build servers).
• Social Engineering: Reports of successful social engineering (e.g.,phishing of project members) are out of scope for this code vulnerabilitypolicy.
• Missing Security Best Practices (without exploitable impact): For example,missing HTTP security headers on a non-sensitive static documentation site,unless you can demonstrate a direct exploitable vulnerability. Such issues arebetter raised as regular GitHub issues for improvement.
• Reports from Automated Scanners: While scanner results can be helpfulstarting points, please manually validate findings and provide a proof ofconcept demonstrating actual exploitability. Generic scanner output withoutcontext is unlikely to be acted upon as a priority security issue.
• Self-XSS: Cross-Site Scripting vulnerabilities that require the victim topaste code into their own browser console or modify their own client-sideenvironment are generally not considered high-impact unless a plausible attackvector is demonstrated.
• Issues requiring physical access to an unlocked device.

When in doubt, please err on the side of reporting toSecurity@Editor.Land.

For any questions regarding this security policy or the vulnerability reportingprocess for any Land Ecosystem Element, please contact us atSecurity@Editor.Land.

Thank you for your commitment to helping us make the Land Code Editor ecosystemmore secure for everyone.

There aren’t any published security advisories