Merge branch 'master' into releases/v1

.github/workflows/test.yml → .github/workflows/ci.yml

@@ -1,4 +1,4 @@
-name: "build-test"
+name: ci
 on: # rebuild any PRs and main branch changes
   pull_request:
   push:
@@ -10,14 +10,14 @@ jobs:
   build: # make sure build/ci work properly
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@v1
+    - uses: actions/checkout@v2
     - run: |
         npm install
         npm run all
   test: # make sure the action works on a clean machine without building
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@v1
+    - uses: actions/checkout@v2
     - uses: ./
       with:
         # to allow the invalid wrapper jar present in test data

.gitignore

@@ -98,6 +98,5 @@ Thumbs.db
 __tests__/runner/*
 lib/**/*
 
-.idea
+.idea/
 *.iml
-

README.md

@@ -1,5 +1,5 @@
 <p align="center">
-  <a href="https://github.com/gradle/wrapper-validation-action/actions"><img alt="gradle/wrapper-validation-action status" src="https://github.com/gradle/wrapper-validation-action/workflows/build-test/badge.svg"></a>
+  <a href="https://github.com/gradle/wrapper-validation-action/actions"><img alt="gradle/wrapper-validation-action status" src="https://github.com/gradle/wrapper-validation-action/workflows/ci/badge.svg"></a>
 </p>
 
 # Gradle Wrapper Validation Action
@@ -15,7 +15,7 @@ Searching across GitHub you can find many pull requests (PRs) with helpful title
 Many of these PRs are contributed by individuals outside of the organization maintaining the project.
 
 Many maintainers are incredibly grateful for these kinds of contributions as it takes an item off of their backlog.
-We assume that most maintainers do not consider the security implications of accepting the Gradle Wrapper binary from an external contributors.
+We assume that most maintainers do not consider the security implications of accepting the Gradle Wrapper binary from external contributors.
 There is a certain amount of blind trust open source maintainers have.
 Further compounding the issue is that maintainers are most often greeted in these PRs with a diff to the `gradle-wrapper.jar` that looks like this.
 
@@ -24,8 +24,6 @@ Further compounding the issue is that maintainers are most often greeted in thes
 A fairly simple social engineering supply chain attack against open source would be contribute a helpful “Updated to Gradle xxx” PR that contains malicious code hidden inside this binary JAR.
 A malicious `gradle-wrapper.jar` could execute, download, or install arbitrary code while otherwise behaving like a completely normal `gradle-wrapper.jar`.
 
-This problem is unique to open source and doesn’t normally impact companies with closed source and pre-vetted employees.
-
 ## Solution
 
 We have created a simple GitHub Action that can be applied to any GitHub repository.
@@ -39,15 +37,20 @@ Additionally, the action will find and SHA-256 hash all
 variants of files named `gradle-wrapper.jar`,
 for example a file named `gradlе-wrapper.jar` (which uses a Cyrillic `е` instead of `e`).
 The goal is to prevent homoglyph attacks which may be very difficult to spot in a GitHub diff.
+We created an example [Homoglyph attack PR here](https://github.com/JLLeitschuh/playframework/pull/1/files).
 
 ## Usage
 
-Simply add this action to your workflow **after** having checked out your source tree and **before** running any Gradle build:  
+### Add to an existing Workflow
+
+Simply add this action to your workflow **after** having checked out your source tree and **before** running any Gradle build:
 
 ```yaml
 uses: gradle/wrapper-validation-action@v1
 ```
 
+### Add a new dedicated Workflow
+
 Here's a sample complete workflow you can add to your repositories:
 
 **`.github/workflows/gradle-wrapper-validation.yml`**
@@ -64,6 +67,26 @@ jobs:
       - uses: gradle/wrapper-validation-action@v1
 ```
 
+## Contributing to an external GitHub Repository
+
+Since [GitHub Actions](https://github.com/features/actions)
+are completely free for open source projects and are automatically enabled on almost all projects,
+adding this check to a project's build is as simple as contributing a PR.
+Enabling the check requires no overhead on behalf of the project maintainer beyond merging the action.
+
+You can add this action to your favorite Gradle based project without checking out their source locally via the
+GitHub Web UI thanks to the 'Create new file' button.
+
+![GitHub 'Create new file' Button bar picture](https://user-images.githubusercontent.com/1323708/73676469-6c023c00-4682-11ea-8c0a-5a1e2d29b17f.png)
+
+Simply add a new file named `.github/workflows/gradle-wrapper-validation.yml` with the contents mentioned above.
+
+We recommend the message commit contents of:
+ - Title: `Official Gradle Wrapper Validation Action`
+ - Body (at minimum): `See: https://github.com/gradle/wrapper-validation-action`
+
+From there, you can easily follow the rest of the prompts to create a Pull Request against the project.
+
 ## Reporting Failures
 
 If this GitHub action fails because a `gradle-wrapper.jar` doesn't match one of our published SHA-256 checksums,
@@ -73,6 +96,14 @@ If you're curious and want to explore what the differences are between the `grad
 and one of our valid release, you can compare them using this online utility: [DiffScope](https://try.diffoscope.org/).
 Regardless of what you find, we still kindly request that you reach out to us and let us know about any issues you encountered.
 
+
+**Note:** When _initially_ applying this action to your project,
+if your `gradle-wrapper.jar` was generated by Gradle 3.3 to 4.0, the check will fail.
+This is because these `gradle-wrapper.jar` versions were dynamically generated by Gradle in a non-reproducible manner.
+As such, it's not possible to verify the `gradle-wrapper.jar` for those versions are legitimate using a hash comparison.
+If the Gradle version in use is out of this range it is possible that your Wrapper JAR is out of sync.
+To fix this run `./gradlew wrapper`. If the Gradle version in use is in the problematic range, you should consider upgrading.
+
 ## Resources
 
 To learn more about verifying the Gradle Wrapper JAR locally, see our

RELEASING.md

@@ -0,0 +1,14 @@
+# Release
+
+* starting on `master`
+* `npm run all`
+* `git checkout releases/v1`
+* `git merge master`
+* `npm prune --production`
+* `git add -f node_modules`
+  * if changed dependencies `git commit -m Dependencies && git push`
+* `git tag v1.0.x && git push --tags` with the actual version number
+* `git tag --delete v1 && git push --delete origin v1 && git tag v1 && git push --tags`
+* go to https://github.com/gradle/wrapper-validation-action/releases
+  * edit and publish the now drafted `v1` release
+  * create a new release from the new full version number `v1.0.x`, list the fixed issues and publish the release