[mythtv] Github tarball from commit can change

Craig Treleaven ctreleaven at cogeco.ca
Tue Sep 29 02:09:36 UTC 2015


> On Sep 28, 2015, at 11:40 AM, Alec Leamas <leamas.alec at gmail.com> wrote:
> 
> On 28/09/15 17:01, Craig Treleaven wrote:
>>> On Sep 28, 2015, at 9:19 AM, Alec Leamas <leamas.alec at gmail.com> wrote:
>>> 
>>> On 28/09/15 14:34, Stuart Auchterlonie wrote:
>>> 
>>>> Pulling the tar ball will always pull the latest and greatest.
>>>> Any change to fixes/0.27 will result in a different tarball to
>>>> the previous download.
>>>> 
>>>> There may be a way of telling it to pull at a specific commit,
>>>> but haven't looked at it
>>> 
>>> There is. See e. g.,
>>> 
>>> https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Hosting_Services
>> 
>> Thanks, Alec, that is what I am doing except that I just use the short hash (“e9b577d3”) rather than the 40-character full hash.  If I should be using the full hash, I can do that.
>> 
>> AIUI, this causes GitHub to deliver a compressed tarball of a snapshot of the project as of that commit.  GitHub creates these tarballs and caches them for some unknown length of time.  GitHub _should_ be able to re-create the tarball if the cached version is no longer available since the snapshot should be exactly the same.
> 
> As I understand this, github just uses git-archive(1) to retrieve the tarball. We have noted that they have the specific semantics described in the manpage about checking out a commit vs checking out a version/tag.
> 
>> My WAG is that the file that differs (‘EXPORTED_VERSION’) is generated by a git hook.  It may be that the hook works differently depending on whether the commit hash is the lastest in that branch or not.  I know almost nothing about such hooks, however, so I could be entirely wrong.
> 
> If so, I would be surprised if github is involved in this. As I understand it, EXPORTED_VERSION is a myth thing. I suppose anything is possible, but it should then be that someone has installed a hook on the github side. Unfortunately, this is above my paygrade :(
> 
> My understanding is that if you checkout the same commit (with a direct reference, not using any tag/version) you should get exactly the same files, checked by a hashsum. If you reference a tag the files should be the same but the modification dates are different.
> 
> So, someone has tampered with EXPORTED_VERSION. First question is if it's actually part of the archive or generated by myth, isn't it?
> 'git ls-files' or 'git log EXPORTED_VERSION' in a cloned copy should reveal that, I guess.
> 
> Actually, you could also run git-archive(1) directly from a clone as well. AFAICT, this is the same as pulling a copy from github.

I spleunked around a bit more.  The following commit by stuartm seems to have set up this hook (?) for when git archive is run:

https://github.com/MythTV/mythtv/commit/cc037a8804c3f260e33f5611272b192699927662

I don’t understand the process enough to say if this is the reason why we got a different archive Sep 25 v. Sep 17.  But the only difference is the EXPORTED_VERSION file which is somehow updated based on the ‘.gitattributes’ file.

Craig


More information about the mythtv-dev mailing list