Obviously any broken symbolic link would cause an error if you try to compute a hash on it.
But there are more subtle issues as well. What if the link is valid but points to something outside of the package? If it points to something inside the package then you'll be computing the hash twice on the same file, which doesn't make a lot of sense.
The SPDX spec does not provide clear direction on this issue. Research pulled up this issue in the SPDX spec repository indicating that the community has not definitively settled on a single approach.
The most reasonable approach, which we will do here, is to exclude all symbolic links from the computation of the verification code and to put all of the links in the excluded file list. That at least makes it very clear to the reader how the code was computed.
Obviously any broken symbolic link would cause an error if you try to compute a hash on it.
But there are more subtle issues as well. What if the link is valid but points to something outside of the package? If it points to something inside the package then you'll be computing the hash twice on the same file, which doesn't make a lot of sense.
The SPDX spec does not provide clear direction on this issue. Research pulled up this issue in the SPDX spec repository indicating that the community has not definitively settled on a single approach.
The most reasonable approach, which we will do here, is to exclude all symbolic links from the computation of the verification code and to put all of the links in the excluded file list. That at least makes it very clear to the reader how the code was computed.