This looks fine, but is there a justification?

this is to fix a github alert of a potential security concern to upgrade this version of jinja2

I need some background to understand this PR:

Was Jinja2 previously installed via the mkdocs-material package in our Pipfile?

If so, is this PR the result of you (Franklin) doing a manual upgrade of Jinja2 in your local pipenv and then pushing the updated Pipfile.lock?

Would another solution be to wait for mkdocs-material to update their dependencies (Jinja2) and wait until it passes down to us?

this is to settle the github alert regarding the security concern. I grabbed the hashes from a different upgraded repo. not sure what exactly it traces back to, but its purpose is to settle the github alert

Could you link from where you got the hashes?

The hashes are simply there to specify the exact version of Jinja2 on pypi.

It's probably not the intended way of pipenv to copy the hashes from somewhere else. But it seems to work? 🤷‍♂️ not sure if this practice is a bit insecure in itself though...

Looks like mkdocs's only jinja2 constraint is >=2.7.1.

That said, lockfiles probably shouldn't be edited by hand. Can we upgrade our constraint to >=2.10.1 and let pipenv recreate the lockfile?

We are not specifying a version of Jinja2 anywhere in our project. See

Okay. Then we can probably just re-lock, or whatever the pipenv operation is, and let the most recent version of jinja2 get pinned.

Yes, I think so too. That's what I wanted to clarify in my comment above:

If so, is this PR the result of you (Franklin) doing a manual upgrade of Jinja2 in your local pipenv and then pushing the updated Pipfile.lock?

this is to fix our potential security vulnerability. I tried in the past to let pipenv do it and there was an assortment of issues I ran into. (previously seen vulnerability fix #144). These concerns pop up once in a while and the solution has been to upgrade the little parts. I have tried on my few other repo copies of the specification (i.e. https://github.com/franklin-feingold/bids-specification-test) to confirm this will fix the vulnerability.