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 pacemaker.spec" 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 here?
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 similar test in the past). Then I looked at the adiff output:
diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 @@ -1159,7 +1159,7 @@ AC_PATH_PROGS(GIT, git false) AC_MSG_CHECKING(build version)
-BUILD_VERSION=0459f40 +BUILD_VERSION=0459f40958 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 over time.
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 stable tarballs.
packaging@lists.fedoraproject.org