Page MenuHomeFreeBSD

Upgrade security/py-pycryptodome{,x,-test-vectors}
AbandonedPublic

Authored by ngie on Mar 12 2023, 7:10 PM.
Tags
None
Referenced Files
F82212247: D39030.id118706.diff
Fri, Apr 26, 2:02 PM
F82212244: D39030.id.diff
Fri, Apr 26, 2:02 PM
F82212243: D39030.id118689.diff
Fri, Apr 26, 2:02 PM
F82212222: D39030.id118708.diff
Fri, Apr 26, 2:01 PM
F82212221: D39030.id118707.diff
Fri, Apr 26, 2:01 PM
F82207221: D39030.diff
Fri, Apr 26, 12:28 PM
Unknown Object (File)
Tue, Apr 23, 5:57 AM
Unknown Object (File)
Sat, Apr 6, 2:18 PM
Subscribers

Details

Reviewers
koobs
john_saltant.com
Group Reviewers
Python
Summary

This change upgrades py-pycryptodome from 3.16 to 3.17 and
py-pycryptodome-test-vectors from 1.0.10 to 1.0.12.

Minor adjustments were made to py-pycryptodome-test-vectors to
accomodate the fact that the upstream author no longer distributes .zip
files for the package.

PR: 270161
Signed-off-by: Enji Cooper <ngie@FreeBSD.org>

Test Plan

Ran the py-cryptodome tests and they passed:

$ make test
===>  Testing for py39-pycryptodome-3.17
===>   py39-pycryptodome-3.17 depends on package: py39-pycryptodome-test-vectors>=0 - found
===>   py39-pycryptodome-3.17 depends on file: /usr/local/bin/python3.9 - found
...
Ran 42562 tests in 111.879s

OK
$

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 50309
Build 47201: arc lint + arc unit

Event Timeline

ngie requested review of this revision.Mar 12 2023, 7:10 PM
ngie retitled this revision from Upgrade security/py-pycryptodome{,-test-vectors} to Upgrade security/py-pycryptodome{,x,-test-vectors}.Mar 12 2023, 7:27 PM

In addition to my per-line comments, I would suggest you run poudriere testport as an extra Q/A step, and record the FreeBSD version and architecture on which you successfully built and tested the update. See bug 268531 for an example of these practices.

security/py-pycryptodome-test-vectors/Makefile
2

Will the tests pass if the 1.0.12 test vectors are used with the 3.16.0 release? If not, maybe a dependency with minimum version spec would be appropriate?

14–15

Add support for Python 3.11 is included in the 3.17 release.

security/py-pycryptodome/Makefile
20

Add support for Python 3.11 was included in the 3.17 release.

This revision now requires changes to proceed.Mar 12 2023, 7:49 PM
ngie marked an inline comment as done.

Address comments re: 3.11 support.

ngie marked an inline comment as done.

Add a minimum required test-vectors version and a comment noting why the version is pinned.

ngie marked an inline comment as done.

Fix typo in previous revision regarding version pinning.

security/py-pycryptodome-test-vectors/Makefile
2

It's not mentioned explicitly, but I think it's potentially implied in the original package split.

From https://www.pycryptodome.org/src/changelog#id22 :

The bulk of the test vectors have been moved to the separate package pycryptodome-test-vectors. As result, packages pycryptodome and pycryptodomex become significantly smaller (from 14MB to 3MB).

Since they share the same GH development repo, I would assume it's best to keep the test-vectors reasonably in sync with the other packages.

This built successfully with poudriere on 13.1-RELEASE-p7/amd64. It also passed the exp-run according to @antoine: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270161#c1 .

John: do you have any more comments I should follow up on?

I would assume it's best to keep the test-vectors reasonably in sync with the other packages.

Given that upstream maintains independent versioning of the main project and the test vectors, it's not at all clear to me that this is a good assumption.

# It's best to keep the versions in sync to avoid introducing unwanted
# side-effects from mismatched package versions.
TEST_DEPENDS=	${PYTHON_PKGNAMEPREFIX}pycryptodome-test-vectors>=1.0.12:security/py-pycryptodome-test-vectors@${PY_FLAVOR}

If you're willing to try running the updated test vectors against the previous version and vice versa, I would do that and use the empirical results to inform whether a version constraint is warranted in the dependency. Otherwise, I think it's better to leave the version unconstrained.

The maintainer did this differently in a package update.