The aarch64 implementations for SPHINCS+ appear to have been pulled into liboqs by mistake in the process of #1420. They have, as far as I can tell, never been switched on. Nor do we advertise their availability in documentation. It would be a non-trivial effort to enable them, so this PR simply deletes the unused code. We can revisit the inclusion of ARM-optimized SPHINCS+ as part of #1894.
To guard against this happening in the future, I added a --delete (-d) option to copy_from_upstream.py. This option ensures a "clean" copy by deleting all subdirectories from upstream target directories (e.g., src/sig/sphincs) prior to running the copy logic. I switched this option on in CI so that we can catch a similar slip-up before merge in the future. I don't, however, recommend it for local use, as it has the potential to wipe out unsaved changes.
The actual deletion of the aarch64 code was done using the new copy_from_upstream option. Here's an example of CI failing because it detects the SPHINCS+ aarch64 code.
Fixes #1967.
[ ] Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
[ ] Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged.)
The aarch64 implementations for SPHINCS+ appear to have been pulled into liboqs by mistake in the process of #1420. They have, as far as I can tell, never been switched on. Nor do we advertise their availability in documentation. It would be a non-trivial effort to enable them, so this PR simply deletes the unused code. We can revisit the inclusion of ARM-optimized SPHINCS+ as part of #1894.
To guard against this happening in the future, I added a
--delete(-d) option tocopy_from_upstream.py. This option ensures a "clean" copy by deleting all subdirectories from upstream target directories (e.g.,src/sig/sphincs) prior to running the copy logic. I switched this option on in CI so that we can catch a similar slip-up before merge in the future. I don't, however, recommend it for local use, as it has the potential to wipe out unsaved changes.The actual deletion of the aarch64 code was done using the new copy_from_upstream option. Here's an example of CI failing because it detects the SPHINCS+ aarch64 code.
Fixes #1967.