On 4/26/2016 10:27 AM, Johan Corveleyn wrote:
> On Tue, Apr 26, 2016 at 9:11 AM, Branko Čibej <brane_at_apache.org> wrote:
>> On 26.04.2016 03:55, Stefan wrote:
>>> 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
>>> 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 $
>>> # $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_at_1740329 in this case). I recursively diff both
> directories against each other (gnu 'diff -r' inside cygwin actually),
> and manually / diagonally verify the differences . 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
> - 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
> - 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.
>  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_at_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. ;-)
Received on 2016-04-26 11:46:05 CEST