release: Release tarballs? How to sign releases?

[real-or-random]

Some things that popped up during the 0.2.0 release:

• Which tarball should we us as official release in the future?
  • github or
  • locally run git archive
  • make dist (diff should be just ci, and dotfiles)?
• Sign the tarball and add the sigs to the release?

Some considerations:

• github tarball is simply and easy to refer to by tag. Tarballs and links are created automatically
• git archive may be nice because it can be recreated locally. But then, if we want all maintainers to sign the tarball, we need to make sure it's deterministic.
• make dist does not seem to be a good choice. It's a bit silly to not include files like .gitignore and .cirrus.yml. I mean this is for devs of the library, you would want to have these files. And this method depends on the build system and we want to support more than one build system in the future. (And this would raise questions like "should the autotools tarball include cmake files?" in the future.)

[real-or-random]

github tarball is simply and easy to refer to by tag. Tarballs and links are created automatically

This is what we've done for 0.2.0 and 0.3.0.

Sign the tarball and add the sigs to the release?

We should consider this before the next release, and document the result in the process document. This will resolve this issue.

[hebasto]

What about using of CMake's CPack module:

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -229,6 +229,18 @@ if(SECP256K1_BUILD_EXAMPLES)
   add_subdirectory(examples)
 endif()
 
+set(CPACK_SOURCE_GENERATOR TBZ2 TGZ TXZ)
+set(CPACK_SOURCE_IGNORE_FILES
+  \\.git/
+  build/
+  ci/
+  \\.cirrus\\.yml
+  \\.gitattributes
+  \\.gitignore
+)
+set(CPACK_VERBATIM_VARIABLES YES)
+include(CPack)
+
 message("\n")
 message("secp256k1 configure summary")
 message("===========================")

?

Here is an example of usage:

$ cmake -S . -B build
$ cmake --build build --target package_source
$ ls -lh build/*Source.tar*
-rw-rw-r-- 1 hebasto hebasto 2.2M Apr 13 14:24 build/libsecp256k1-0.3.2-Source.tar.bz2
-rw-rw-r-- 1 hebasto hebasto 2.5M Apr 13 14:24 build/libsecp256k1-0.3.2-Source.tar.gz
-rw-rw-r-- 1 hebasto hebasto 2.2M Apr 13 14:24 build/libsecp256k1-0.3.2-Source.tar.xz

[real-or-random]

What about using of CMake's CPack module

I wasn't aware of that one. I think that's yet another option, but I don't think it's any better than git archive for our use case.

I lean towards keeping the github tarball. It's the same for everyone, and if we want to sign it, we can still verify its integrity by checking the files inside (okay, modulo malicious polyglots etc...)

[romanz]

Not sure, but https://github.com/orgs/community/discussions/45830 may be an issue...

[real-or-random]

Not sure, but github.com/orgs/community/discussions/45830 may be an issue...

Oh okay, this makes git archive much more interesting...

[hebasto]

Not sure, but github.com/orgs/community/discussions/45830 may be an issue...

Oh okay, this makes git archive much more interesting...

See #1287.

[real-or-random]

We should revisit this before the next release.

Whatever we decide on, we should update the release process to include a cursory manual inspection of the release tarball (are all aux/docs files present, etc.).