On 25/05/17 00:28 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, May 24, 2017 at 05:22:43PM +0200, Jan Pokorný wrote:
> On 24/05/17 09:58 -0500, Jorge Gallegos wrote:
>> On Wed, May 24, 2017 at 04:19:05PM +0200, Jan Pokorný wrote:
>>> today, I've accidentally attested there are no stability guarantees
>>> with the on-demand archives from common git hosting sites when preparing
>>> a new pacemaker update, redownloading "spectool -s 0
>>> of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the
>> Are you pointing to a _tag_ (or as github likes to call them: release) ?
>> As far as I know tags can be re-created, isn't that what is happening
> Nope, the point is that nothing has changed in the codebase or, for
> that matter, tags. It must have been GitHub that changed how its
> equivalent of "git archive" behaves.
>>> hashes, which (surprisingly to me) didn't match (they were at any
>>> test in the past). Then I looked at the adiff output:
>>>> diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac
>>>> --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09
>>>> +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09
>>>> @@ -1159,7 +1159,7 @@
>>>> AC_PATH_PROGS(GIT, git false)
>>>> AC_MSG_CHECKING(build version)
>>>> if test != ":%h$"; then
>>>> AC_MSG_RESULT(archive hash: )
>>> for configure.ac that indeed has export-subst git attribute set
>>> and the change itself arises from "$Format:%h$" substitution.
>>> This likely means GitHub was internally updated to use equivalent
>>> of git 2.11 feature of abbreviation length autoscaling within
>>> last 14 days.
>> This is the other bit that makes me think it was actually the
>> maintainers hand that moved this, I don't believe github does anything
>> special to the code once it's stored there. There is no way for github
>> to alter code afaik?
> Once more, see "git help archive", ATTRIBUTES section, export-subst
> in particular. That exactly stands for the varying part, which is
> implementation-specific, and GH implementation has apparently changed,
> leading to changed contents of numerous archives to be downloaded from
> that very point.
Well, the title of your mail implies that *any* archive changed.
Of course, any such archives can change bitwise in between two
arbitrary moments, simply because some variable in the archiving
process can change (is even file list linearization assuredly
stable?). I've left that, obvious for some, aspect aside in the email
body, because a changed content is what seems to be entirely new,
at least to me. It means that also alternative checksuming approaches
(zcat archive | sha512sum) are disqualified from the attempts to
deal with such instabilities.
What changed in fact is an archive with %h subst. But %h is
inherently unstable: when commits are added to the archive, git will
extend the generated abbreviation length to maintain uniqueness.
This is how the original git implementation was changed recently,
but it doesn't mean any implementation has to behave that way,
and who knows what these proprietary services use.
I think the error here is in relying on stability %h substitution
I'd say more broadly that the error is to rely on stability of
auto-generated archives as such. In that light, Colin's git-evtag
project looks appealing for upstreams that do not provide their own