Request gitoid:sha1 and gitoid:sha256 as hash types for query api about deps.dev HOT 7 OPEN

As a side note, Software Heritage's SWHIDs also are basically just gitoids, and having compatibility here would be great.

from deps.dev.

As I understood this feature request, it's about matching source code files (e.g. .java files).

Right, but I have a hunch that this request was made out of the same misunderstanding of the API as I had: In @edwarnicke's view source code files seem to be artifacts (and leaves of the dependency tree), and the API sounded as if hashing of such "artifact" already is supported, and just gitoids would need to be added as an alternative hash algorithm.

Anyway, let's see what @edwarnicke responds 😀

PS: Personally, I don't share the view that source code files are the leaves of dependency trees. They're just the building blocks the leave artifacts are made of.

from deps.dev.

Oh... also... there is a URI scheme for gitoids if that proves helpful.

from deps.dev.

Hi @edwarnicke! If I've understood your feature request correctly, you want to query by a hash of a source code file and get a list of matching package versions. If so, I agree that would be neat, but it's not something we can currently support (regardless of whether the hash is expressed as in the current Query endpoint or using a gitoid). For the most part, we don't have a reliable link between a package version and the repo commit it was built from. The exceptions are Go (where the repo is the distribution format) and the small-but-growing number of npm package versions for which SLSA provenance attestations are available. We are working on expanding our support for that, however, so hopefully this will eventually be a feature we could support.

from deps.dev.

you want to query by a hash of a source code file and get a list of matching package versions. If so, I agree that would be neat, but it's not something we can currently support

The last sentence confused me as the docs of https://docs.deps.dev/api/v3alpha/#query sounded as if that already was supported. But I guess the term "content hash" refers to something else than hashes of files (no matter by which algorithm). On the other hand, further docs say "hashes are matched against multiple artifacts that comprise package versions, and any given artifact may appear in many package versions", which again does sound as if "artifacts" were files.

@sarnesjo could you maybe clarify what the supported content / artifact hashes are? Like, in the case of maven, would it be the hash of the binary / source JAR?

from deps.dev.

Right, that wording could be more clear–I'll update the docs. What it should say is "hashes are matched against multiple release artifacts that comprise package versions". The exact meaning of this varies from system to system. For Maven, yes, it's the various .jar (and .war, etc) files uploaded to one of the Maven repositories that we track.

As I understood this feature request, it's about matching source code files (e.g. .java files).

from deps.dev.

For java, besides the .jar and .war files on the one hand, and the .java source code files on the other, there's also the compiled .class files that one could hash and query. I imagine being able to query on the level of .class files would be useful when encountering fat jars?

from deps.dev.