Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We need a way to find download location for artifacts from local maven #42

Open
AlexanderYukhanov opened this issue Sep 5, 2023 · 5 comments

Comments

@AlexanderYukhanov
Copy link
Collaborator

When using a local Maven repository for hermetic builds, the build system is currently unable to determine the origin of the artifacts. This results in NOASSERTION being generated for download locations, which can create issues in EO compliance.

I propose that we support annotation of Maven artifacts in local repositories by placing a origin.json file in the folder that contains the artifact. The origin.json file would contain metadata that describes where the artifact was sourced from. For example:

{
  "mavenUrl": "https://repo1.maven.org/maven2"
}

What do you think?

@loosebazooka
Copy link
Collaborator

loosebazooka commented Sep 5, 2023

So this is technically possible using the extension and keeping another set of metadata for this. I think @mathjeff is doing this for androidX. Maybe we need to think about how origin.json would get populated? and how it would surface itself to the gradle repository/dependency handlers?

@AlexanderYukhanov
Copy link
Collaborator Author

For the first part, it's simple - we can always make it users's responsibility to create and maintain origin.json.
The second part there are multiple solutions:

  1. use org.eclipse.aether to resolve the artifacts in local repository and use the returned path information;
  2. or just find the folder containing jar with given sha225sum in local maven path and get origin.json from it

@mathjeff, what is your approach for androidx, are you actively working on it, any ETA?

@mathjeff
Copy link
Collaborator

mathjeff commented Sep 5, 2023

For passing this information to the spdx-gradle-plugin we use DefaultSpdxSbomTaskExtension.mapRepoUri:

https://android.googlesource.com/platform/frameworks/support/+/13aec9976bb86fb43c24c5756e73700c87beb180/buildSrc/private/src/main/kotlin/androidx/build/sbom/Sbom.kt#242

@mathjeff
Copy link
Collaborator

mathjeff commented Sep 5, 2023

In AndroidX we probably haven't figured out the longterm solution for acquiring this information; for the moment we don't download relevant artifacts from very many places, so we have essentially have a map from filepath (of local maven repo) to remote maven url.

Some ideas:

A) keep our hardcoded map for now until we need something better
B) add per-artifact metadata that gets saved whenever an artifact is downloaded
C) keep the hardcoded map but also, when we download artifacts, validate that the urls they actually came from match what is expected by the map

It almost feels to me that the most expressive data model would be for us to tell Gradle where the remote urls are and where our local cache repositories are and which local cache repository to use for the corresponding remote url, although during normal builds we don't want Gradle to consider the remote urls anyway. Perhaps that would be similar to having a new local directory for each remote repository.

Maybe related, we have a script for downloading remote artifacts ( https://android.googlesource.com/platform/frameworks/support/+/13aec9976bb86fb43c24c5756e73700c87beb180/development/importMaven/importMaven.sh ) which we might update

@AlexanderYukhanov
Copy link
Collaborator Author

Keeping information about url mapping in the build system sounds a bit ... uncomfortable to me. It feels that the build system should not be a source of information but only proceed external information, so B sounds the most reasonable to me.
I do not see how creating a new directory for each remote repository will simplify the life, having a script like yours which stores origin.json next to the downloaded artifact seems to be a simpler solution

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants