Bump hosted-git-info from 2.8.8 to 2.8.9

[dependabot[bot]]

Bumps hosted-git-info from 2.8.8 to 2.8.9.

Changelog

Sourced from hosted-git-info's changelog.

2.8.9 (2021-04-07)

Bug Fixes

• backport regex fix from #76 (29adfe5), closes #84

Commits

• 8d4b369 chore(release): 2.8.9
• 29adfe5 fix: backport regex fix from #76
• See full diff in compare view

Maintainer changes

This version was pushed to npm by nlf, a new releaser for hosted-git-info since your current version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

[carnil]

This issue seems to have gotten CVE-2024-34997 assigned.

[tomMoral]

Hello,

Thanks for the issue, however, I don't think it makes sense in the context of the joblib library. Note that similar issue has already been discussed in #977

Here, the NumpyArrayWrapper is used internally to persist numpy arrays in the context of sharing objects between two processes/distributed experiments/caching. One of joblib's goal is to allow the user to serialize any Python object to communicate tasks or results, or to cache results. To achieve this, we need to be as open as possible with our serialization and therefor use the pickle format.

IMO, a simpler and unsafe pattern is even simpler than this:

import os
import pickle

class A:
    def __reduce__(self):
        return (os.system,('whoami',))
    
a=A()

with open('a.pkl','wb') as file:
    pickle.dump(a,file)
with open('a.pkl', 'rb') as file:
    pickle.load(file)

So why add an extra feature to avoid this in a nested case? We are already making it clear that joblib.load should not be used for inter-user sharing on this page: https://joblib.readthedocs.io/en/stable/generated/joblib.load.html We could maybe make the NumpyArrayWrapper private to make it clearer it should not be used outside the parallel/caching context if you think this is not clear enough (it is not exposed in the doc).

I am closing this issue for now but feel free to continue the discussion if you think I am missing some points.

[rshanlever]

With their being an NVD entry for this that isn't marked as disputed, it's flagging this component in security scanners. Probably bad to leave it in limbo.

[tomMoral]

Hi, I am sorry but I have no idea how to dispute this CVE. If you have any guide toward how we can remove this flag, this would be super helpful.

[AxelTeichert]

https://www.cve.org/Resources/General/Policies/CVE-Record-Dispute-Policy.pdf

[noren95]

@tomMoral So what are your conclusions in this case? As I understand this behavior is a part of joblib (that allows de/serialization), and the apparently "vulnerability" is caused by an incorrect use of the component?

[AxelTeichert]

Well, if you would kindly write a dispute, it looks much better to company users of this module.

[Martinogorman-tp]

This package is now flagged by our security scanners. We can no longer download due to https://nvd.nist.gov/vuln/detail/CVE-2024-34997

[mcvincekova]

@tomMoral what should our expectations be in this case? unless this is fixed or the issue is disputed, we will need to drop usage of this library, due to it being flagged as insecure.

Can we reopen this issue (or should I make a new one), since it doesn't look like it has been resolved? Unless the it's correct behaviour is the resolution we should accept and move to a different lib.

Thanks for any update.

[tomMoral]

Hello,

As stated above, inter-process communication requires pickling arbitrary code, so this is the correct behavior. The pickle load is produced by the main process, which should have a secure connection with the worker processes so I think it is quite hard to attack. For joblib.load there is a note stating it should never be used to load files from untrusted sources.

The fact that the library was flagged for this behavior is problematic and I am happy to dispute this. However, I have no clue where I should do this and I don't have the time to investigate. I don't see where I should enter extra information on this page: https://nvd.nist.gov/vuln/detail/CVE-2024-34997

If you can point me toward where I should dispute this, I will do this quickly.

[mcvincekova]

Hey, thanks for the response.

I am not a 100% sure about the process, but given the official guide and the contact info on their official page, I think you can:

• Request an update to an existing CVE via their contact form
• Wait for the response & see what is required for you to complete the dispute claim

I hope that helps.

[tomMoral]

Thanks, I did send them a request for update. I will keep you inform when I hear back from them.

[GaelVaroquaux]

I think that we should re-open this issue as long as the upstream CVE is open, as the upstream CVE is impacting the users.

@tomMoral, what do you think?

[tomMoral]

On the official CVE website, the security issue is marked as disputed with a link to this discussion: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-34997 (I just checked today, did not received any feedback on the dispute and I don't know how to make the CVE close the matter).

I would say it is ok to keep this one close, but if you feel that it is helpful to re-open a tracking of the CVE, I would be in favor of re-opening one specifically referencing and tracking the CVE like this one: https://github.com/joblib/joblib/issues/1588

[GaelVaroquaux]

OK, I'll re-open the other one. Thanks @tomMoral !!