local precommit doesn't match github runner verison #45
Comments
|
I ran it on several OSes today and was greeted with the same issues as the pre-commit action: Updating pre-commit hooks.
Fixing docs/ttp-dev.md trim trailing whitespace.................................................Failed
Fixing docs/ttp-dev.md check for added large files..............................................Passed
args: ttps/macOS/README.md ttps/cloud/aws/secretsmanager/steal-secretsmanager-secret/README.md README.md ttps/examples/outputs/README.md args: ttps/examples/args/README.md ttps/discovery/get-running-processes/README.md .github/CODE_OF_CONDUCT.md .github/CONTRIBUTING.md args: ttps/persistence/ssh/backdoor-ssh-authorized-keys/README.md .github/ISSUE_TEMPLATE.md ttps/cloud/aws/iam/revive-old-iam-user/README.md .github/PULL_REQUEST_TEMPLATE.md args: ttps/cloud/aws/iam/escalate-old-iam-user/README.md ttps/privilege-escalation/credential-theft/enumerate-creds-lazagne/README.md docs/ttp-dev.md ttps/defense-evasion/macos/disable-system-updates/README.md docs/ttp-dev.md:178: MD010 Hard tabs A detailed description of the rules is available at https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md codespell................................................................Passed
TTP Development-This document introduces concepts to help developers TTP Anatomy-ForgeArmory TTPs are designed to be consumed by TTPForge, Metadata-TTP metadata must include the name of the TTP and a description of that TTP's An example of TTP metadata is shown below. Arguments-Arguments are defined after the TTP metadata. Arguments are uniquely named, @@ -58,7 +58,7 @@ steps:
### Steps
-Steps are uniquely named blocks of implementation logic which are executed in
+Steps are uniquely named blocks of implementation logic which are executed in
sequence. Steps help developers organize and manage the complexity of TTPs.
In general, steps will fall into one of the following high-level categories;
@@ -68,16 +68,16 @@ In general, steps will fall into one of the following high-level categories;
- Execution
- Cleanup
-Additionally, TTPs may be daisy-chained enabling developers to create complex
-sequences of TTPs. In doing so, each daisy-chained TTP is represented in the
-parent TTP as a sub-TTP. We'll see an example of this shortly and some
+Additionally, TTPs may be daisy-chained enabling developers to create complex
+sequences of TTPs. In doing so, each daisy-chained TTP is represented in the
+parent TTP as a sub-TTP. We'll see an example of this shortly and some
recommendations on developing sub-TTPs as common building blocks.
#### Assessment
-It is often necessary for a TTP to test execution requirements, such as whether
-a necessary environment variable is set, and bail out of the TTP if it is not.
-In this example, if the `AWS_DEFAULT_REGION` environment variable is not set,
+It is often necessary for a TTP to test execution requirements, such as whether
+a necessary environment variable is set, and bail out of the TTP if it is not.
+In this example, if the `AWS_DEFAULT_REGION` environment variable is not set,
the TTP returns exit code 1 and no further blocks are executed.
```yaml
@@ -90,20 +90,20 @@ steps:
echo "Error: AWS_DEFAULT_REGION must be set."
exit 1
fi
-
+
<- snip ->-When creating assessment type blocks, it's preferable to place each test in its Shaping-It is often necessary for a TTP to install dependencies, stage files, or shape @@ -124,18 +124,18 @@ action in its own block.
#### Execution
-The execution blocks contain the core TTP logic. A single execution block may
+The execution blocks contain the core TTP logic. A single execution block may
be sufficient for simple TTPs such as atomics, which contain a single procedure.
-For complex TTPs, the core logic should be broken up across multiple steps or
-sub-TTPs. In general, if the core logic implements multiple procedures or the
+For complex TTPs, the core logic should be broken up across multiple steps or
+sub-TTPs. In general, if the core logic implements multiple procedures or the
procedure can be reasonably divided, refactoring into smaller steps will enhance
maintainability.
-Code likely to be reused in other TTPs should be placed in a sub-TTP and imported
-where needed. It's easier to maintain building blocks than to modify the same
-(reimplemented) code in multiple places. Good candidates for sub-TTPs include
-assessment and shaping operations. Here, you might check for commonly used
-prerequisites, install frequent tools, or tamper with security controls before
+Code likely to be reused in other TTPs should be placed in a sub-TTP and imported
+where needed. It's easier to maintain building blocks than to modify the same
+(reimplemented) code in multiple places. Good candidates for sub-TTPs include
+assessment and shaping operations. Here, you might check for commonly used
+prerequisites, install frequent tools, or tamper with security controls before
the primary execution block.
```yaml
@@ -148,11 +148,11 @@ steps:
#### Cleanup
-In addition to the implementation logic, each TTP must contain a `cleanup` block
-to revert artifacts from the preceding blocks. If no implementation blocks produce
+In addition to the implementation logic, each TTP must contain a `cleanup` block
+to revert artifacts from the preceding blocks. If no implementation blocks produce
artifacts, the `cleanup` block should just return a success log.
-Example with implementation block artifacts: Here, we revert changes made in
+Example with implementation block artifacts: Here, we revert changes made in
previous steps.
```yaml
steps:
@@ -169,7 +169,7 @@ steps:
echo "[+] DONE!"-Example without implementation block artifacts: No changes were made to the steps:
@@ -182,4 +182,3 @@ steps:
inline: |
echo "No cleanup needed, as this TTP simply dumped clipboard contents to stdout."Error: failed to run pre-commit with args [run --all-files --show-diff-on-failure]: stdout: [INFO] Initializing environment for https://github.com/pre-commit/pre-commit-hooks.
Fixing docs/ttp-dev.md trim trailing whitespace.................................................Failed
Fixing docs/ttp-dev.md check for added large files..............................................Passed
args: ttps/macOS/README.md ttps/cloud/aws/secretsmanager/steal-secretsmanager-secret/README.md README.md ttps/examples/outputs/README.md args: ttps/examples/args/README.md ttps/discovery/get-running-processes/README.md .github/CODE_OF_CONDUCT.md .github/CONTRIBUTING.md args: ttps/persistence/ssh/backdoor-ssh-authorized-keys/README.md .github/ISSUE_TEMPLATE.md ttps/cloud/aws/iam/revive-old-iam-user/README.md .github/PULL_REQUEST_TEMPLATE.md args: ttps/cloud/aws/iam/escalate-old-iam-user/README.md ttps/privilege-escalation/credential-theft/enumerate-creds-lazagne/README.md docs/ttp-dev.md ttps/defense-evasion/macos/disable-system-updates/README.md docs/ttp-dev.md:178: MD010 Hard tabs A detailed description of the rules is available at https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md codespell................................................................Passed
TTP Development-This document introduces concepts to help developers TTP Anatomy-ForgeArmory TTPs are designed to be consumed by TTPForge, Metadata-TTP metadata must include the name of the TTP and a description of that TTP's An example of TTP metadata is shown below. Arguments-Arguments are defined after the TTP metadata. Arguments are uniquely named, @@ -58,7 +58,7 @@ steps:
### Steps
-Steps are uniquely named blocks of implementation logic which are executed in
+Steps are uniquely named blocks of implementation logic which are executed in
sequence. Steps help developers organize and manage the complexity of TTPs.
In general, steps will fall into one of the following high-level categories;
@@ -68,16 +68,16 @@ In general, steps will fall into one of the following high-level categories;
- Execution
- Cleanup
-Additionally, TTPs may be daisy-chained enabling developers to create complex
-sequences of TTPs. In doing so, each daisy-chained TTP is represented in the
-parent TTP as a sub-TTP. We'll see an example of this shortly and some
+Additionally, TTPs may be daisy-chained enabling developers to create complex
+sequences of TTPs. In doing so, each daisy-chained TTP is represented in the
+parent TTP as a sub-TTP. We'll see an example of this shortly and some
recommendations on developing sub-TTPs as common building blocks.
#### Assessment
-It is often necessary for a TTP to test execution requirements, such as whether
-a necessary environment variable is set, and bail out of the TTP if it is not.
-In this example, if the `AWS_DEFAULT_REGION` environment variable is not set,
+It is often necessary for a TTP to test execution requirements, such as whether
+a necessary environment variable is set, and bail out of the TTP if it is not.
+In this example, if the `AWS_DEFAULT_REGION` environment variable is not set,
the TTP returns exit code 1 and no further blocks are executed.
```yaml
@@ -90,20 +90,20 @@ steps:
echo "Error: AWS_DEFAULT_REGION must be set."
exit 1
fi
-
+
<- snip ->-When creating assessment type blocks, it's preferable to place each test in its Shaping-It is often necessary for a TTP to install dependencies, stage files, or shape @@ -124,18 +124,18 @@ action in its own block.
#### Execution
-The execution blocks contain the core TTP logic. A single execution block may
+The execution blocks contain the core TTP logic. A single execution block may
be sufficient for simple TTPs such as atomics, which contain a single procedure.
-For complex TTPs, the core logic should be broken up across multiple steps or
-sub-TTPs. In general, if the core logic implements multiple procedures or the
+For complex TTPs, the core logic should be broken up across multiple steps or
+sub-TTPs. In general, if the core logic implements multiple procedures or the
procedure can be reasonably divided, refactoring into smaller steps will enhance
maintainability.
-Code likely to be reused in other TTPs should be placed in a sub-TTP and imported
-where needed. It's easier to maintain building blocks than to modify the same
-(reimplemented) code in multiple places. Good candidates for sub-TTPs include
-assessment and shaping operations. Here, you might check for commonly used
-prerequisites, install frequent tools, or tamper with security controls before
+Code likely to be reused in other TTPs should be placed in a sub-TTP and imported
+where needed. It's easier to maintain building blocks than to modify the same
+(reimplemented) code in multiple places. Good candidates for sub-TTPs include
+assessment and shaping operations. Here, you might check for commonly used
+prerequisites, install frequent tools, or tamper with security controls before
the primary execution block.
```yaml
@@ -148,11 +148,11 @@ steps:
#### Cleanup
-In addition to the implementation logic, each TTP must contain a `cleanup` block
-to revert artifacts from the preceding blocks. If no implementation blocks produce
+In addition to the implementation logic, each TTP must contain a `cleanup` block
+to revert artifacts from the preceding blocks. If no implementation blocks produce
artifacts, the `cleanup` block should just return a success log.
-Example with implementation block artifacts: Here, we revert changes made in
+Example with implementation block artifacts: Here, we revert changes made in
previous steps.
```yaml
steps:
@@ -169,7 +169,7 @@ steps:
echo "[+] DONE!"-Example without implementation block artifacts: No changes were made to the steps:
@@ -182,4 +182,3 @@ steps:
inline: |
echo "No cleanup needed, as this TTP simply dumped clipboard contents to stdout.", stderr: , err: exit status 1 I'd recommend reinstalling pre-commit on your system. I was running: pre-commit 3.3.3 |
What happened?
Steps to reproduce:
Expected:
Tests should fail locally as they do in Github.
Actual:
All tests pass in local precommit environment.
Any suggestions for fixing this bug?
No response
Relevant log output
bash-3.2$ sw_vers
ProductName: macOS
ProductVersion: 13.5
BuildVersion: 22G74
bash-3.2$ which mage
/Users/vvx7/.asdf/installs/golang/1.21.0/packages/bin/mage
bash-3.2$ which go
/Users/vvx7/.asdf/shims/go
bash-3.2$ go version
go version go1.21.0 darwin/amd64
The text was updated successfully, but these errors were encountered: