gtristan commented on code in PR #1997:
URL: https://github.com/apache/buildstream/pull/1997#discussion_r2055273339
##########
src/buildstream/downloadablefilesource.py:
##########
@@ -270,6 +270,13 @@ def fetch(self): # pylint: disable=arguments-differ
"File downloaded from {} has sha256sum '{}', not
'{}'!".format(self.url, sha256, self.ref)
)
+ def collect_source_info(self):
+ #
+ # XXX remote sources are not necessarily archives, perhaps we should
+ # allow downloadablefilesource imlementations to choose the
SourceInfoMedium
+ #
+ return [SourceInfo(self.url, SourceInfoMedium.ARCHIVE,
SourceVersionType.SHA256, self.ref)]
Review Comment:
I don't believe that we should worry about congruency of cache keys with the
result of URLs found in SBoMs.
However I agree that we should be *aware* of that detail.
I am *more* concerned that the URLs reported in the SBoMs are the
intentionally expressed *upstreams* rather than downstream mirrors, as this is
a more accurate description of the *provenance* of the data which led, under
some configuration, to an artifact with a cache key,
> I'm not sure whether that's the case. Won't the alias definition from the
parent project be used if the alias from > the subproject is mapped in the
junction? That alias definition could potentially point to a different URL
without > affecting the cache key.
This sounds like a *you get what you pay for* scenario. I.e. if you have
overridden the defaults for the default aliases of sources in a subproject,
rather than just adding your own mirrors, then the SBoMs would still accurately
describe what your toplevel project has expressed in terms of inputs.
It is however undesirable for toplevels to redirect the default aliases, and
as with the above note about cache keys, I agree that it should be *known*.
I'll leave this comment open for now as a reminder that this indeed should
be documented in the appropriate places.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
