5 ms·
Consider removing autogenerated files from tarballs
- hbogert 2y agoI'll just do `git clone --depth 1 ..` in the future by default and forget about 'half-built' source releases
- deleted 2y ago[deleted]
- auguzanellato 2y agoThis problem could probably be avoided by having reproducible release artifacts generated by a public CI workflow
- throw0101c 2y agoIsn't this part of what the traditional (?) target of "make distclean" does? (Remove everything that ./configure generated.)
- wakawaka28 2y agoNote that `configure` is itself generated in many cases. Distclean should ideally be equivalent to `git clean -f` but without needing git.
- wakawaka28 2y agoDoesn't this mean you would have to extract the tarball to even compare it to what's in git? It's not going to be just one hash. Even git-generated tarballs are not guaranteed to be identical for the same commit, I think. The idea here is ok, but if you can't trust the people making releases of your project then you have critical issues. I know making releases seems like a chore that almost anyone can do, but it is so critical that it must be handled by trusted individuals. Everyone would ideally be trustworthy. But the point is, binary files cannot easily be reviewed and the simplicity of making a release gives people a false sense of security. If you're gonna allow untrusted people to make releases, you might as well give up on everything else you're doing to be secure, because it hardly matters. This is why we need reproducible builds too by the way. The less you have to trust, the better.
- rurban 2y agoNo configure? Sorry, no. Very few people are able to do sh autogen.sh or autoreconf -if; libtoolize
- voidz 2y agoThen that's what they will have to learn then isn't it?
- rurban 2y agoNo, we had those discussions forever. Also in the light recently again, with autotoolized github src tarball and zips unable to use.
- volf_ 2y agoYou could have `./configure` print a message saying to do exactly what you said.