Section 13 ‐ Code Maintenance & Security - ApertureViewer/Aperture-Opertations-Manual GitHub Wiki

13.1 Policy on Contributing Code to Upstream Projects

Aperture Viewer's policy on contributing code, including fixes and enhancements, back to upstream projects is as follows:

• Contributions to Linden Lab (Official Second Life Viewer):
  • Consideration may be given to preparing a clean Pull Request (PR) for submission directly to Linden Lab for generally applicable bug fixes or enhancements developed within Aperture.
  • Strict Criteria for Submission: Such contributions are made selectively by the Project Lead only if the code:
    • Is mature, thoroughly tested, and "code ready."
    • Provides clear and broad benefit to all Second Life users, not just a niche group.
    • Addresses an issue or provides an enhancement to the core Linden Lab codebase.
    • Aligns with Linden Lab's technical direction and priorities.
    • Can be integrated by Linden Lab without imposing Aperture-specific architectural dependencies not desired by LL.
  • Process: Any such submission would follow Linden Lab's specific contribution guidelines and be pursued through direct communication channels as guided by them. This includes significant visual system enhancements where collaboration opportunities align with Linden Lab's roadmap.

(For full details, refer to AOM Section 10.1).

13.2 Handling Security Vulnerabilities

Security is taken seriously. The following process applies to the handling of potential security vulnerabilities:

• Reporting:
  • Security vulnerabilities should be reported privately and directly to the Project Lead (William Weaver) via the official project email: [email protected].
  • Do NOT report security vulnerabilities via public GitHub Issues, Discord, or other public forums.
  • Reports should include detailed information about the vulnerability, steps to reproduce it, and potential impact, if known.
• Verification & Assessment:
  • The Project Lead will promptly investigate and verify any reported security vulnerability.
  • The severity and potential impact will be assessed.
• Coordination (If Upstream):
  • If the vulnerability originates in or affects the upstream Firestorm or Linden Lab codebase, the Project Lead will coordinate privately with the respective security teams of those projects before any public disclosure related to Aperture Viewer, following responsible disclosure practices.
• Patch Development:
  • A patch for the vulnerability will be developed by the Project Lead as a high priority.
• Release of Patch:
  • The patch will typically be released as part of an urgent hotfix (patch version) release for Aperture Viewer.
  • If coordinated with upstream projects, the Aperture release may coincide with or follow their own patch releases.
• Disclosure:
  • Once a patch is released and available to users, information about the vulnerability (sufficient for users to understand the risk and the importance of updating, but without exposing unnecessary technical details that could aid exploitation before widespread patching) may be disclosed in release notes or a security advisory, if deemed appropriate and after coordination with any affected upstream projects.

13.3 Code Signing Procedures and User Security

Ensuring the integrity and authenticity of official Aperture Viewer releases is important for user security.

• SHA-256 Checksums:
  • For every official release, SHA-256 checksums for all distributed installer files are generated and published alongside the release notes on GitHub.
  • Users are strongly encouraged to verify the checksum of their downloaded installer against the official published checksum before running the installer to ensure the file has not been corrupted or tampered with. (Instructions for verification are provided on the "Download & Installation" Wiki page).
• Code Signing (Future Goal):
  • Current Status: As of AOM v1.0.0, official Aperture Viewer executables and installers are not currently digitally signed with a commercial code signing certificate. This is primarily due to the associated costs and administrative overhead for a non-commercial, volunteer project.
  • Future Consideration: The project recognizes the significant security benefits of code signing (e.g., verifying publisher authenticity, ensuring file integrity, reducing warnings from operating systems/antivirus software). Obtaining and implementing code signing for future releases is a desired future goal, contingent upon resolving logistical challenges (such as integration with automated build systems like Azure, if used) and addressing potential costs.
  • Interim Measures: Until formal code signing is implemented, users must rely on downloading only from the official ApertureViewer GitHub Releases page and diligently verifying SHA-256 checksums.
• Secure Distribution: Official releases of Aperture Viewer will only be distributed via the Releases section of the official ApertureViewer/Aperture-Viewer GitHub repository. Users should not download Aperture Viewer from any other unofficial sources.

13.4 Dependency Management

Aperture Viewer inherits a large number of third-party libraries from its upstream codebase.

• Autobuild: The project utilizes the autobuild system (developed by Linden Lab) for managing and building many of these third-party dependencies.
• Updates: Updates to third-party libraries are typically inherited through merges from upstream (Firestorm/Linden Lab).
• Security of Dependencies: The Aperture Viewer project relies on the diligence of upstream projects (Linden Lab and Firestorm) to vet and update dependencies for security vulnerabilities. If Aperture Viewer becomes aware of a critical vulnerability in a dependency that is not being addressed upstream in a timely manner, the Project Lead may investigate options for patching or mitigating it directly within Aperture, if feasible.