ipfs/kubo · error
extracted binary exceeds maximum size of %d bytes
Error message
extracted binary exceeds maximum size of %d bytes
What it means
Size guard while extracting the ipfs binary from a release archive: the entry was read through a LimitReader of maxBinarySize+1 bytes and still exceeded maxBinarySize, so the archive entry is larger than any legitimate kubo binary.
Source
Thrown at core/commands/update.go:787
defer gzr.Close()
tr := tar.NewReader(gzr)
lookFor := "kubo/" + binName
for {
hdr, err := tr.Next()
if errors.Is(err, io.EOF) {
break
}
if err != nil {
return nil, err
}
if hdr.Name == lookFor {
result, readErr := io.ReadAll(io.LimitReader(tr, maxBinarySize+1))
if readErr != nil {
return nil, readErr
}
if int64(len(result)) > maxBinarySize {
return nil, fmt.Errorf("extracted binary exceeds maximum size of %d bytes", maxBinarySize)
}
return result, nil
}
}
return nil, fmt.Errorf("%s not found in tar.gz", lookFor)
}
func extractFromZip(data []byte, binName string) ([]byte, error) {
zr, err := zip.NewReader(bytes.NewReader(data), int64(len(data)))
if err != nil {
return nil, err
}
lookFor := "kubo/" + binName
for _, f := range zr.File {
if f.Name != lookFor {
continue
}View on GitHub (pinned to 329838acdf)
Solutions
- Re-download the release; a corrupted or maliciously crafted archive can trigger this
- Verify the release file on dist.ipfs.tech if the error persists
- Install the new binary manually from the official distribution
Defensive patterns
Strategy: validation
When it happens
Trigger: Thrown at core/commands/update.go:787 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of ipfs/kubo@329838acdf (2026-09-03).
Data as JSON: /api/errors/6dca09ca844915df.
Report an issue: GitHub.