diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
new file mode 100644
index 000000000..959e47065
--- /dev/null
+++ b/CODE_OF_CONDUCT.md
@@ -0,0 +1,101 @@
+
+
+# Code of Conduct
+
+This is a Code of Conduct for the Ghaf community.
+
+
+
+
+
+- [Code of Conduct](#code-of-conduct)
+ - [Our Pledge](#our-pledge)
+ - [Our Standards](#our-standards)
+ - [Enforcement Responsibilities](#enforcement-responsibilities)
+ - [Scope](#scope)
+ - [Enforcement](#enforcement)
+ - [Enforcement Guidelines](#enforcement-guidelines)
+ - [Attribution](#attribution)
+
+
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
+
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our community include:
+
+* demonstrating empathy and kindness toward other people;
+* being respectful of differing opinions, viewpoints, and experiences;
+* giving and gracefully accepting constructive feedback;
+* accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience;
+* focusing on what is best not just for us as individuals, but for the overall community.
+
+Examples of unacceptable behavior include:
+
+* the use of sexualized language or imagery, and sexual attention or advances of any kind;
+* trolling, insulting or derogatory comments, and personal or political attacks;
+* public or private harassment;
+* publishing others’ private information, such as a physical or email address, without their explicit permission;
+* other conduct which could reasonably be considered inappropriate in a professional setting.
+
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned with this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
+
+
+## Scope
+
+This Code of Conduct applies within all community spaces and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
+
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at GhafCodeofConduct@ssrc.tii.ae. All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the reporter of any incident.
+
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
+
+1. **Correction**
+
+ *Community Impact*: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
+
+ *Consequence*: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
+
+2. **Warning**
+
+ *Community Impact*: A violation through a single incident or series of actions.
+
+ *Consequence*: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
+
+3. **Temporary Ban**
+
+ *Community Impact*: A serious violation of community standards, including sustained inappropriate behavior.
+
+ *Consequence*: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
+
+4. **Permanent Ban**
+
+ *Community Impact*: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
+
+ *Consequence*: A permanent ban from any sort of public interaction within the community.
+
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant, version 2.1](https://www.contributor-covenant.org/).
diff --git a/README.md b/README.md
index e296debc0..4d90fe46b 100644
--- a/README.md
+++ b/README.md
@@ -11,7 +11,7 @@
-[](./LICENSES/LICENSE.Apache-2.0) [](./LICENSES/LICENSE.CC-BY-SA-4.0) [](https://github.com/tiiuae/ghaf/blob/main/docs/style_guide.md) [](https://securityscorecards.dev/viewer/?uri=github.com/tiiuae/ghaf) [](https://www.bestpractices.dev/projects/8290)
+[](./LICENSES/LICENSE.Apache-2.0) [](./LICENSES/LICENSE.CC-BY-SA-4.0) [](https://github.com/tiiuae/ghaf/blob/main/docs/style_guide.md) [](https://securityscorecards.dev/viewer/?uri=github.com/tiiuae/ghaf) [](https://www.bestpractices.dev/projects/8290) [](./CODE_OF_CONDUCT.md)
@@ -35,8 +35,8 @@ See the documentation overview under [README-docs.md](./docs/README-docs.md).
Other repositories that are a part of the Ghaf project:
-* [sbomnix](https://github.com/tiiuae/sbomnix): a utility that generates SBOMs given Nix derivations or out paths
-* [ghaf-infra](https://github.com/tiiuae/ghaf-infra), [ci-public](https://github.com/tiiuae/ci-public), [ci-test-automation](https://github.com/tiiuae/ci-test-automation): CI/CD related files
+* [sbomnix](https://github.com/tiiuae/sbomnix): a utility that generates SBOM given Nix derivations or out paths
+* [ghaf-infra](https://github.com/tiiuae/ghaf-infra), [ci-public](https://github.com/tiiuae/ci-public), [ci-test-automation](https://github.com/tiiuae/ci-test-automation), [ghafscan](https://github.com/tiiuae/ghafscan): CI/CD related files
## Build System
@@ -67,4 +67,4 @@ The Ghaf team uses several licenses to distribute software and documentation:
| Apache License 2.0 | [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) | Ghaf source code. |
| Creative Commons Attribution Share Alike 4.0 International | [CC-BY-SA-4.0](https://spdx.org/licenses/CC-BY-SA-4.0.html) | Ghaf documentation. |
-See [LICENSE.Apache-2.0](./LICENSES/LICENSE.Apache-2.0) and [LICENSE.CC-BY-SA-4.0](./LICENSES/LICENSE.CC-BY-SA-4.0) for the full license text.
+See [LICENSE.Apache-2.0](./LICENSES/Apache-2.0.txt) and [LICENSE.CC-BY-SA-4.0](./LICENSES/CC-BY-SA-4.0.txt) for the full license text.
diff --git a/SECURITY.md b/SECURITY.md
index e41f897c7..246ec807f 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -6,24 +6,25 @@
# Security Policy
This document includes information about the vulnerability reporting, patch,
-release, and disclosure processes, as well as general security posture.
+release, disclosure processes, and the general security posture.
-- [Supported Versions](#supported-versions)
-- [Reporting a Vulnerability](#reporting-a-vulnerability)
- - [When Should I Report a Vulnerability?](#when-should-i-report-a-vulnerability)
- - [When Should I NOT Report a Vulnerability?](#when-should-i-not-report-a-vulnerability)
- - [Vulnerability Response](#vulnerability-response)
-- [Security Release & Disclosure Process](#security-release--disclosure-process)
- - [Private Disclosure](#private-disclosure)
- - [Public Disclosure](#public-disclosure)
- - [Security Releases](#security-releases)
- - [Severity](#severity)
-- [Security Team](#security-team)
-- [Security Policy Updates](#security-policy-updates)
+- [Security Policy](#security-policy)
+ - [Supported Versions](#supported-versions)
+ - [Security Team](#security-team)
+ - [Reporting Vulnerability](#reporting-vulnerability)
+ - [When Should I Report Vulnerability?](#when-should-i-report-vulnerability)
+ - [When Should I NOT Report Vulnerability?](#when-should-i-not-report-vulnerability)
+ - [Vulnerability Response](#vulnerability-response)
+ - [Security Release \& Disclosure Process](#security-release--disclosure-process)
+ - [Private Disclosure](#private-disclosure)
+ - [Public Disclosure](#public-disclosure)
+ - [Security Releases](#security-releases)
+ - [Severity](#severity)
+ - [Security Policy Updates](#security-policy-updates)
@@ -35,126 +36,89 @@ Release candidates will not receive security updates.
| Version | Supported |
| -------- | ------------------ |
| >= 23.12 | :white_check_mark: |
-| <=23.09 | :x: |
+| <= 23.09 | :x: |
-## Reporting a Vulnerability
-We're extremely grateful for security researchers and users that report
-vulnerabilities to us. All reports are thoroughly investigated by the project
-[security team](#security-team).
+## Security Team
+
+The Security Team is responsible for the overall security of the project and for reviewing reported vulnerabilities. Each member is familiar with designing secure software, security issues related to CI/CD, GitHub Actions, and build provenance.
+
+Security Team:
+
+* Brian McGillion (@brianmcgillion)
+* Manuel Bluhm (@mbssrc)
+* Henri Rosten (@henrirosten)
+* Mika Tammi (@mikatammi)
+
+Security Team membership is currently considered on a case-by-case basis.
+
+
+## Reporting Vulnerability
+
+We are grateful to security researchers and users who report vulnerabilities. The project [Security Team](#security-team) thoroughly investigates all reports.
+
+You can report security vulnerabilities directly (privately or publicly) to the security team by using the [Report a vulnerability](https://github.com/tiiuae/ghaf/security/advisories/new) form, as the ghaf repository is configured with the GitHub's [Security Advisories](https://docs.github.com/en/code-security/security-advisories) feature. For information on how to submit a vulnerability using GitHub's interface, see [Privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability#privately-reporting-a-security-vulnerability).
+
-Vulnerabilities are reported privately via GitHub's
-[Security Advisories](https://docs.github.com/en/code-security/security-advisories)
-feature. Please use the following link to submit your vulnerability:
-[Report a vulnerability](https://github.com/tiiuae/ghaf/security/advisories/new)
+### When Should I Report Vulnerability?
-Please see
-[Privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability#privately-reporting-a-security-vulnerability)
-for more information on how to submit a vulnerability using GitHub's interface.
+* You think you discovered a potential security vulnerability in Ghaf.
+* You are unsure how a vulnerability affects Ghaf.
+* You think you discovered a vulnerability in another project that Ghaf depends on.
-### When Should I Report a Vulnerability?
+> For projects with their own vulnerability reporting and disclosure process, report it directly there.
-- You think you discovered a potential security vulnerability in Ghaf
-- You are unsure how a vulnerability affects Ghaf
-- You think you discovered a vulnerability in another project that Ghaf depends on
- - For projects with their own vulnerability reporting and disclosure process, please report it directly there
-### When Should I NOT Report a Vulnerability?
+### When Should I NOT Report Vulnerability?
+
+* You need help tuning GitHub Actions for security.
+* You need help applying security-related updates.
+* When the issue is currently acknowledged in [Ghaf Vulnerability Reports](https://github.com/tiiuae/ghafscan/blob/main/reports/main/README.md).
+* Your issue is not security-related.
-- You need help tuning GitHub Actions for security
-- You need help applying security related updates
-- When the issue is currently acknowledged in [Security Advisory](https://github.com/tiiuae/ghafscan/blob/main/reports/main/README.md)
-- Your issue is not security related
### Vulnerability Response
-Each report is acknowledged and analyzed by the [Security Team](#security-team)
-within 14 days. This will set off the
-[Security Release Process](#security-release--disclosure-process).
+Each report is acknowledged and analyzed by the [Security Team](#security-team) within 14 days. This sets off the [Security Release & Disclosure Process](#security-release--disclosure-process).
+
+Any vulnerability information shared with the Security Team stays within the Ghaf project and will not be disseminated to other projects unless it is necessary to get the issue fixed.
-Any vulnerability information shared with the Security Team stays within
-Ghaf project and will not be disseminated to other projects
-unless it is necessary to get the issue fixed.
+We keep a reporter updated as the security issue moves from triage to identified fix, and then to release planning.
-As the security issue moves from triage, to identified fix, to release planning
-we will keep the reporter updated.
## Security Release & Disclosure Process
-Security vulnerabilities should be handled quickly and sometimes privately. The
-primary goal of this process is to reduce the total time users are vulnerable
-to publicly known exploits.
+Security vulnerabilities are handled quickly and sometimes privately. The primary goal of this process is to reduce the total time users are vulnerable to publicly known exploits.
+
### Private Disclosure
-We ask that all suspected vulnerabilities be privately and responsibly
-disclosed via the [private disclosure process](#reporting-a-vulnerability)
-outlined above.
+We ask that all suspected vulnerabilities be privately and responsibly disclosed through the [private disclosure process](#reporting-a-vulnerability) outlined above. Fixes may be developed and tested by the [Security Team](#security-team) in a [temporary private fork](https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability) that is private from the general public if deemed necessary.
-Fixes may be developed and tested by the [Security Team](#security-team) in a
-[temporary private fork](https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability)
-that are private from the general public if deemed necessary.
### Public Disclosure
-Vulnerabilities are disclosed publicly as [Security
-Advisories](https://github.com/tiiuae/ghafscan/blob/main/reports/main/README.md).
-
-A public disclosure date is negotiated by the [Security Team](#security-team)
-and the bug submitter. We prefer to fully disclose the bug as soon as possible
-once a user mitigation is available. It is reasonable to delay disclosure when
-the bug or the fix is not yet fully understood, the solution is not
-well-tested, or for vendor coordination. The timeframe for disclosure is from
-immediate (especially if it's already publicly known) to several weeks. For a
-vulnerability with a straightforward mitigation, we expect report date to
-disclosure date to be on the order of 14 days.
-
-If you know of a publicly disclosed security vulnerability please IMMEDIATELY
-[report the vulnerability](#reporting-a-vulnerability) to inform the
-[Security Team](#security-team) about the vulnerability so they may start the
-patch, release, and communication process.
-
-If possible the Security Team will ask the person making the public report if
-the issue can be handled via a private disclosure process. If the reporter
-denies the request, the Security Team will move swiftly with the fix and
-release process. In extreme cases you can ask GitHub to delete the issue but
-this generally isn't necessary and is unlikely to make a public disclosure less
-damaging.
+Vulnerabilities are disclosed publicly as [Security Advisories](https://github.com/tiiuae/ghafscan/blob/main/reports/main/README.md).
-### Security Releases
+A public disclosure date is negotiated by the [Security Team](#security-team) and a vulnerability reporter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when a bug or fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The time frame for disclosure is from immediate (especially if it is already publicly known) to several weeks. For a vulnerability with straightforward mitigation, we expect a report date to disclosure date to be on the order of 14 days.
-Once a fix is available it will be released and announced via the project on
-GitHub, releases will announced and clearly marked as a security release and
-include information on which vulnerabilities were fixed. As much as possible
-this announcement should be actionable, and include any mitigating steps users
-can take prior to upgrading to a fixed version.
+If you know of a publicly disclosed security vulnerability, please *IMMEDIATELY* [report the vulnerability](#reporting-a-vulnerability) to inform the [Security Team](#security-team), so they may start the patch, release, and communication process.
-Fixes will be applied in patch releases to all [supported
-versions](#supported-versions) and all fixed vulnerabilities will be noted in
-the [Release Notes](https://tiiuae.github.io/ghaf/release_notes/release_notes.html).
+If possible the Security Team will ask the person making the public report if the issue can be handled via a private disclosure process. If the reporter denies the request, the Security Team will move swiftly with the fix and release process. In extreme cases, you can use GitHub to delete the issue but this generally isn not necessary and is unlikely to make a public disclosure less damaging.
-### Severity
-The [Security Team](#security-team) evaluates vulnerability severity on a
-case-by-case basis, guided by [CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document).
+### Security Releases
-## Security Team
+Once a fix is available, it will be released and announced in the project on GitHub, releases will announced and marked as a security release and include information on which vulnerabilities were fixed. As much as possible this announcement should be actionable and include any mitigating steps users can take before upgrading to a fixed version.
-The Security Team is responsible for the overall security of the
-project and for reviewing reported vulnerabilities. Each member is familiar
-with designing secure software, security issues related to CI/CD, GitHub
-Actions and build provenance.
+Fixes will be applied in patch releases to all [supported versions](#supported-versions) and all fixed vulnerabilities will be noted in the [Release Notes](https://tiiuae.github.io/ghaf/release_notes/release_notes.html).
-Security Team:
-- Brian McGillion (@brianmcgillion)
-- Manuel Bluhm (@mbssrc)
-- Henri Rosten (@henrirosten)
-- Mika Tammi (@mikatammi)
+### Severity
+
+The [Security Team](#security-team) evaluates vulnerability severity on a case-by-case basis, guided by the [CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document) specification document.
-Security Team membership is currently considered on a case-by-case basis.
## Security Policy Updates
-Changes to this Security Policy are reviewed and approved by the
-[Security Team](#security-team).
+Changes to this Security Policy are reviewed and approved by the [Security Team](#security-team).
diff --git a/docs/src/appendices/glossary.md b/docs/src/appendices/glossary.md
index dc8679d53..bcae30f13 100644
--- a/docs/src/appendices/glossary.md
+++ b/docs/src/appendices/glossary.md
@@ -142,6 +142,11 @@ _Kernel-based Virtual Machine, an open-source virtualization technology built in
_Kernel-based Virtual Machine Secured, an open-source project._
Source:
+### labws, LabWS
+
+_Lab Wayland Compositor, a window-stacking compositor for Wayland, an open-source project._
+Source:
+
### MMU
_memory management unit_
diff --git a/docs/src/ref_impl/creating_appvm.md b/docs/src/ref_impl/creating_appvm.md
index 5ba9f42c3..e394a7fea 100644
--- a/docs/src/ref_impl/creating_appvm.md
+++ b/docs/src/ref_impl/creating_appvm.md
@@ -18,7 +18,7 @@ To create an AppVM:
Add the VM description in the target configuration.
-[lenovo-x1.nix](../../../targets/lenovo-x1.nix) already has AppVMs inside for Chromium, Gala, and Zathura applications.
+[lenovo-x1-carbon.nix](https://github.com/tiiuae/ghaf/blob/main/targets/lenovo-x1-carbon.nix) already has AppVMs inside for Chromium, Gala, and Zathura applications.
#### AppVMs Example
@@ -63,11 +63,11 @@ Each VM has the following properties:
## Adding Application Launcher in GUI VM
-To add an app launcher, add an element in the [guivm.nix](../../../modules/virtualization/microvm/guivm.nix) file to the **graphics.launchers** list.
+To add an application launcher, add an element in the [guivm.nix](https://github.com/tiiuae/ghaf/blob/main/modules/virtualization/microvm/guivm.nix) file to the **graphics.weston.launchers** list.
-A launcher element has 2 properties:
+A launcher element has two properties:
-1. **path** – path to the executable you want to run, like a graphical application.
-2. **icon** – path to an icon to show.
+* **path**–path to the executable you want to run, like a graphical application;
+* **icon**–path to an icon to show.
-Check the example launchers at [guivm.nix](../../../modules/virtualization/microvm/guivm.nix).
+Check the example launchers at [guivm.nix](https://github.com/tiiuae/ghaf/blob/main/modules/virtualization/microvm/guivm.nix).
diff --git a/docs/src/ref_impl/development.md b/docs/src/ref_impl/development.md
index 6c7c95e8d..88845c3c7 100644
--- a/docs/src/ref_impl/development.md
+++ b/docs/src/ref_impl/development.md
@@ -5,23 +5,26 @@
# Development
-Ghaf Framework is free software, currently under active development. The scope of target support is updated with development progress:
+Ghaf Framework is free software, currently under active development.
-- [Build and Run](./build_and_run.md)
-- [Running Remote Build on NixOS](./remote_build_setup.md)
-- [Installer](./installer.md)
-- [Cross-Compilation](./cross_compilation.md)
-- [Creating Application VM](./creating_appvm.md)
+The scope of target support is updated with development progress:
+
+* [Build and Run](./build_and_run.md)
+* [Running Remote Build on NixOS](./remote_build_setup.md)
+* [Installer](./installer.md)
+* [Cross-Compilation](./cross_compilation.md)
+* [Creating Application VM](./creating_appvm.md)
+* [labwc Desktop Environment](./labwc.md)
Once you are up and running, you can participate in the collaborative development process by building a development build with additional options. For example, with the development username and password that are defined in [accounts.nix](https://github.com/tiiuae/ghaf/blob/main/modules/users/accounts.nix).
-If you authorize your development SSH keys in the [ssh.nix](https://github.com/tiiuae/ghaf/blob/main/modules/development/ssh.nix#L10-L23) module and rebuild ghaf for your target device, you can use `nixos-rebuild switch` to quickly deploy your configuration changes to the target device over the network using SSH. For example:
+If you authorize your development SSH keys in the [ssh.nix](https://github.com/tiiuae/ghaf/blob/main/modules/development/ssh.nix#L10-L23) module and rebuild Ghaf for your target device, you can use `nixos-rebuild switch` to quickly deploy your configuration changes to the target device over the network using SSH. For example:
nixos-rebuild --flake .#nvidia-jetson-orin-agx-debug --target-host root@ --fast switch
...
nixos-rebuild --flake .#lenovo-x1-carbon-gen11-debug --target-host root@ --fast switch
...
-Please note that with the `-debug` targets, the debug ethernet is enabled on host. With Lenovo X1 Carbon, you can connect USB-Ethernet adapter for the debug and development access.
+> With the `-debug` targets, the debug ethernet is enabled on host. With Lenovo X1 Carbon, you can connect USB-Ethernet adapter for the debug and development access.
Pull requests are the way for contributors to submit code to the Ghaf project. For more information, see [Contribution Guidelines](../appendices/contributing_general.md).
diff --git a/docs/src/ref_impl/labwc.md b/docs/src/ref_impl/labwc.md
index 9c83201f8..117c0001c 100644
--- a/docs/src/ref_impl/labwc.md
+++ b/docs/src/ref_impl/labwc.md
@@ -3,28 +3,30 @@
SPDX-License-Identifier: CC-BY-SA-4.0
-->
-# Labwc Desktop Environment
+# labwc Desktop Environment
-[Labwc](https://labwc.github.io/) is a configurable and lightweight wlroots-based Wayland-compatible desktop environment.
-To use Labwc as your default desktop environment, add it as a module to Ghaf:
+[labwc](https://labwc.github.io/) is a configurable and lightweight wlroots-based Wayland-compatible desktop environment.
+
+
+To use labwc as your default desktop environment, add it as a module to Ghaf:
* change the configuration option `profiles.graphics.compositor = "labwc"`
or
-* uncomment the corresponding line in [guivm.nix](../modules/virtualization/microvm/guivm.nix) file.
+* uncomment the corresponding line in the [guivm.nix](https://github.com/tiiuae/ghaf/blob/main/modules/virtualization/microvm/guivm.nix) file.
-The basis of the labwc configuration is the set of following files: `rc.xml`, `menu.xml`, `autostart`, and `environment`. These files can be edited by substituting in the Labwc overlay `overlays/custom-packages/labwc/default.nix`.
+The basis of the labwc configuration is the set of following files: `rc.xml`, `menu.xml`, `autostart`, and `environment`. These files can be edited by substituting in the labwc overlay `overlays/custom-packages/labwc/default.nix`.
## Window Border Coloring
The border color concept illustrates the application trustworthiness in a user-friendly manner. The color shows the application's security level and allows avoiding user's mistakes. The same approach can be found in other projects, for example, [QubeOS](https://www.qubes-os.org/doc/getting-started/#color--security).
-Ghaf uses patched Labwc which makes it possible to change the border color for the chosen application. The implementation is based on window rules by substituting the server decoration colors (`serverDecoration` = `yes`). The `borderColor` property is responsible for the frame color.
+Ghaf uses patched labwc which makes it possible to change the border color for the chosen application. The implementation is based on window rules by substituting the server decoration colors (`serverDecoration` = `yes`). The `borderColor` property is responsible for the frame color.
> **TIP:** According to the labwc specification, the **identifier** parameter is case-sensitive and relates to app_id for native Wayland windows and WM_CLASS for XWayland clients.
-For example:
+For example, the foot terminal with Aqua colored frame:
```