kubernetes/kops · error
unhandled sha length for %q
Error message
unhandled sha length for %q
What it means
fileExtensionForSHA maps a hex hash string to its checksum-file extension: 40 hex chars -> .sha1, 64 -> .sha256. Any other length (short, truncated, or non-standard hash) returns this error, aborting the CopyFile task.
Source
Thrown at pkg/assets/assetcopy/copyfile.go:54
type CopyFile struct {
Name string
SourceFile string
TargetFile string
SHA string
VFSContext *vfs.VFSContext
Cluster *kops.Cluster
}
// fileExtensionForSHA returns the expected extension for the given hash
// If the hash length is not recognized, it returns an error.
func fileExtensionForSHA(sha string) (string, error) {
switch len(sha) {
case 40:
return ".sha1", nil
case 64:
return ".sha256", nil
default:
return "", fmt.Errorf("unhandled sha length for %q", sha)
}
}
func (e *CopyFile) Run() error {
ctx := context.TODO()
expectedSHA := strings.TrimSpace(e.SHA)
shaExtension, err := fileExtensionForSHA(expectedSHA)
if err != nil {
return err
}
targetSHAFile := e.TargetFile + shaExtension
targetSHABytes, err := e.VFSContext.ReadFile(targetSHAFile)
if err != nil {
if os.IsNotExist(err) {View on GitHub (pinned to 4c8573c808)
Solutions
- Inspect the sha in the error message and count its length to identify the wrong algorithm.
- Regenerate or fix the checksum source so it is sha1 (40 hex) or sha256 (64 hex).
- If the sha comes from a file repository .sha file, correct that file's contents.
- Re-run `kops get assets --copy` after the sha is corrected.
Example fix
// before (bad sha in repo) 5d41402abc4b2a76b9719d911017c592 file.tar.gz # md5, 32 chars // after 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed file.tar.gz # sha1, 40 chars
Defensive patterns
Strategy: validation
Validate before calling
sha := strings.TrimSpace(fileAsset.SHAValue.Hex())
if len(sha) != 40 && len(sha) != 64 {
return fmt.Errorf("asset sha must be sha1 (40) or sha256 (64) hex chars, got %d: %q", len(sha), sha)
} Prevention
- Publish only sha1/sha256 checksum files in your file repository
- Validate checksum files with `shasum -a 256 -c` before using them with kops
- Avoid md5/crc32 checksums in custom mirrors
- Sanity-check sha lengths in generated asset specs before running copy
When it happens
Trigger: A FileAsset whose SHAValue, when hex-encoded, is neither 40 nor 64 characters — e.g. SHAValue parsed from a corrupt or wrong-algorithm .sha file (md5=32 chars), an empty sha, or a truncated entry in the asset list.
Common situations: A custom file repository publishes checksum files generated with md5 or crc32; a manually edited assets spec contains a cut-off hash; a mirror serves a wrong .sha1 file that kops parses as the expected sha.
Related errors
- unable to parse sha: %q, %v
- unable to hash file %q downloaded: %v
- %s: %v
- not all assets copied successfully
- unable to transfer %q to %q: %v
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/8d31c3c42e9005b4.
Report an issue: GitHub.