ci: Apply prettier lint suggestions
This is blocking [new proposals][1] from passing CI.
[1]: https://gerrit.openbmc.org/c/openbmc/docs/+/76147
Change-Id: I3df57bd4e1abec93cb1775aa291295de9fa083f2
Signed-off-by: Peter Delevoryas <peter@pjd.dev>
diff --git a/SECURITY.md b/SECURITY.md
index b841241..fc658ff 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -29,15 +29,16 @@
- Privately engage community members to understand and address the problem.
Anyone brought onboard should be given a link to the OpenBMC [security
response team guidelines][].
-- Work to determine the scope and severity of the problem, such as [CVSS metrics][].
+- Work to determine the scope and severity of the problem, such as [CVSS
+ metrics][].
- Work to create or identify an existing [CVE][].
- Coordinate workarounds and fixes with you and the community.
- Coordinate announcement details with you, such as timing or how you want to be
credited.
- Create an OpenBMC security advisory.
-Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][], (SPECIAL
-REPORT CMU/SEI-2017-SR-022) for additional considerations.
+Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][],
+(SPECIAL REPORT CMU/SEI-2017-SR-022) for additional considerations.
Alternatives to this process:
diff --git a/architecture/code-update/emmc-storage-design.md b/architecture/code-update/emmc-storage-design.md
index 59ccba1..875f2a7 100644
--- a/architecture/code-update/emmc-storage-design.md
+++ b/architecture/code-update/emmc-storage-design.md
@@ -135,8 +135,8 @@
- No initramfs: It may be possible to boot the rootfs by passing the UUID of the
logical volume to the kernel, although a [pre-init script][] will likely still
- be needed. Therefore, having an initramfs would offer a more standard implementation
- for initialization.
+ be needed. Therefore, having an initramfs would offer a more standard
+ implementation for initialization.
- FAT MBR partitioning: FAT is a simple and well understood partition table
format. There is space for 4 independent partitions. Alternatively one slot
diff --git a/architecture/code-update/flash-layout.md b/architecture/code-update/flash-layout.md
index 68eb1c6..b47f957 100644
--- a/architecture/code-update/flash-layout.md
+++ b/architecture/code-update/flash-layout.md
@@ -10,7 +10,8 @@
### Boot loading and init
-For system initialization and bootstrap, [Das U-Boot][] was selected as the bootloader.
+For system initialization and bootstrap, [Das U-Boot][] was selected as the
+bootloader.
After basic initialization of the system, the bootloader may present a prompt
and/or start automatic boot. The commands and/or data to select the boot image
diff --git a/architecture/interface-overview.md b/architecture/interface-overview.md
index b66c240..ebc38db 100644
--- a/architecture/interface-overview.md
+++ b/architecture/interface-overview.md
@@ -23,12 +23,14 @@
OpenBMC's services and the interfaces they provide are controlled by `systemd`.
This document references OpenBMC `systemd` unit names to help link concepts to
-the source code. The reader is assumed to be familiar with [systemd
-concepts][]. The templated units ("unit@.service") may be omitted for clarity. Relevant
-details from the unit file may be shown, such as the program which implements a service.
+the source code. The reader is assumed to be familiar with [systemd concepts][].
+The templated units ("unit@.service") may be omitted for clarity. Relevant
+details from the unit file may be shown, such as the program which implements a
+service.
The OpenBMC [Service Management][] interface can control `systemd` services. For
-example, disabling a BMC service will disable the corresponding external interface.
+example, disabling a BMC service will disable the corresponding external
+interface.
[systemd concepts]:
https://www.freedesktop.org/software/systemd/man/systemd.html#Concepts
@@ -250,8 +252,8 @@
+--------------------------------------------------+
```
-To learn more, read the [Phosphor D-Bus interface docs][] and search for README files
-in various subdirectories under the xyz/openbmc_project path.
+To learn more, read the [Phosphor D-Bus interface docs][] and search for README
+files in various subdirectories under the xyz/openbmc_project path.
[phosphor d-bus interface docs]:
https://github.com/openbmc/phosphor-dbus-interfaces
diff --git a/community-membership.md b/community-membership.md
index 78a7e5a..e0bdf7b 100644
--- a/community-membership.md
+++ b/community-membership.md
@@ -15,8 +15,9 @@
## New contributors
-[New contributors] should be welcomed to the community by existing members, helped
-with review workflow, and directed to relevant documentation and communication channels.
+[New contributors] should be welcomed to the community by existing members,
+helped with review workflow, and directed to relevant documentation and
+communication channels.
## Established community members
diff --git a/designs/dump-manager.md b/designs/dump-manager.md
index f774c73..67d12bf 100644
--- a/designs/dump-manager.md
+++ b/designs/dump-manager.md
@@ -165,7 +165,8 @@
come from a parallel class with this specific Enum name. All of the Enum
strings should be in the format
'domain.Dump.Create.CreateParameters.ParamName'. e.g.: { "key1": "value1",
- "key2": "value2" } ends up in AdditionaData like: ["KEY1=value1", "KEY2=value2"]
+ "key2": "value2" } ends up in AdditionaData like: ["KEY1=value1",
+ "KEY2=value2"]
- **Notify**: Notify the dump manager that a new dump is created.
- ID: ID of the dump, if not 0 this will be the external id of the dump
diff --git a/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md b/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md
index 394b6cb..8e61021 100644
--- a/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md
+++ b/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md
@@ -307,9 +307,9 @@
8. Proposal: xyz.openbmc_project.MachineContext
- Rejection: "We have all this stuff [.Model, .SerialNumber, ect. properties] defined
- already. I'm not going to accept a new "bunch of random properties HPe thinks
- are important [today] globbed into a new interface" interface"
+ Rejection: "We have all this stuff [.Model, .SerialNumber, ect. properties]
+ defined already. I'm not going to accept a new "bunch of random properties
+ HPe thinks are important [today] globbed into a new interface" interface"
- Patrick Williams, Phosphor-dbus-interfaces maintainer.
diff --git a/designs/expired-password.md b/designs/expired-password.md
index ad9db23..a2c5dc8 100644
--- a/designs/expired-password.md
+++ b/designs/expired-password.md
@@ -37,9 +37,9 @@
reason. Some servers (such as the OpenSSH server) handle the
PasswordChangeRequired by implementing a "password change dialog".
-The [Redfish Specification version 1.7.0][] section 13.2.6.1 ("Password change required
-handling") provides the ManagerAccount resource v1.3 with a PasswordChangeRequired
-property which supports a password change dialog.
+The [Redfish Specification version 1.7.0][] section 13.2.6.1 ("Password change
+required handling") provides the ManagerAccount resource v1.3 with a
+PasswordChangeRequired property which supports a password change dialog.
[redfish specification version 1.7.0]:
https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.7.0.pdf
diff --git a/designs/vpd-collection.md b/designs/vpd-collection.md
index 50950f7..1e52b63 100644
--- a/designs/vpd-collection.md
+++ b/designs/vpd-collection.md
@@ -8,9 +8,10 @@
On OpenBMC, Vital Product Data (VPD) collection is limited to only one or two
Field Replaceable Units (FRUs) today - one example is the BMC FRU. On OpenPower
-systems, the BMC also supports just one VPD format, the [OpenPower VPD] [1] format.
-As a part of its enterprise class servers, IBM will use the IPZ format VPD, which
-the BMC currently does not support. Certain FRUs also have keyword format VPD.
+systems, the BMC also supports just one VPD format, the [OpenPower VPD] [1]
+format. As a part of its enterprise class servers, IBM will use the IPZ format
+VPD, which the BMC currently does not support. Certain FRUs also have keyword
+format VPD.
The BMC requires to read VPD for all FRUs for several reasons:
diff --git a/features.md b/features.md
index 86ca688..6963e1d 100644
--- a/features.md
+++ b/features.md
@@ -5,8 +5,7 @@
- [BMCWeb][] HTTP/Web server
- [WebUI Vue][] web application
- REST Management: [BMCWeb Redfish][], [Phosphor REST APIs][] includes [Host
- management
- REST APIs][]
+ management REST APIs][]
- [D-Bus interfaces][] describes internal interfaces
- [D-Bus Object Mapper][]
- [Remote KVM][]
diff --git a/security/how-to-report-a-security-vulnerability.md b/security/how-to-report-a-security-vulnerability.md
index d577376..3bc3589 100644
--- a/security/how-to-report-a-security-vulnerability.md
+++ b/security/how-to-report-a-security-vulnerability.md
@@ -44,15 +44,16 @@
- Privately engage community members to understand and address the problem.
Anyone brought onboard should be given a link to the OpenBMC [security
response team guidelines][].
-- Work to determine the scope and severity of the problem, such as [CVSS metrics][].
+- Work to determine the scope and severity of the problem, such as [CVSS
+ metrics][].
- Coordinate workarounds and fixes with you and the community.
- Coordinate announcement details with you, such as timing or how you want to be
credited.
- At the agreed time, publish the OpenBMC security advisory, reveal the fix, and
publish the CVE.
-Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][], (SPECIAL
-REPORT CMU/SEI-2017-SR-022) for additional considerations.
+Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][],
+(SPECIAL REPORT CMU/SEI-2017-SR-022) for additional considerations.
Alternatives to this process:
diff --git a/security/network-security-considerations.md b/security/network-security-considerations.md
index 674bbfb..e9ebff3 100644
--- a/security/network-security-considerations.md
+++ b/security/network-security-considerations.md
@@ -6,13 +6,14 @@
This is only intended to be a guide; security is ultimately the responsibility
of projects which choose to incorporate OpenBMC into their project. If you find
-a security vulnerability, please consider [how to report a security vulnerability][].
+a security vulnerability, please consider [how to report a security
+vulnerability][].
[how to report a security vulnerability]:
https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md
-Threats to the BMC are classified using the [CIA triad][]. All threat types are significant;
-here is an example of each:
+Threats to the BMC are classified using the [CIA triad][]. All threat types are
+significant; here is an example of each:
- Confidentiality: If an attacker can get data from the BMC, they may be able to
chain other vulnerabilities to establish a covert information channel to get
@@ -51,9 +52,9 @@
the `https://github.com/openbmc/meta-aspeed` repository under
`recipes-kernel/linux/linux-aspeed_git.bb`.
-Per [CVE 1999-0524][], responding to certain ICMP packets can give an attacker more
-information about the BMC's clock or subnet, which can help with subsequent attacks.
-OpenBMC responds to all ICMP requests.
+Per [CVE 1999-0524][], responding to certain ICMP packets can give an attacker
+more information about the BMC's clock or subnet, which can help with subsequent
+attacks. OpenBMC responds to all ICMP requests.
[cve 1999-0524]: https://nvd.nist.gov/vuln/detail/CVE-1999-0524
@@ -108,9 +109,9 @@
1. Configure OpenBMC recipes to build the unwanted feature out of the BMC's
firmware image. This gives the BMC the advantage of a smaller attack
surface.
-2. Implement something like the [Redfish ManagerNetworkProtocol][] properties for
- IPMI, SSH, and other BMC services, possibly by using shell commands like 'systemctl
- disable ipmid' and 'systemctl stop ipmid'.
+2. Implement something like the [Redfish ManagerNetworkProtocol][] properties
+ for IPMI, SSH, and other BMC services, possibly by using shell commands like
+ 'systemctl disable ipmid' and 'systemctl stop ipmid'.
[redfish managernetworkprotocol]:
https://redfish.dmtf.org/schemas/ManagerNetworkProtocol.v1_4_0.json
@@ -208,9 +209,9 @@
#### The webui-vue Web application
-General considerations for Web applications such as given by [OWASP
-Web Application Security Guidance][] apply to OpenBMC. The webui-vue uses
-username and password-based authentication, and REST APIs for subsequent access.
+General considerations for Web applications such as given by [OWASP Web
+Application Security Guidance][] apply to OpenBMC. The webui-vue uses username
+and password-based authentication, and REST APIs for subsequent access.
[owasp web application security guidance]:
https://www.owasp.org/index.php/Web_Application_Security_Guidance
diff --git a/security/obmc-github-security-advisory-template.md b/security/obmc-github-security-advisory-template.md
index 6fd299b..76a8448 100644
--- a/security/obmc-github-security-advisory-template.md
+++ b/security/obmc-github-security-advisory-template.md
@@ -1,7 +1,8 @@
# OpenBMC Security Advisory Template
This has guidelines for OpenBMC repository maintainers to follow when creating
-new draft GitHub security advisories as part of the [Security response team guidelines][].
+new draft GitHub security advisories as part of the [Security response team
+guidelines][].
Note that the sections under the "Description" section are intended for the
security advisory "Description" field
diff --git a/security/obmc-security-response-team-guidelines.md b/security/obmc-security-response-team-guidelines.md
index b2b351f..2a3f615 100644
--- a/security/obmc-security-response-team-guidelines.md
+++ b/security/obmc-security-response-team-guidelines.md
@@ -47,8 +47,8 @@
response team. For example, link to these guidelines.
- Coordinate with all collaborators and keep them informed.
- Considerations in the [CERT Guide to Coordinated Vulnerability Disclosure][] (SPECIAL
- REPORT CMU/SEI-2017-SR-022) may guide the process.
+ Considerations in the [CERT Guide to Coordinated Vulnerability Disclosure][]
+ (SPECIAL REPORT CMU/SEI-2017-SR-022) may guide the process.
Example collaborations:
@@ -64,9 +64,10 @@
problems. When fixing the problem, use the contribution process but limit
the details in the issue or use a private channel to discuss.
3. Negotiate how the code review will proceed.
- - Consider [contributing][] using a Gerrit [private change][] if everyone has
- access to Gerrit.
- - Consider using [Patch set][] emails to make reviews accessible to all stakeholders.
+ - Consider [contributing][] using a Gerrit [private change][] if everyone
+ has access to Gerrit.
+ - Consider using [Patch set][] emails to make reviews accessible to all
+ stakeholders.
4. When agreed:
- Publish a security advisory to the affected OpenBMC repository.
- Make the Gerrit review publicly viewable.
@@ -76,18 +77,19 @@
Repository maintainer process steps: 1. Create a private gerrit code review and
oversee development of the fix. 2. Create a draft advisory under
github.com/openbmc/<REPO>/security/advisories. Please follow guidance in the
-[OpenBMC Security Advisory Template][]. Add the openbmc security-response group and
-other stakeholders to the advisory. 3. Review the security bulletin with stakeholders
-to get it ready to publish. 4. Work with the SRT to identify CVEs. If you are unsure
-what counts as a vulnerability, please consult with the SRT. For example, independent
-bugs should have separate CVEs. A security advisory can reference multiple CVEs.
-When the CVE is known, add it to the security advisory, and reference it in the commit
-message, stating how the fix relates to the CVE. For example: This fixes CVE-yyyy-nnnnn.
-Doing so helps downstream security responders. If the commit is a partial fix, please
-explain that and provide references to the other parts of the fix. 5. If stakeholders
-negotiate for coordinated disclosure, plan to release the fix and the security advisory
-on the negotiated day. 6. When the code fix and the advisory are both ready (subject
-to coordinated disclosure), please merge the fixes (and make any private review be
+[OpenBMC Security Advisory Template][]. Add the openbmc security-response group
+and other stakeholders to the advisory. 3. Review the security bulletin with
+stakeholders to get it ready to publish. 4. Work with the SRT to identify CVEs.
+If you are unsure what counts as a vulnerability, please consult with the SRT.
+For example, independent bugs should have separate CVEs. A security advisory can
+reference multiple CVEs. When the CVE is known, add it to the security advisory,
+and reference it in the commit message, stating how the fix relates to the CVE.
+For example: This fixes CVE-yyyy-nnnnn. Doing so helps downstream security
+responders. If the commit is a partial fix, please explain that and provide
+references to the other parts of the fix. 5. If stakeholders negotiate for
+coordinated disclosure, plan to release the fix and the security advisory on the
+negotiated day. 6. When the code fix and the advisory are both ready (subject to
+coordinated disclosure), please merge the fixes (and make any private review be
public) publish the security advisory, and email the security-response team.
[security vulnerability reporting process]: ./obmc-security-response-team.md