symlink(2) is a very dumb syscall, and allows you to put any damn value
you please inside a symlink. In addition, spaces are valid path
characters which causes issues with keyword parsing. So use Vis() and
Unvis() to safely store an encoded version of the path.
This also adds a cli test for this behaviour.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This is part of a patchset that refactors all of the checking logic into
comparison operations. Essentially, provide a Compare(...) function that
allows for two different manifests to be compared. Extra and missing
entries are supported in addition to the standard modified entry, and by
implementing as a manifest comparison there is no double-scanning of the
manifest source.
The main annoyance is that we have to also include tar_time handling,
which has not been abstracted inside keywords.go. This is a bit ugly
right now, but works fine for the moment.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Previously, the time generation code would inexplicably drop parts of
the nanotime -- potentially causing validation to succeed when it should
fail. This was probably do to a bug in the remainder logic, but instead
we should be using .Nanosecond() anyway.
After changing the time of a file with a test case like this:
// Change the time to something known with nanosec != 0.
chtime := time.Unix(100, 987654321)
if err := os.Chtimes("somefile", chtime, chtime); err != nil {
// panic
}
timeKeywordFunc() would return the wrong value (time=100.000000021).
This fixes the issue and adds a test case.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
BSD file's support "flags". These have some similarity with xattr, but
for specific features, rather than general purpose key/values.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Previously, the symlink size reported by a archive/tar header
was 0. This is incorrect, as the size of a symlink should be
the size of its contents, which is just the path to where
the symlink points to. Thus, the size of this file would just
be len(Linkname).
Signed-off-by: Stephen Chung <schung@redhat.com>
Currently, if you create a manifest with, say 'sha1', and another
manifest with 'sha1digest', gomtree will produce different output
with regard to the keyword name. I.e, `sha1=[...]` vs. `sha1digest=[...]`.
If we want to use synonyms for keywords, as well as align with upstream mtree
output, specifying 'sha1' and 'sha1digest' should impact gomtree's
in the same way.
Signed-off-by: Stephen Chung <schung@redhat.com>
if the keyword "tar_time" is present when evaluating
an Entry, gomtree should use the tar_time when evaluating
the "time" keyword as well. This commit also adds a test that
makes sure "tar_time" wins against "time" if both are present.
Some minor clean-ups as well, such as checking if KeywordFunc[keyword]
actually retrieves a function.
Signed-off-by: Stephen Chung <schung@redhat.com>
Since the field in a tar header for each file only preserves seconds
precision, not nanosecond precision, let's handle it special. This will
allow for more custom case handling in Check()
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Originally only returning `Sys.linkname` when evaluating
a tar header's link field. We want it to be in the form of
keyword=value instead.
Signed-off-by: Stephen Chung <schung@redhat.com>
when creating a manifest from, or validating, a stream like a tar
archive, it requires thinking about some of the functions differently
than walking a directory tree.
This is the beginning of allowing for such features.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Fixes#7. Upper 3 bits are 'special' mode bits, and are not
included when calling info.Mode().Perm(). Need to mask
the info.Mode() with the corresponding mode bit defined
by the go library to see if these bits are set or not.
Signed-off-by: Stephen Chung <schung@redhat.com>
Setting up sibling and parent relationships for entries, so they can be
easier to walk.
Also, making "keyword=value" easier to parse. This helps filtering.
Both of these ready us for checking/validating a hierarchy.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Initially only on linux platform, but could accommodate BSDs as well.
The keyword is rather a prefix of the key. So xattr keyword will have a
prefix of "xattr." followed by a suffix of its namespace and name.
The value stored in the manifest is the SHA1 digest of the extended
attribute's data.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
