[pacman-dev] [PATCH 0/2] Deprecate md5sums, show sha256sums as an example-by-default.

[Eli Schwartz]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20170226/843fd7f6/attachment.asc>