archive/tar: test tarinsecurepath behavior for link targets
Clarify the Reader.Next documentation for tarinsecurepath=0 and add regression coverage for link targets.
The tarinsecurepath check reports ErrInsecurePath for non-local Header.Name values, but it does not validate Header.Linkname. That distinction is security-relevant for archive consumers that use archive/tar as part of extraction or policy enforcement: link targets need to be handled by the extractor's own filesystem policy.
This change preserves the current behavior. It makes the contract clearer by:
- rewording the Reader.Next comment so the ErrInsecurePath behavior reads directly;
- keeping the existing statement that only file names are validated, not link targets;
- adding tests for TypeLink and TypeSymlink entries with non-local link targets while GODEBUG=tarinsecurepath=0.
The new test confirms that the tarinsecurepath check applies to the entry name and not to the link target. This should help prevent future regressions or ambiguous assumptions around link handling in archive/tar readers.
Tests:
- go_bootstrap.exe test archive/tar
- go_bootstrap.exe test archive/...
Review requested. Please let me know if this should be adjusted to emphasize the test coverage only, or if there is a preferred wording for the Reader.Next documentation.
diff --git a/src/archive/tar/reader.go b/src/archive/tar/reader.go
index e426c72..dadb455 100644
--- a/src/archive/tar/reader.go
+++ b/src/archive/tar/reader.go
@@ -46,9 +46,9 @@
// At the end of the archive, Next returns the error io.EOF.
//
// If Next encounters a non-local file name (as defined by [filepath.IsLocal])
-// and the GODEBUG environment variable contains `tarinsecurepath=0`,
+// and the GODEBUG environment variable contains `tarinsecurepath=0`, Next
+// returns the header with an [ErrInsecurePath] error.
// Only file names are validated, not link targets.
-// Next returns the header with an [ErrInsecurePath] error.
// A future version of Go may introduce this behavior by default.
// Programs that want to accept non-local names can ignore
// the [ErrInsecurePath] error and use the returned header.
diff --git a/src/archive/tar/reader_test.go b/src/archive/tar/reader_test.go
index a324674..45b6938 100644
--- a/src/archive/tar/reader_test.go
+++ b/src/archive/tar/reader_test.go
@@ -1684,6 +1684,51 @@
}
}
+func TestInsecureLinknames(t *testing.T) {
+ t.Setenv("GODEBUG", "tarinsecurepath=0")
+ for _, test := range []struct {
+ name string
+ typeflag byte
+ linkname string
+ }{
+ {
+ name: "hardlink",
+ typeflag: TypeLink,
+ linkname: "../target",
+ },
+ {
+ name: "symlink",
+ typeflag: TypeSymlink,
+ linkname: "/target",
+ },
+ } {
+ var buf bytes.Buffer
+ tw := NewWriter(&buf)
+ if err := tw.WriteHeader(&Header{
+ Name: test.name,
+ Typeflag: test.typeflag,
+ Linkname: test.linkname,
+ }); err != nil {
+ t.Fatalf("WriteHeader(%s): %v", test.name, err)
+ }
+ if err := tw.Close(); err != nil {
+ t.Fatalf("Close(%s): %v", test.name, err)
+ }
+
+ tr := NewReader(&buf)
+ h, err := tr.Next()
+ if err != nil {
+ t.Fatalf("Next(%s): got err %v, want nil", test.name, err)
+ }
+ if h.Name != test.name {
+ t.Errorf("Next(%s): got name %q, want %q", test.name, h.Name, test.name)
+ }
+ if h.Linkname != test.linkname {
+ t.Errorf("Next(%s): got linkname %q, want %q", test.name, h.Linkname, test.linkname)
+ }
+ }
+}
+
func TestDisableInsecurePathCheck(t *testing.T) {
t.Setenv("GODEBUG", "tarinsecurepath=1")
var buf bytes.Buffer
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I spotted some possible problems with your PR:
1. You have a long 325 character line in the commit message body. Please add line breaks to long lines that should be wrapped. Lines in the commit message body should be wrapped at ~76 characters unless needed for things like URLs or tables. (Note: GitHub might render long lines as soft-wrapped, so double-check in the Gerrit commit message shown above.)
2. You usually need to reference a bug number for all but trivial or cosmetic fixes. For this repo, the format is usually 'Fixes #12345' or 'Updates #12345' at the end of the commit message. Should you have a bug reference?
Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Congratulations on opening your first change. Thank you for your contribution!
Next steps:
A maintainer will review your change and provide feedback. See
https://go.dev/doc/contribute#review for more info and tips to get your
patch through code review.
Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.
During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11 or adds a tag like "wait-release", it means that this CL will be
reviewed as part of the next development cycle. See https://go.dev/s/release
for more details.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I spotted some possible problems with your PR:
1. You have a long 325 character line in the commit message body. Please add line breaks to long lines that should be wrapped. Lines in the commit message body should be wrapped at ~76 characters unless needed for things like URLs or tables. (Note: GitHub might render long lines as soft-wrapped, so double-check in the Gerrit commit message shown above.)
2. You usually need to reference a bug number for all but trivial or cosmetic fixes. For this repo, the format is usually 'Fixes #12345' or 'Updates #12345' at the end of the commit message. Should you have a bug reference?Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
- [how to update commit messages](https://go.dev/wiki/GerritBot/#how-does-gerritbot-determine-the-final-commit-message) for PRs imported into Gerrit.
- the Go project's [conventions for commit messages](https://go.dev/doc/contribute#commit_messages) that you should follow.
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
Done. I updated the GitHub PR description to wrap the long line and added:
No issue: this is a documentation and test clarification for existing behavior.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |