github tarballs problematic?

github tarballs problematic?

[ng0]

I've just come across this post via https://pagure.io/pagure/issue/861
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UDZ2WKMTOE6J2M4K7PF5OWSSC4BAX2SH/

quote in almost full:

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 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. Hope this will be useful for some (e.g. fedora-review tool has a check to redownload and diff sources against SRPM content, IIRC).
-- 
ng0
OpenPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588

Re: github tarballs problematic?

[Ludovic Courtès]

Hi ng0,

ng0 <ng0@pragmatique.xyz> skribis:

> I've just come across this post via https://pagure.io/pagure/issue/861
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UDZ2WKMTOE6J2M4K7PF5OWSSC4BAX2SH/
>
> quote in almost full:
>
> 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 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. Hope this will be useful for some (e.g. fedora-review tool has a check to redownload and diff sources against SRPM content, IIRC).

Interesting.  IIUC this only affects projects that use this
“$Format:%h$” feature, right?  I wonder how widespread it is.

Thanks for the heads-up,
Ludo’.