On 4/26/2016 10:27 AM, Johan Corveleyn wrote:
On Tue, Apr 26, 2016 at 9:11 AM, Branko Čibej <[email protected]> wrote:
On 26.04.2016 03:55, Stefan wrote:
Hi,
during the verification process of the tarballs I spotted that some
files have a different HeadURL and/or different timestamp records in
the files when comparing the archives with the content from the tagged
revisions.
Is that expected?
For instance win-tests.py in 1.8.16:
zip file:
# $HeadURL:
http://svn.apache.org/repos/asf/subversion/branches/1.8.x/win-tests.py $
tag:
# $HeadURL:
https://svn.apache.org/repos/asf/subversion/tags/1.8.16/win-tests.py $
Not that it worried me enough to not sign the zip-archives. Just a bit
wondering whether something is odd here.
Could be that the archive was built from the branch instead of from the
tag. Our release scripts allow for both, but releases really should be
cut from the tag. Could be an oversight ...
Thanks Brane, that explains that to me.
I always verify the contents (of the Windows zip files) against an
export of the tag and of the branch the tag was created from
(branches/1.8.x@1740329 in this case). I recursively diff both
directories against each other (gnu 'diff -r' inside cygwin actually),
and manually / diagonally verify the differences [1]. Indeed, HeadURL
and Date keywords can differ, but I ignore those.
Sounds like a reasonable improvement to my verification process (aka:
also verifying it against the branch-revision). Gonna add that for the
next time.
- HeadURL either pops up when diffing to the branch export or to the
tag export, but not both (indeed, it might be that usually it's
identical to the tag export, and not to the branch export -- maybe
it's reversed this time). Note: I perform the "export for content
verification" with the plain http URL, not https, since that's what
apparently is always used when creating the tarballs / zips.
Hm... Interesting point. I took the ones from https with the reason that
that way I have a slightly higher trust in what I download actually
being from the apache repository (i.e. man-in-the-middle-attack).
Certainly talking here about a very high level of security already
(especially since it's just verifying some built content (which is
signed by the build master) against some content from the web (i.e. data
in the repository)).
I guess I'll therefore stick with using the https-access here.
- Date pops up as a difference because of timezone issues. If I change
my own timezone (on Windows) to UTC, before executing the export, then
the Date keywords are identical, so they don't appear in the diff. It
has made me wonder if there was a way to influence the timezone used
for "Date" expansion during export, on Windows. I haven't found a way
to do that (only by changing the system timezone).
So if you export from http, and change your timezone to UTC before
exporting, then you get the least amount of unnecessary diff when
comparing the zip with the exported directories.
Thanks for the explanation - makes fully sense.
Other differences I ignore are:
- expected differences in svn_version.h (different when comparing to
the branch, should be identical when comparing with the tag).
- some symlinks vs. actual contents (consequence of running this
verification on Windows, I guess): for svnpubsub and svnwcsub (plus
nominate.pl in 1.9.x). In the exports you get "link svnwcsub.freebsd"
or something like that, in the zip you have the actual content of the
file.
- some generated files (only present in the zip, not in the tag / branch).
- and some directories / files are not in the zip (but they are in the
tag / branch), like the CONTRIB directory, which is expected too.
Yep, got the same and came to the same conclusion.
[1] See my usual statement when submitting my signature to the mailing list:
[[[
Contents of subversion-1.8.16.zip are identical to tags/1.8.16, and
to branches/1.8.x@1740329 (except for expected differences in svn_version.h
and svnpubsub and svnwcsub (symlinks vs. file contents), and
generated files).
]]]
which I borrowed and modified from Paul Burba's signature statements
back in the day ...
Good idea. If you won't mind, I'll borrow that template from your for my
next signing run. ;-)
--
Regards,
Stefan Hett
