goshs is a feature-rich single-binary file server for red teamers and developers. Prior to 2.1.5, the httpserver/handler.go sendFile handler opened files using a cleaned path but derived the authorization filename from raw req.URL.Path, so a trailing slash could bypass .goshs ACL-file protection and block-list checks. This issue is fixed in version 2.1.5.

Affected: Go: github.com/patrickhener/goshs/v2, Go: goshs.de/goshs/v2, Go: github.com/patrickhener/goshs, Go: goshs.de/goshs

## Summary

`sendFile` derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

## Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

``` GET /blocked/secret.txt -> 404 (control, correctly blocked) GET /blocked/secret.txt/ -> 200 + contents GET /blocked/.goshs/ -> 200, returns the ACL file itself, including the admin:$2a$... bcrypt hash ```

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

## Suggested fixes…