pypi package

[gaardiolor]

Hi,

I think there is no pypi package? Would be nice if this could be added.

I do see a kyber-py package, but it's not yours it seems. The associated github page points to https://github.com/jack4818/kyber-py , but it redirects to your repo (!) If this is unwanted, it could violate https://peps.python.org/pep-0541/ and you could possibly raise a dispute. Maybe the one who added this package does not have malicious intent, and is open to transfer ownership to you.

If you could add it (even under a different name), and add the correct package name to the documentation, I think it would avoid confusion.

Thanks!

[GiacomoPope]

I think the owner of that library wanted kyber-py to be made and at the time I was not happy to do this so they did it without me / my permission.

It's something low priority for me right now, but yes, it would be good for this to be sorted out properly to stop outdated code being hosted on pypi

[GiacomoPope]

This is the old PR where I asked for it to not be made: #4

[GiacomoPope]

@MarcPartensky could you remove the pypi package please

[MarcPartensky]

Hello I removed the package.

[GiacomoPope]

OK -- so now my real motivation to make a package is if this really helps something for @tomato42 with your projects. Generally i still feel against it, but maybe we could then keep this fairly basic and move interoperability from your other PR into another repo?

[tomato42]

@GiacomoPope I mean, I see this package just like I see python-ecdsa (https://github.com/tlsfuzzer/python-ecdsa): a working, correct implementation useful for experimentation and testing, a practical explanation how the algorithm is working. But not supposed to be used in production, not secure against side channel attacks, etc.

Not sure what you mean by moving the interoperability into another repo... Why would having a way to read and write standard file formats for the algorithm not appropriate for this repo? I haven't updated the PRs because of the active discussions in IETF.

[GiacomoPope]

OK, let's wait for people to argue about in IETF and when things are stable we can make the pypi package. It doesnt seem urgent enough to upload things before that?

[gaardiolor]

Well, it could mean someone else is going to publish one again. It might be best to make it yourself, and use the versioning to show that it's alpha. 0.0.1a1 for example, see https://peps.python.org/pep-0440/ .

[tomato42]

I don't think we need to wait for standard file format to publish a package without support for writing files in standard format. We already have v1.0 release, let's use that.

[GiacomoPope]

Then I would like to make a PR with GitHub CLI which automatically updates the pypi package when a new tag is made. This seems the simplest way to sort this out. I'll do this when I have time, or I am happy for someone to start the work.

I have something similar, although with maturin, here: https://github.com/GiacomoPope/xoflib/blob/main/.github/workflows/CI.yml

[webknjaz]

I have something similar, although with maturin, here: GiacomoPope/xoflib@main/.github/workflows/CI.yml

That's an example of producing an entire matrix of platform-specific wheels. This project is pure-python and that part can be replaced with a single job calling python -Im build and saving the output as GHA artifacts. It also uses the old auth mechanism with long-living API tokens.

Today, the go-to way is to use short-lived OIDC-baked tokens that are auto-acquired with my pypi-publish action. It also produces digital attestations out of the box now. Here's my with an example workflow: https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/. We've also made sure that GitHub's own docs show a good example: https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-pypi (although, the example is probably pinned to an older version and needs updating). And their starter workflow is now better than in was for years.
Here's the PyPI-side doc: https://docs.pypi.org/trusted-publishers/.

[webknjaz]

@MarcPartensky could you remove the pypi package please

@GiacomoPope this was probably a bad idea. You should've asked to transfer the project to you. And maybe mark the releases as yanked. They are immutable, and you won't be able to reuse the same version numbers. It'll work for new version numbers that were never uploaded in the past. But in case of collisions, your uploads will fail (and this is usually pain to debug since it's unobvious with the old versions not visible on the UI anymore).

[GiacomoPope]

I happy to have feedback and changes made to the PR for the CI

As for the version numbers I'm not too worried as I think they only every uploaded once?

[webknjaz]

Oh, I see that you've already made #93 following the guide :)

[webknjaz]

As for the version numbers I'm not too worried as I think they only every uploaded once?

Sure. If you know what version number that was, just make sure to avoid it and maybe document somewhere.

[GiacomoPope]

I don't know what was used, no