yes that's indeed a problem that needs to be dealt with.
That said, technically the getsum client doesn't download the file; it only fetches "$url.sha256" if present or a "SHA256SUMS" in the same directory and compares that with the one stored in the transparency log.
It follows a common pattern on release sites (such as major projects on github).
In other words getsum only ensures that the checksum file itself is immutable, and the checksum file then is used to ensure that bigger file also hasn't changed. The reason for that lies in the fact that getsum has a server side component (hosted on getsum.pub) that serves the Go modules fetched by the Go sumdb.
Big file downloaders tend to be more complicated than expected; progress bars, resuming downloads etc etc.
Perhaps getsum instead of downloading the file it could verify the file? E.g.:
That said, technically the getsum client doesn't download the file; it only fetches "$url.sha256" if present or a "SHA256SUMS" in the same directory and compares that with the one stored in the transparency log.
It follows a common pattern on release sites (such as major projects on github).
In other words getsum only ensures that the checksum file itself is immutable, and the checksum file then is used to ensure that bigger file also hasn't changed. The reason for that lies in the fact that getsum has a server side component (hosted on getsum.pub) that serves the Go modules fetched by the Go sumdb.
Thus, the correct instructions are:
Big file downloaders tend to be more complicated than expected; progress bars, resuming downloads etc etc. Perhaps getsum instead of downloading the file it could verify the file? E.g.: EDIT: just implemented the "-c" flag described above