[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [open-regulatory-compliance] CRA Standardisation request
|
Yes, I agree that upstream can’t know about the ultimate version of its deps until integration - but it DOES know about the version of the deps it needs (no matter how fuzzy)…
On 2/18/2025 11:08 AM, Daniel Thompson-Yvetot via
open-regulatory-compliance wrote:
> @Tobie - if you think the lack of idempotency for libraries is
> troubling, wait til you hear about the new techniques around module
> federation. ;)
For awareness: The 'lack of idempotency for libraries' problem is not
limited to the _javascript_/npm example. The problem also exists...and is
arguably significantly harder...in the install technology used by
Eclipse-based projects and products (called 'equinox p2').
>
> But seriously I think the text is a copout from the JS sec team. I
> agree with Dick, some knowledge is better than none, e.g. in practice,
> I don’t care what version of jquery is used, if it is in your
> package.json / lockfile / reposource I will deep dive.
>
> I feel that their analysis is missing the fact that a library’s entire
> dependency tree can be inferred from the package.JSON - and that
> information IS valuable.
Admittedly it's valuable...but it's also *static*. Just the fact that
in osgi/p2 acceptable version *ranges* constraints are given for
dependencies means that the target environment (i.e. what else is
present at install time as well as what repos are know/available) will
determine the dependency resolution....i.e. what version of a dependency
is resolved dynamically at install time.
>
> The guarantee of a library is that it will never have dependencies
> other than direct, indirect, or transitive. Maybe the lesson here is
> that a library should “presolve” for a known range of upstream library
> versions that are expected to be viable.
That would also end up being static (across time/new versions of
dependencies)...and so would require regular library-level (or lower)
maintenance.
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
