archive/tar: call to Next does not detect that stream is truncated

[dsnet]

Using go1.5

As part of fixing #12436, I discovered that just calling Next alone without manually reading the data causes it to not detect a truncated stream.

package main

import (
    "bytes"
    "encoding/hex"
    "fmt"
    "io"
    "io/ioutil"
)
import "archive/tar"

func main() {
    truncData, _ := hex.DecodeString(data)

    fmt.Println("Decode with manual discard:")
    tr := tar.NewReader(bytes.NewReader(truncData))
    for {
        _, err := tr.Next()
        if err == io.EOF {
            fmt.Println("STOP_NEXT:", err)
            break
        }
        if err != nil {
            fmt.Println("FAIL_NEXT:", err)
            break
        }
        if _, err := io.Copy(ioutil.Discard, tr); err != nil {
            fmt.Println("FAIL_READ:", err)
            break
        }
    }

    fmt.Println("\nDecode with automatic discard:")
    tr = tar.NewReader(bytes.NewReader(truncData))
    for {
        _, err := tr.Next()
        if err == io.EOF {
            fmt.Println("STOP_NEXT:", err)
            break
        }
        if err != nil {
            fmt.Println("FAIL_NEXT:", err)
            break
        }
        // Without manually consuming the data, the next
        // call to Next should automatically consume it,
        // realize that the stream is truncated and return 
        // an error. But it doesn't.
    }
}

// This is a truncated and invalid Tar file. GNU and BSD tar all reject this.
const data = "616161000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000000000000000000003030303036343400303030313735300030303031" +
    "373530003030303030303030303536003132353734303537323436003031" +
    "303431320020300000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000075737461722020007261777200" +
    "00000000000000000000000000000000000000000000000000000064736e" +
    "657400000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000000000000000000000000000000000000000000000000000000000000" +
    "000054686520717569636b2062726f776e20666f78206a756d706564206f" +
    "76657220746865206c617a7920646f672e"

Currently, this outputs:

Decode with manual discard:
FAIL_READ: unexpected EOF

Decode with automatic discard:
STOP_NEXT: EOF

It should output:

Decode with manual discard:
FAIL_READ: unexpected EOF

Decode with automatic discard:
FAIL_NEXT: unexpected EOF

@dsymonds, is this expected behavior, or should I fix this as well?

[dsymonds]

Yeah, sounds like a bug.

[gopherbot]

CL https://golang.org/cl/14623 mentions this issue.

[gopherbot]

CL https://golang.org/cl/15175 mentions this issue.