TarArchive decompress fails when tar has broken relative symlinks

[davellas]

When using the TarArchive decompress function, if the input Tar file has broken symlinks inside, the decompression fails with error
failed to evaluate symlink

However sometimes these broken symlinks don't really have negative impacts.
One example of such tar archives are the releases of code-server https://github.com/coder/code-server/releases
Manually untarring these files work, but they are not possible to be untarred with packit.

Expected Behavior

It is possible to use the TarArchive packit functionality to untar files containing broken symlinks

Current Behavior

Untarring files with broken symlinks always result in error

Possible Solution

It would be good enough to have an option/flag to specify in order to ignore broken symlinks instead of just throwing an error.

Steps to Reproduce

1. download one of the code-server releases linked above
2. try to deliver/decompress it with packit

[robdimsdale]

Hey @davellas - this sounds like a reasonable request. We'll take a look and see what the best course of action is.

I see three options:

1. make packit always ignore broken symlinks
2. allow optional configuration to ignore broken symlinks (your suggestion)
3. decide that the current behavior is desirable and do nothing (unlikely, but just including it here for completeness)

We'll do some exploring and get back to you.

Out of curiosity, are you actually using packit to download the https://github.com/coder/code-server/releases tarball as part of a buildpack? Or is that just a convenient example to reproduce the failure?

[davellas]

Hi @robdimsdale,

thank you for answering so quickly!
I agree with those 3 options, and obviously would prefer even 1 or 2 :)
I feel that TarArchive should deviate from the common Tar behaviour only if really necessary, as that is the de facto standard.

To answer your question, yes, I encountered this error when I was trying to make a custom buildpack. I was using openvscode-server (https://github.com/gitpod-io/openvscode-server) and have packit download and manage the dependency for me, it worked really well.
When I switched to code-server I noticed the error in this issue unfortunately.
I also opened a ticket for code-server as I think that their release tar files should be cleaned up, however I still believe that if normal Tar can handle them correctly, so should packit.

[robdimsdale]

Oh cool, is your buildpack open-source? Do you have a link to it? It's always interesting to see what kinds of buildpacks the community is creating and what problems they solve!

[davellas]

Unfortunately it is not open source, I don't exclude it to become open source in the future but it is out of my control right now.

However it doesn't do much more than installing the above code-server and a bunch of extensions

[robdimsdale]

No worries!

[robdimsdale]

I downloaded a tarball release of code server e.g. this one, extracted it with tar -xf and then checked for broken symlinks with:

→ find ./code-server-4.9.1-linux-amd64 -type l -exec test ! -e {} \; -print
./code-server-4.9.1-linux-amd64/lib/vscode/extensions/node_modules/.bin/tsc
./code-server-4.9.1-linux-amd64/lib/vscode/extensions/node_modules/.bin/tsserver

(from this Stack Overflow post)

Which I then validated were broken by looking for the typescript/bin directory with:

→ ls -alh ./code-server-4.9.1-linux-amd64/lib/vscode/extensions/node_modules/typescript/
total 16K
drwxr-xr-x  3 ubuntu ubuntu 4.0K Dec 16 16:48 .
drwxr-xr-x  5 ubuntu ubuntu 4.0K Dec 16 16:48 ..
drwxr-xr-x 15 ubuntu ubuntu 4.0K Dec 16 16:48 lib
-rw-r--r--  1 ubuntu ubuntu 4.0K Dec 16 16:48 package.json

And we see that the symlinks are invalid because there is no typscript/bin directory.

I haven't tried to reproduce this with Packit yet, but assuming that this causes Packit to break, I think that the best course of action is to warn on broken symlinks (maybe via the debug logger) but not fail. I don't think we need to introduce configuration for this, given that tar silently ignores the broken symlinks. This is essentially the first option I laid out above, but with some logging to aid debugging of dependencies.