crazywhalecc
Add hash verification for SPC and dependencies
To implement package hash calculations and version locking, we might need to implement a manifest similar to other package management systems (like Homebrew), while pulling our regularly updated manifest version list and download URLs from static-php.dev or githubusercontent. This would be a near-destructive update for the current downloader and would add a significant amount of CI work.
I'm not sure I can do it alone, it would be a tremendous amount of work.
Much of what we do is essentially creating a package manager with static linking features, and I think we should also call the 3.0 project StaticPHP (Static package builder for PHP) instead of static-php-cli (Static-linked PHP builder for CLI).
But anyway the modules in 3.0 will be more independent, and even if we don't implement it for the time being, we can reduce our workload as a result :P
I think we should also call the 3.0 project StaticPHP
As long as we keep bin/spc, I'm fine with that 😅
As long as we keep bin/spc, I'm fine with that
Keep user interface compatibility is almost the simplest thing in version 3.0 though 🫣
I successfully implemented hash comparison and version display! If we don't maintain the manifest and continue using the existing structure of SPC, this might be the easiest approch.
What do you verify them against? I'd rather we don't have to maintain a huge list of hashes.
What do you verify them against? I'd rather we don't have to maintain a huge list of hashes.
I only implement php-src and all ghrel hash verification. The ghrel sha256 value could be fetched in api.github.com. We have many ghrel artifacts.
Currently, among download types, only ghrel has a unified hash verification method.
However, "verified" can have two meanings - checksum and signature. If we want to go further and calculate the signature, we can also use the same interface to overwrite the specified package.
But for version numbers, these are simply crawled from APIs of download types. It just records the version numbers, but the cache component will not use it for now.
I just added a sort of half-baked version of an updating command to the downloader. Also split up php version sources so we can handle having multiple downloaded. Build/extraction still always go into source/php-src because it would take too much refactoring otherwise and we always rebuilt php anyway.
Also split up php version sources so we can handle having multiple downloaded
3.0 will have downloading process in build:xx command and can with --dl-with-php option. I'm not sure if doing this in 2.0 is appropriate for your implementation.
Yeah I agree, I don't think it should be merged. I will split it off into a different branch, to implement more resourceful CI on the packages repository.