BUG: docker-compose file with YAML directive breaking

[gabibguti]

Describe the bug
A docker-compose file with YAML directive seems to break the Pinned-Dependencies check.

Reproduction steps
Steps to reproduce the behavior:

1. Run Scorecard @4.10.2 for github.com/grpc/grpc: scorecard --repo=github.com/grpc/grpc
2. View that Pinned-Dependencies check ends in:

internal error: error parsing shell code: https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies
templates/examples/php/echo/base.Dockerfile.template:1:48
parameter expansion requires a literal

3. The problematic file/line is https://github.com/grpc/grpc/blob/master/templates/examples/php/echo/base.Dockerfile.template#L1

Expected behavior
I expected Scorecard to be able to parse docker-compose files with YAML directive.

Additional context
None.

[spencerschrock]

I'm guessing it's coming from here:

scorecard/checks/raw/shell_download_validate.go

Lines 957 to 962 in 1fb5960

	if err != nil {
	// Note: this is caught by internal caller and only printed
	// to avoid failing on shell scripts that our parser does not understand.
	// Example: https://github.com/openssl/openssl/blob/master/util/shlib_wrap.sh.in
	return sce.WithMessage(sce.ErrorShellParsing, err.Error())
	}

Based on the comment, I'm guessing we aren't ignoring the error everywhere we call it. But I haven't tracked it down.

[spencerschrock]

So we used to catch it here:

scorecard/checks/shell_download_validate.go

Lines 810 to 822 in a004ffb

	func validateShellFile(pathfn string, content []byte, dl checker.DetailLogger) (bool, error) {
	files := make(map[string]bool)
	r, err := validateShellFileAndRecord(pathfn, content, files, dl)
	if err != nil {
	if errors.Is(err, errInternalInvalidShellCode) {
	// Discard and print this particular error for now.
	dl.Debug(err.Error())
	} else {
	return r, err
	}
	}
	return r, nil
	}

Until it was removed by this large PR #1932

@laurentsimon any idea if this was an intentional removal?

[spencerschrock]

Crashing the whole Pinned-Dependencies check shouldn't be an issue anymore after #3515.
There's still a processing error, which gets logged, but this doesn't seem like a normal dockerfile so happy to close this one out.