Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dsnet opened this issue Sep 9, 2015 · 3 comments
Closed

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

dsnet opened this issue Sep 9, 2015 · 3 comments
Milestone

Comments

@dsnet
Copy link
Member

dsnet commented Sep 9, 2015

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
Copy link
Contributor

dsymonds commented Sep 9, 2015

Yeah, sounds like a bug.

@ianlancetaylor ianlancetaylor added this to the Go1.6 milestone Sep 9, 2015
@gopherbot
Copy link

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

@gopherbot
Copy link

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

@golang golang locked and limited conversation to collaborators Nov 10, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants