Upgrade Jinja to 3.1.6

[aidenfoxivey]

As per
GHSA-cpwx-vrp4-4pq7 use of Jinja 3.1.5 has a vulnerability. It's probably not an incredible problem, but it would be best to upgrade these packages to stay updated with bugfixes.

This follows the Nix flake model where the inputs are not pinned explicitly, so 'updating' them will actually increment their versions.

[coveralls]

coverage: 82.752% (-0.003%) from 82.755%
when pulling 0efb289 on aidenfoxivey:dev
into 01de36c on open-quantum-safe:main.

[praveksharma]

Thank you for getting to this @aidenfoxivey!

I ran a cursory search on requirements.txt/requirements.in and found that pip-compile (from pip-tools) translates the handwritten requirements.in to a version pinned requirements.txt. I am not certain that is the workflow that was user prior to this PR but as I understand it, the workflow in this PR is certainly different. Could you please explain the workflow for how a user would update a dependency once this PR is merged?

This follows the Nix flake model

Does this mean you're using nix to manage python dependencies instead of pip-tools?

Also, although /scripts/copy_from_upstream/requirements.* are useful for developers, these are not the files which track python dependencies in CI. I believe @h2parson looked into this recently; there might be other locations in .github/workflows and in the ci-containers repo. Hayden, could you please have a look and confirm if there are any other files which also track python dependencies?

[h2parson]

I believe that when updating the requirements for SLH DSA I took the following steps (in addition to updating the files Pravek mentioned):

-Added the name of the pip requirement to .github/workflows/requirements.in

liboqs/.github/workflows/requirements.in

Line 9 in f802330

requests==2.32.4

-Ran the command "pip-compile --generate-hashes --output-file=requirements.txt requirements.inpip-compile --generate-hashes --output-file=requirements.txt requirements.in" to populate .github/workflows/requirements.txt

-Then add the following line in the CI containers repo like so
https://github.com/open-quantum-safe/ci-containers/blob/530d6d247e4326c0ff4b3297612906ad9cfb27fa/ubuntu-latest/Dockerfile#L62

[aidenfoxivey]

Could you please explain the workflow for how a user would update a dependency once this PR is merged?

A user can run pip-compile --upgrade to update the dependencies further.

Does this mean you're using nix to manage python dependencies instead of pip-tools?

Sorry, I was vague here. I mean that there is a lock file and a requirement file. The lock file is just "liboqs at commit foobarbaz uses this version of the python package".

My perspective is that unless the workflow depends on a specific version of a python package, the requirements.in file should not be pinned.

If you do pin requirements.in, this means that a user running pip-compile --upgrade will not actually get an updated requirements.txt, since the requirements file itself is pinned, instead of just the lock file.

[praveksharma]

Thanks for the explanation @aidenfoxivey, I think looks good to go if you're certain this the only place Jinja needs updating.

[aidenfoxivey]

@praveksharma

~/s/liboqs % rg jinja
scripts/copy_from_upstream/copy_from_upstream.py
8:import jinja2
85:        contents = jinja2.Template(template).render(f)
90:        contents = jinja2.Template(template).render(f)
96:    contents = jinja2.Template(template).render({'instructions': instructions})
111:        contents = preamble + identifier_start + jinja2.Template(template).render(
126:    contents = preamble + identifier_start + jinja2.Template(template).render(f) + postamble

scripts/copy_from_upstream/requirements.txt
15:jinja2==3.1.6
24:    #   jinja2

From what I can tell this is the only use of Jinja in the repo!

[dstebila]

I think it is good practice to have the hashes of the packages here to reduce the risk of supply chain attacks.

[aidenfoxivey]

good call - I just fixed it!

[aidenfoxivey]

.

[aidenfoxivey]

good call - I just fixed it!

[dstebila]

@aidenfoxivey We now have some merge conflicts here, are you able to resolve?

[aidenfoxivey]

@aidenfoxivey We now have some merge conflicts here, are you able to resolve?

Should be fixed.