On 02/26/2017 12:49 AM, Mike Swanson wrote:
On Fri, 2017-02-24 at 16:01 -0500, Eli Schwartz wrote:
Congratulations, you have just won today's FUD award!
The goal, as I understood it, is to promote the practice of upstream developers (project maintainers, release managers, whomever) signing their code so that downstream users and packagers can verify that the source they receive is identical to what upstream wants to put out. For me, trusting the "generate an archive" to a third party is in opposition of promoting good practice. I don't care if GitHub is good today, they may not be good tomorrow, and if an upstream gets cozy to the idea of "just download the GitHub archive" to sign off a release, they open themselves up to a world of hurt when GitHub (or anyone successfully pulling off a MITM attack -- unlikely with HTTPS, but not entirely impossible) starts messing with those archives, inserting/changing things not supposed to be there.
I do believe there is a healthy amount of uncertainty and doubt to take here. It's great that GitHub generates archives today that are identical to git-archive's own files. It may not always be the case.
For everyone else on this thread, what that Wiki *really* said, is:
4. Go back to your "Releases" section and download the tarball mysoftware-0.4.tar.gz automatically generated by GitHub. Verify that the tarball contains exactly the same data as the git repository.
The wiki also skimmed over exactly how to do this. "diff -r", comparing checksums from git-archive, diffoscope?
Which presumably implies that your complete and utter FUD regarding 'trusting the "generate an archive" to a third party' is, well, FUD. You just admitted that they (Debian Wiki) didn't actually say that, so why did you just try confusing the issue *again*? As for "exactly how to do this", I didn't realize there were so many people out there who both don't know how to compare a set of files, and cannot figure out how to google it. But those people should definitely not be trusted to write software if they fail at *both*, and anyway feel free to improve the Debian wiki if you really think this kind of extra-redundant redundancy is vital. I still maintain that accusing that page of offering "bad advice" is unmitigated FUD, but whatever...
I stopped reading after the prior point, but thanks for accusing me of plagiarism when their example doesn't even take the same route I did.
The fact that you copied their first command right down to the specific example software name/tag, is not negated by your further modification into a pipeline. Either way, you very clearly read the second half of that page, refused to acknowledge its existence, and then attempted to give the impression that your command-line-fu will save us all from the "bad advice" on that page. (And then you made the same *exact* implementation mistake they did, which would be, again, because you *copied* their implementation, mistake and all.)
Or accusing me of having it untested. I use the command all the time. It works.
(And if you're saying any upstream developer doesn't understand what a tag is, I'm sorry. It's irresponsible to not know how to use your own tooling. Learn git and get good at it.)
Well, you clearly aped the Debian Wiki's confusion over what a tag is, and I don't much care whether you know how the command works in general, blind copypasta is still untested. But I'll humor you... the reason it doesn't work is because while it will certainly create *a* tar.gz archive (and sign it), it certainly won't create the *right* tar.gz archive/sig. If your tag is "mysoftware-0.4",[1] and the repo name is presumably "mysoftware", then GitHub will use a combined prefix of "mysoftware-mysoftware-0.4" which will generate a totally different tarball. And if not (because your tag is named "0.4"), then `git archive` won't accept invalid object names like "mysoftware-0.4". Again, you clearly didn't test *this* command, however much you may have tested `git archive` in the general sense... or you would have gotten "invalid signature" errors when attempting to use the results. To recap: If you want to generate the same archive as GitHub will, for reproducibility/signing/whatever reasons... the correct way to do it is by generating a tar.gz archive and using `--prefix ${reponame}-${tag#v}` (The #v part is because yes, GitHub will strip out the "v" if you tag your releases as "v0.4") -- Eli Schwartz [1] It is a terrible minority practice to embed the software name in the release tag version name. So the Debian Wiki is actually offering bad advice, just not the bad advice you thought they were.