Security Policy violation Binary Artifacts

[allstar-app]

This issue was automatically created by Allstar.

Security Policy Violation
Project is out of compliance with Binary Artifacts policy: binaries present in source code

Rule Description
Binary Artifacts are an increased security risk in your repository. Binary artifacts cannot be reviewed, allowing the introduction of possibly obsolete or maliciously subverted executables. For more information see the Security Scorecards Documentation for Binary Artifacts.

Remediation Steps
To remediate, remove the generated executable artifacts from the repository.

Artifacts Found

• ClassySharkWS/gradle/wrapper/gradle-wrapper.jar
• third_party/asmdex-1.0.jar
• third_party/java-binutils.jar
• third_party/util-2.0.6.jar

Additional Information
This policy is drawn from Security Scorecards, which is a tool that scores a project's adherence to security best practices. You may wish to run a Scorecards scan directly on this repository for more details.

---

Allstar has been installed on all Google managed GitHub orgs. Policies are gradually being rolled out and enforced by the GOSST and OSPO teams. Learn more at http://go/allstar

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

[yijigu7745]

  您好，您发送的邮件我已收到，谢谢。

[borisf]

Done, removed all the jars

[anantshri]

@borisf you have broken the build process coz of this action #202 please suggest alternative ways in which packages an be built.

[borisf]

Thanks Anant,

Removing jars is our policy, thus we need to think about ways to overcome. Open for suggestions.

[anantshri]

I will be honest and brutal here

1. Adhering to policy for the sake of adherence is total BS in my humble opinion
2. lets look at how others have handled the same issue
   example
   Security Policy violation Binary Artifacts accompanist#1101: added exception
   Security Policy violation Binary Artifacts charts#757 : automagically approved even though the file exists
   Security Policy violation Binary Artifacts android-fhir#1253 : went the exception way
3. do check Feature: provide an ignore list for Binary-Artifact check in GitHub action ossf/scorecard#1270

With that said I can understand why such a policy will exist, and I am totally in favour of implementing such policy long term. However here is the scenario right now.
a. Project claims to be opensource
b. Project provides jar file as final artifact
c. Project claims to have a compilation menthod (gradlew) which is non functional as jars are referenced in it without being present. https://github.com/google/android-classyshark/blob/master/ClassySharkWS/build.gradle#L30
d. There is no way a user can obtain jar or compile the project.

I see a few way forward.
i) add exceptions restore jars and continue running the project.
ii) remove all local jar references and make project work without local jars
iii) clearly mention that this project is only code visible but is not compilable by outsiders and outside contributions might not be acceptable or desired. (if anyone cant compile they cant submit updates mostly.) : example https://github.com/google/charts#development

[anantshri]

additional references added https://docs.gradle.org/current/userguide/gradle_wrapper.html#:~:text=Adding%20the%20JAR%20file%20to%20version%20control%20is%20expected.

[anantshri]

ossf/scorecard#1815 Additional reference.