Open LoupVaillant opened 3 years ago
Hi @LoupVaillant,
I stopped maintaining it since there was a mismatch between how platformio expects releases (namely the files tagged at a certain commit) vs the way monocypher was doing releases: an actual github release with nicely minted source files with some version flags set.
In the many parallel projects this one dropped a bit behind. My plan was to make a small script that would unpack that release zip and push that to this repo, and try to follow the monocypher repo in a steady way.
Cheers, Davy
For context: https://github.com/LoupVaillant/Monocypher/pull/132
That's unfortunate to have so many publish complication just because of this __git__
, editing this version by hand would simplify vastly the publishing process instead of packaging to tar.gz and then unpackage, unzip to a repo, commit there and publish to platform.io... the amount of CI process just to workaround this comment...
I'm happy updating the version that is referenced in this repo, but last time @LoupVaillant wasn't happy with the outcome in the platformio library.
I'm happy updating the version that is referenced in this repo, but last time @LoupVaillant wasn't happy with the outcome in the platformio library.
If you could, that would be great! π
From my user perspective, I don't mind about the __git__
comment. I know the version I'm using by looking at the deps in platformio.ini
At least I can confirm that monocypher works nicely with platformio with the version of this repo.
I'm happy updating the version that is referenced in this repo, but last time @LoupVaillant wasn't happy with the outcome in the platformio library.
I have since changed my mind βsomewhat.
The goal of the version number is to help users track which versions they are using when they copy & paste the files into their own source code (what I designed as the "common case"). If that tracking is performed by PlatformIO instead, that's not too bad. A potentially bigger problem is the test suite, (the repository doesn't have vectors.h
), but does PlatformIO has a way to run a test suite to begin with?
Alternatively, I could write a script that unpacks the .tar.gz and puts it in a Monocypher-Realeases repository. As I said in the other thread, it seems to me that several ecosystems like to point to git repositories instead of tarballs, not just PlatformIO. Maintaining that repository would help third parties write their own manifest files, and either point to, fork, or git-submodule the Monocypher-realeses repository. (My, I didn't think of submodules. That alone might be a compelling argument to set up Monocypher-realeases).
Would you use such a Monocypher-realeases repository if I created it?
Alternatively, I could write a script that unpacks the .tar.gz and puts it in a Monocypher-Realeases repository. As I said in the other thread, it seems to me that several ecosystems like to point to git repositories instead of tarballs, not just PlatformIO. Maintaining that repository would help third parties write their own manifest files, and either point to, fork, or git-submodule the Monocypher-realeses repository. (My, I didn't think of submodules. That alone might be a compelling argument to set up Monocypher-realeases).
Maybe even use github-actions to do it automatically on a release?
Would you use such a Monocypher-realeases repository if I created it?
Sure, just give me a ping where to point it too :) If possible, also have some example code in there (in directory /examples/
)?
PlatformIO instead, that's not too bad. A potentially bigger problem is the test suite, (the repository doesn't have vectors.h), but does PlatformIO has a way to run a test suite to begin with?
There is an entire part about testing within PlatformIO about I have never been using it so far.
I don't expect myself to run the unit tests of the library I'm using frankly, unless I'm starting to modify the library (but I would never modify a crypto library myself for sure π ). Another problem is that micro-controllers run at a much slower speed than our desktop machines, so tests that would take 1h on a desktop machine could take 1 day on a micro-controller.
Would you use such a Monocypher-realeases repository if I created it?
I would use it for sure if it's the only way to get a release. If it was my repo, I would try to make the repository more code generated up-front (e.g replace the __git__
manually when releasing) so that I don't have to maintain a separate repo for publishing it. I'm saying that because I already manage a good dozens of repos on GitHub, and it's a challenge/burden to follow all of them, so the less I have to manage additionals CIs && duplicated info, the more I'm happy π
but
Maybe even use github-actions to do it automatically on a release?
Yes I concur, github-actions is probably the easiest way to get this up-and-running.
Another problem is that micro-controllers run at a much slower speed than our desktop machines, so tests that would take 1h on a desktop machine could take 1 day on a micro-controller.
The entire test suite take less than a second on my laptop. They're designed to be very thorough, but they don't waste much time. Remove Argon2i (which shouldn't be used on micro-controllers to begin with), and it's even faster. Even with a 1000x slowdown, they would be bearable.
I would use it for sure if it's the only way to get a release.
Well, there are the tarballs too, but thanks.
If it was my repo, I would try to make the repository more code generated up-front (e.g replace the git manually when releasing) so that I don't have to maintain a separate repo for publishing it.
Well, I'm kind of fanatical about not versioning generated stuff, but I kinda gave up when implementing TIS-CI integration. As the other said "we all have principles, until shit goes to hell".
As for __git__
, there's quite a few of them:
$ grep -ro __git__
dist.sh:__git__
src/monocypher.c:__git__
src/optional/monocypher-ed25519.h:__git__
src/optional/monocypher-ed25519.c:__git__
src/monocypher.h:__git__
makefile:__git__
tests/formal-analysis/monocypher.c:__git__
tests/formal-analysis/monocypher-ed25519.h:__git__
tests/formal-analysis/monocypher-ed25519.c:__git__
tests/formal-analysis/monocypher.h:__git__
monocypher.pc:__git__
I've made many little mistakes with past releases, so I'm pretty adamant about automating everything I can. This is one of those times.
@DavyLandman, I'll set up Monocypher-releases as soon as I have some time. The examples/
folder unfortunately will have to wait: I know there's a dire need for it, but my work on protocols taught me that this is not a quick job, even for me who wrote the entire library. I'll start by updating Monocypher-Utils, which was from the beginning designed to act as an example to copy from.
The entire test suite take less than a second on my laptop. They're designed to be very thorough, but they don't waste much time. Remove Argon2i (which shouldn't be used on micro-controllers to begin with), and it's even faster. Even with a 1000x slowdown, they would be bearable.
Good to know π
Well, there are the tarballs too, but thanks.
Yeah I know π , but as I explained. I don't want to store tarballs in my github repo nor I find it amusing to setup all the dance of downloading/unziping/adding to my projects to get it compile. That's what PlatformIO is providing, with a single line change in a project, which is pretty nice. Maybe some corporate users are still going through tarballs these days, otherwise PlatformIO seems a lot more practical, even beyond small home projects.
@DavyLandman, I'll set up Monocypher-releases as soon as I have some time.
Cool, thanks!
Hi,
@xoofx just told me about this repository that bring PlatformIO support for Monocypher. That's great, thanks for the effort.
I just noticed that your version number is lagging behind. Monocypher is now at version 3.1.2. Very few things have changed, but there have been a number of important additions. If you could update that would be great.
Thanks, Loup.