affaan-m/ECC · error

Nasiko archive is truncated.

Error message

Nasiko archive is truncated.

What it means

While walking the gunzipped tar in extractQualifiedTarGzip (scripts/lib/nasiko-release.js), each 512-byte header's octal size field is parsed and the entry's end offset (header + payload) is compared against the buffer length. If an entry claims more bytes than remain, the archive is truncated relative to its own headers and parsing stops with this error.

Source

Thrown at scripts/lib/nasiko-release.js:96

}

function extractQualifiedTarGzip(archiveBytes, expectedName) {
  let tar;
  try { tar = zlib.gunzipSync(archiveBytes, { maxOutputLength: MAX_BINARY_BYTES + 2048 }); }
  catch (_error) { throw new Error('Nasiko archive is invalid or exceeds the decompressed size limit.'); }
  let offset = 0;
  let binary = null;
  while (offset + 512 <= tar.length) {
    const header = tar.subarray(offset, offset + 512);
    if (header.every(byte => byte === 0)) break;
    const name = readTarString(header, 0, 100);
    const prefix = readTarString(header, 345, 155);
    const type = String.fromCharCode(header[156] || 48);
    const rawSize = readTarString(header, 124, 12).trim();
    const size = Number.parseInt(rawSize || '0', 8);
    const start = offset + 512;
    const end = start + size;
    if (!Number.isSafeInteger(size) || size < 0 || end > tar.length) throw new Error('Nasiko archive is truncated.');
    const payload = tar.subarray(start, end);
    const isBinary = !prefix && name === expectedName && (type === '0' || type === '\0');
    const isAppleDouble = !prefix && name === `._${expectedName}` && type === '0' && size <= 1024 * 1024;
    const isPaxMetadata = !prefix && name === `PaxHeader/${expectedName}` && type === 'x' && size <= 64 * 1024
      && !/(?:^|\n)(?:path|linkpath)=/i.test(payload.toString('utf8'));
    if (isBinary && !binary && size > 0 && size <= MAX_BINARY_BYTES) binary = Buffer.from(payload);
    else if (!isAppleDouble && !isPaxMetadata) throw new Error('Unsafe Nasiko archive: expected exactly one bounded regular binary file.');
    offset = start + Math.ceil(size / 512) * 512;
  }
  if (!binary) throw new Error('Unsafe Nasiko archive: expected exactly one bounded regular binary file.');
  return binary;
}

function fetchBytes(url, options = {}) {
  const parsed = new URL(url);
  if (parsed.origin !== REGISTRY_ORIGIN || parsed.protocol !== 'https:') return Promise.reject(new Error('Nasiko download origin is not allowed.'));
  const maxBytes = options.maxBytes || MAX_ARCHIVE_BYTES;
  return new Promise((resolve, reject) => {

View on GitHub (pinned to 06c5e118c4)

Solutions

  1. Re-run the install to fetch a fresh, complete layer
  2. Verify the artifact manually: download the layer, `gunzip` it, and run `tar -tvf` to confirm the tar itself is intact
  3. If you produce the archive, ensure sizes are correct zero-padded octal and the stream is fully flushed before digesting
Defensive patterns

Strategy: try-catch

Try / catch

try {
  await installNasiko({ version: 'v0.1.0' });
} catch (error) {
  if (/archive is truncated/.test(String(error.message))) {
    // A header claimed more payload bytes than the buffer holds. Re-fetch once;
    // if reproducible, inspect with `tar -tvf` after gunzip and report a
    // packaging defect upstream.
  }
  throw error;
}

Prevention

When it happens

Trigger: For any tar entry: start + size > tar.length, or a size field that parses to NaN/negative. Causes: the gzip stream was cut short but still inflated partially, the tar was assembled with a wrong size header, or bytes were dropped after decompression.

Common situations: Interrupted downloads that still passed digest checks because the digest was of a different (truncated) artifact than expected; hand-rolled tar generation with incorrect octal size padding; tools that append data after the two zero end-blocks misaligning the walk.

Related errors

AI-assisted analysis of affaan-m/ECC@06c5e118c4 (2026-08-18). Data as JSON: /api/errors/30470efec3f819fc. Report an issue: GitHub.