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

  1. Re-download the release; a corrupted or maliciously crafted archive can trigger this
  2. Verify the release file on dist.ipfs.tech if the error persists
  3. 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.