The signature protects against compromised mirrors, not just corruption
during transfer.
- Josh
On 30/8/2025 04:14, Jason Liu wrote:
Yes and no.
By default, rsync primarily relies on the file size and modification
timestamps to determine whether a particular file needs to be
(re-)synchronized. The -c/--checksum option in rsync runs checksums
during the initial scan of both ends, instead of relying on file size
and timestamp.
However, note that these checksums are only computed _prior_ to
performing any data transfers. So using -c cannot serve as a file
integrity check after the transfer has been performed. This is why,
whenever I want to backup or archive stuff using rsync, I run the same
rsync command _twice_, the first time using 'rsync -av', and then the
second time using 'rsync -avc'. If the checksumming the second time
doesn't result in any data being transferred, then you can essentially
treat the second rsync as a file integrity check.
P.S.: One other downside to using rsync's -c option is that it uses a
128-bit MD4 checksum, not MD5 or SHA.
--
Jason Liu
On Fri, Aug 29, 2025 at 1:55 PM Nils Breunese <[email protected]
<mailto:[email protected]>> wrote:
Ryan Carsten Schmidt <[email protected]
<mailto:[email protected]>> wrote:
> On Aug 29, 2025, at 11:01, Dave Allured - NOAA Affiliate wrote:
>
>> What is the problem with just going back to rsync and hosting
the uncompressed port tree? Then only the changed files would be
downloaded for port sync. You could also offer a complete tarball
available as an alternative, for new installs and full rebuilds. I
feel like I am missing something here.
>
> We switched to using a tarball so that its integrity could be
verified with a signature.
>
> https://github.com/macports/macports-base/
commit/476e4e15ff52ed1582cafa5d4be0476a6c05a5c1 <https://github.com/
macports/macports-base/commit/476e4e15ff52ed1582cafa5d4be0476a6c05a5c1>
AFAIK rsync can already do file-level integrity checksum checks, so
maybe there is no need for this?
Nils.
