google/android-classyshark

Security Policy violation Binary Artifacts

allstar-app opened this issue · 7 comments

allstar-app commented

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 commented
borisf commented

Done, removed all the jars

anantshri commented

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

borisf commented

Thanks Anant,

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

anantshri commented

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
    google/accompanist#1101: added exception
    google/charts#757 : automagically approved even though the file exists
    google/android-fhir#1253 : went the exception way
  3. do check 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 commented

ossf/scorecard#1815 Additional reference.