* Use uvx to run cibuildwheel on RISC-V
Oldest uvx mistake ever
Cache bust on arch
* Choose Python explicitly
* Simplify os/arch handling
* Add name
* Use official
* Cache only for local builds
* Zizmor is not happy
* ci: switch riscv64 from QEMU to native RISE runner
* fix: use RISE runner Python, skip setup-uv on riscv64
* fix: run cibuildwheel via pipx on riscv64 (bypass setup-python)
* ci: add riscv64 manylinux/musllinux wheels
Now that cibuildwheel and PyPI support riscv64, we can start building
riscv64 wheels.
Because there is no native riscv64 runner available, this PR adds a
QEMU-based riscv64 job to the cibuildwheel workflow.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
* Pin action
---------
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Co-authored-by: Hynek Schlawack <hs@ox.cx>
* Build free-threaded wheels, disable limited API there
Co-authored-by: Min RK <151929+minrk@users.noreply.github.com>
* Try installing libffi-dev on Linux
It's faling due to lack of includes. Presumably because the lack of cffi
wheels.
* Revert "Try installing libffi-dev on Linux"
Does not work.
* Merge
* Actually build FT
* support the free-threaded build of Python 3.14 (#93)
* support the free-threaded build of Python 3.14
* attempt to get 3.14t CI to run
* Add trove classifier
* Add changelog
* Add 3.14 trove classifier, too
---------
Co-authored-by: Hynek Schlawack <hs@ox.cx>
---------
Co-authored-by: Min RK <151929+minrk@users.noreply.github.com>
Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
* Add M1 builder, update cibuildwheel
* Oops
* Make pip shut up
* Try if we still have to silence warnings
* We do, but let's be more specific
* Nope, wasn't enough
* [pre-commit.ci] pre-commit autoupdate
updates:
- [github.com/psf/black: 21.11b1 → 21.12b0](https://github.com/psf/black/compare/21.11b1...21.12b0)
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
While not being a [Python Software Foundation](https://www.python.org/psf-landing/) project, everyone interacting in this project is expected to follow the [PSF Code of Conduct](https://policies.python.org/python.org/code-of-conduct/).
## Our Pledge
In general, this means that everyone is expected to be **open**, **considerate**, and **respectful** of others no matter what their position is within the project.
We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, caste, color, religion, or sexual
identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our
community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall
community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or advances of
any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email address,
without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
<mailto:hs@ox.cx>.
All complaints will be reviewed and investigated promptly and fairly.
We take Code of Conduct violations seriously, and will act to ensure our spaces are welcoming, inclusive, and professional environments to communicate in.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
If you need to raise a Code of Conduct report, you may do so privately by email to [Hynek Schlawack](mailto:hs@ox.cx).
## Enforcement Guidelines
Reports will be treated confidentially.
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of
actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or permanent
ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the
community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
Alternately you can make a [report to the Python Software Foundation](https://policies.python.org/python.org/code-of-conduct/Procedures-for-Reporting-Incidents/).
@ -30,21 +30,30 @@ Please report any harm to [Hynek Schlawack] in any way you find appropriate.
You can (and should) run our test suite using [*tox*].
However, you’ll probably want a more traditional environment as well.
We highly recommend to develop using the latest Python release because we try to take advantage of modern features whenever possible.
First create a [virtual environment](https://virtualenv.pypa.io/) so you don't break your system-wide Python installation.
It’s out of scope for this document to list all the ways to manage virtual environments in Python, but if you don’t already have a pet way, take some time to look at tools like [*direnv*](https://hynek.me/til/python-project-local-venvs/), [*virtualfish*](https://virtualfish.readthedocs.io/), and [*virtualenvwrapper*](https://virtualenvwrapper.readthedocs.io/).
First, create a [virtual environment](https://virtualenv.pypa.io/) so you don't break your system-wide Python installation.
We recommend using the Python version from the `.python-version-default` file in project's root directory.
Next, get an up to date checkout of the *argon2-cffi-bindings* repository:
If you're using [*direnv*](https://direnv.net), you can automate the creation of a virtual environment with the correct Python version by adding the following `.envrc` to the project root after you've cloned it to your computer:
If you're using tools that understand `.python-version` files like [*pyenv*](https://github.com/pyenv/pyenv) does, you can make it a link to the `.python-version-default` file.
---
Next, fork the repository on GitHub and get an up-to-date checkout:
@ -78,7 +87,7 @@ When working on `src/_argons_cffi_bindings/_ffi_build.py`, it makes sense to reg
---
To avoid committing code that violates our style guide, we strongly advise you to install [*pre-commit*] [^dev] hooks:
To avoid committing code that violates our style guide, we strongly encourage you to install [*pre-commit*] [^dev] hooks:
```console
$ pre-commit install
@ -90,8 +99,8 @@ You can also run them anytime (as our tox does) using:
$ pre-commit run --all-files
```
[^dev]: *pre-commit* should have been installed into your virtualenv automatically when you ran `pip install -e '.[dev]'` above.
If *pre-commit* is missing, your probably need to run `pip install -e '.[dev]'` again.
[^dev]: *pre-commit* should have been installed into your virtualenv automatically when you ran `python -Im pip install -e . --group dev` above.
If *pre-commit* is missing, your probably need to run `python -Im pip install -e . --group dev` again.
## Code
@ -110,7 +119,8 @@ $ pre-commit run --all-files
"""
```
- If you add or change public APIs, tag the docstring using `.. versionadded:: 16.0.0 WHAT` or `.. versionchanged:: 16.2.0 WHAT`.
- We use [*isort*](https://github.com/PyCQA/isort) to sort our imports, and we use [*Black*](https://github.com/psf/black) with line length of 79 characters to format our code.
- We use [Ruff](https://ruff.rs/) to sort our imports and format our code with a line length of 79 characters.
As long as you run our full [*tox*] suite before committing, or install our [*pre-commit*] hooks (ideally you'll do both – see [*Local Development Environment*](#local-development-environment) above), you won't have to spend any time on formatting your code at all.
If you don't, [CI] will catch it for you – but that seems like a waste of your time!
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Calendar Versioning](https://calver.org/).
The first digit of the version is the year, the second digit is incremented with each release, starting at 1 for each year.
The third digit is when we need to start branches for older releases (only for emergencies).
The **first number** of the version is the year.
The **second number** is incremented with each release, starting at 1 for each year.
The **third number** is when we need to start branches for older releases (only for emergencies).
There is very little activity on the bindings repo, so it doesn't make sense to carry around the build complexity of those ancient Python versions.
The [21.2.0 wheels on PyPI](https://pypi.org/project/argon2-cffi-bindings/21.2.0/) include support for Python 3.6 and are based on the same Argon2 version.
*argon2-cffi-bindings* provides low-level [*CFFI*](https://cffi.readthedocs.io/) bindings to the [*Argon2*] password hashing algorithm including a vendored version of them.
*argon2-cffi-bindings* provides low-level [CFFI](https://cffi.readthedocs.io/) bindings to the official implementation of the [Argon2] password hashing algorithm.
<!-- [[[cog
# Extract commit ID; refresh using `tox -e cog`
# Extract commit ID; refresh using `tox -e cog-render`
import subprocess
out = subprocess.check_output(["git", "submodule"], text=True)
id = out.strip().split(" ", 1)[0]
link = f'[**`{id[:7]}`**](https://github.com/P-H-C/phc-winner-argon2/commit/{id})'
print(f"The currently vendored *Argon2* commit ID is {link}.")
print(f"The currently vendored Argon2 commit ID is {link}.")
]]] -->
The currently vendored *Argon2* commit ID is [**`f57e61e`**](https://github.com/P-H-C/phc-winner-argon2/commit/f57e61e19229e23c4445b85494dbf7c07de721cb).
The currently vendored Argon2 commit ID is [**`f57e61e`**](https://github.com/P-H-C/phc-winner-argon2/commit/f57e61e19229e23c4445b85494dbf7c07de721cb).
<!-- [[[end]]] -->
> [!NOTE]
> If you want to hash passwords in an application, this package is **not** for you.
> Have a look at [*argon2-cffi*] with its high-level abstractions!
These bindings have been extracted from [*argon2-cffi*] and it remains its main consumer.
However, they may be used by other packages that want to use the *Argon2* library without dealing with C-related complexities.
However, they may be used by other packages that want to use the Argon2 library without dealing with C-related complexities.
## Usage
*argon2-cffi-bindings* is available from [PyPI](https://pypi.org/project/argon2-cffi-bindings/).
The provided *CFFI* bindings are compiled in API mode.
The provided CFFI bindings are compiled in API mode.
Best effort is given to provide binary wheels for as many platforms as possible.
### Disabling Vendored Code
A copy of [*Argon2*] is vendored and used by default, but can be disabled if *argon2-cffi-bindings* is installed using:
A copy of [Argon2] is vendored and used by default, but can be disabled if *argon2-cffi-bindings* is installed using:
Usually the build process tries to guess whether or not it should use [*SSE2*](https://en.wikipedia.org/wiki/SSE2)-optimized code (see [`_ffi_build.py`](https://github.com/hynek/argon2-cffi-bindings/blob/main/src/_argon2_cffi_bindings/_ffi_build.py) for details).
Usually the build process tries to guess whether or not it should use [SSE2](https://en.wikipedia.org/wiki/SSE2)-optimized code (see [`_ffi_build.py`](https://github.com/hynek/argon2-cffi-bindings/blob/main/src/_argon2_cffi_bindings/_ffi_build.py) for details).
This can go wrong and is problematic for cross-compiling.
Therefore you can use the `ARGON2_CFFI_USE_SSE2` environment variable to control the process:
@ -66,15 +71,16 @@ Please refer to [*cffi* documentation](https://cffi.readthedocs.io/en/latest/usi
The list of symbols that are provided can be found in the [`_ffi_build.py` file](https://github.com/hynek/argon2-cffi-bindings/blob/main/src/_argon2_cffi_bindings/_ffi_build.py).
*argon2-cffi-bindings* is available under the MIT license, available from [PyPI](https://pypi.org/project/argon2-cffi-bindings/), the source code and documentation can be found on [GitHub](https://github.com/hynek/argon2-cffi-bindings).
*argon2-cffi-bindings* targets Python 3.6 and later, including PyPy3.
@ -82,21 +88,29 @@ The list of symbols that are provided can be found in the [`_ffi_build.py` file]
*argon2-cffi-bindings* is written and maintained by [Hynek Schlawack](https://hynek.me/about/).
It is released under the [MIT license](https://github.com/hynek/argon2-cffi/blob/main/LICENSE>).
The development is kindly supported by [Variomedia AG](https://www.variomedia.de/).
The development is kindly supported by [Variomedia AG](https://www.variomedia.de/) and all my amazing [GitHub Sponsors](https://github.com/sponsors/hynek).
The authors of *Argon2* were very helpful to get the library to compile on ancient versions of Visual Studio for ancient versions of Python.
The authors of Argon2 were very helpful to get the library to compile on ancient versions of Visual Studio for ancient versions of Python.
The documentation quotes frequently in verbatim from the *Argon2* [paper](https://www.password-hashing.net/argon2-specs.pdf) to avoid mistakes by rephrasing.
The documentation quotes frequently in verbatim from the Argon2 [paper](https://www.password-hashing.net/argon2-specs.pdf) to avoid mistakes by rephrasing.
#### Vendored Code
The original *Argon2* repo can be found at <https://github.com/P-H-C/phc-winner-argon2/>.
The original Argon2 repo can be found at <https://github.com/P-H-C/phc-winner-argon2/>.
Except for the components listed below, the *Argon2* code in this repository is copyright (c) 2015 Daniel Dinu, Dmitry Khovratovich (main authors), Jean-Philippe Aumasson and Samuel Neves, and under [CC0] license.
Except for the components listed below, the Argon2 code in this repository is copyright (c) 2015 Daniel Dinu, Dmitry Khovratovich (main authors), Jean-Philippe Aumasson and Samuel Neves, and under [CC0] license.
The string encoding routines in src/encoding.c are copyright (c) 2015 Thomas Pornin, and under [CC0] license.
The string encoding routines in `src/encoding.c` are copyright (c) 2015 Thomas Pornin, and under [CC0] license.
The [*BLAKE2*](https://www.blake2.net) code in ``src/blake2/`` is copyright (c) Samuel Neves, 2013-2015, and under [CC0] license.
The [BLAKE2](https://www.blake2.net) code in `src/blake2/` is copyright (c) Samuel Neves, 2013-2015, and under [CC0] license.
Available as part of the [Tidelift Subscription](https://tidelift.com/?utm_source=lifter&utm_medium=referral&utm_campaign=hynek).
The maintainers of *argon2-cffi-bindings* and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open-source packages you use to build your applications.
Save time, reduce risk, and improve code health, while paying the maintainers of the exact packages you use.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
