tar archives lack a unified formal specification of what the format actually is. Though the USTAR and PAX formats specify that an archive should end with 2 blocks of zeros, the reality is that this specification came after the world has been doing all sorts of weird things. Most parsers treat the last 2 blocks of zeros as optional for maximal compatibility. This even goes for GNU tar, which also treats those blocks as optional. It just so happens that GNU tar has a special case where they fail on an empty file. On the other hand, BSD tar seems perfectly happy parsing an empty file.

Personally, I think we should keep the current behavior since an empty file should be valid supposing the trailing 2 blocks of zeros is considered optional. Also, turning an empty file into an error now is likely to break people who have come to depend on this behavior.

For other references, perl also treat empty file as valid:

perl -MArchive::Tar -e 'my $tar = Archive::Tar->new; $tar->read("./empty")'

python raise error:

python -c 'import tarfile; tarfile.TarFile("./empty")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/tarfile.py", line 1587, in __init__
    self.firstmember = self.next()
  File "/usr/lib/python2.7/tarfile.py", line 2371, in next
    raise ReadError("empty file")
tarfile.ReadError: empty file

I'm going to close this as working as intended:

1. Had we been implementing archive/tar from scratch perhaps we could have treated an empty file as invalid, but that has not be the case since Go 1.0. Changing it may break people relying on this property.
2. Many tar implementations also treat empty file as valid, so we are hardly the exception.