https://codeberg.org/missionz3r0/GetZi
I found myself with dependencies that did not play well with zig fetch. I did not want to commit the file to my repository and while I could of written a shell script, that did appeal to me either. So, I cobbled this little project together.
Cool project. Small, unserious suggestion: your tagline could be
Stop trying to make fetch happen.
If that didn’t imply one should never use fetch, I’d love it.
Interesting idea.
If I could offer one small recommendation, perhaps include a step for validating the file integrity against a known MD5/SHA256 checksum?
If you were feeling really adventurous, you could also add support for extracting archives, though that may be going beyond the scope of your plans.
Please no MD5:
A 2013 attack by Xie Tao, Fanbao Liu, and Dengguo Feng breaks MD5 collision resistance in 2^18 time. This attack runs in less than a second on a regular computer.[2]
I’ve been considering it, as well as letting a person define get dependencies in build.zig.zon. But, then it’d just be zig fetch for files you don’t want to unpack. There’s already an accepted proposal for that. As well as a PR.
But I’m not completely against the idea of checksums, just not sure how I’d want to go about it. Especially as GetZi was originally meant to retrieve files that regularly change. So if you used a static SHA256, getting the file would fail forever-more.
Actually, I do this already but not in GetZi. GetZi was split out from another project which includes decompression.
Nothing really wrong with MD5 as long as you’re using it as a better-than-crc32 checksum, and not something related to security.
Verifying file integrity is in large part a security measure, though.
What is meant there is ‘cryptographically’ secure, that is, a hash function that an attacker can’t forge. If what is intended is ‘detection of file corruption due to wire errors’ then md5 should be fine. If you want to detect ‘evil man in the middle attacks’ then md5 is bad.
Now let’s consider our use case: tcp/ip and ftp already have wire error detection built-in. We therefore only care about ‘evil man in the middle attacks’. In that context, md5 is useless since at best it checks what tcp/ip and ftp already does, and at worse it might persuade the receiver that their can’t be MITM attacks.
I had a C# app that dealt with large number of strings and I started to run into issues with hash collisions from the default C# string hashing. Switching to MD5 was a good improvement. At the time SHA* was too slow. No security issues with this use case.