Bug#1141449: trixie-pu: package node-lodash/4.17.21+dfsg+~cs8.31.198.20210220-9+deb13u1

Jonathan Wiltshire <[email protected]> Sat, 25 Jul 2026 12:26:27 +0100
Newsgroups gmane.linux.debian.devel.release
Message-ID <amSdY2dgVJjQP2ek__3789.32070905051$1784978966$gmane$org@powdarrmonkey.net>
Control: tag -1 = trixie confirmed

On Fri, Jul 24, 2026 at 06:58:09PM +0530, Utkarsh Gupta wrote:
> Hi Jonathan,
> 
> On Wed, Jul 15, 2026 at 1:25 AM Jonathan Wiltshire <[email protected]> wrote:
> > JavaScript is not my forte, so I may be up the wrong tree here. But in:
> >
> > | if (key === '__proto__' &&
> > |     !hasOwnProperty.call(object, '__proto__')) {
> > |   return false;
> > }
> >
> > Could it be that `object` here is always the original object, rather than
> > the object at the current point in the path, allowing a later `__proto__`
> > to slip through?
> 
> Interesting point. I was able to probably reproduce what you're
> saying. "object" in that guard is the original root object, it's never
> advanced as the loop walks the path. The hole is specific to __proto__
> when the root carries an own __proto__ key. So only the __proto__
> guard is affected and the impact is deletion, not assignment.
> 
> Note this is upstream's code as shipped in 4.18.0 (commit fe8d32e), so
> it looks like a residual flaw in the upstream fix itself. I'll report
> it upstream: the proper correction is to check ownership against the
> current node during traversal rather than the root, I think?

Yes, if we're right about the issue that sounds the appropriate fix. But I
agree this is better handled upstream.

I'll take the current fixes in case upstream is not responsive in time
before the point release, even though it's a while away yet.


Thanks,