Classic confinement request for golangci-lint

store-requests
1

golangci-lint has been strictly confined for a while now but it fails to run correctly under certain circumstances - in particular when scanning a project where it needs a go package that requires itself to be compiled against various host system headers - e.g. when running it against snapd itself we see the following errors as it was not able to fetch the go package github.com/gvalkov/golang-evdev as that requires itself to be compiled against the host installed linux/input.h header amongst others.

± golangci-lint run 
cmd/snap-bootstrap/triggerwatch/evdev.go:29:8: could not import github.com/gvalkov/golang-evdev (-: # github.com/gvalkov/golang-evdev
vendor/github.com/gvalkov/golang-evdev/device.go:139:9: undefined: ioctl
vendor/github.com/gvalkov/golang-evdev/device.go:139:38: undefined: EVIOCGBIT
vendor/github.com/gvalkov/golang-evdev/device.go:149:10: undefined: ioctl
vendor/github.com/gvalkov/golang-evdev/device.go:149:39: undefined: EVIOCGBIT
vendor/github.com/gvalkov/golang-evdev/device.go:180:15: undefined array length MAX_NAME_SIZE or missing type constraint
vendor/github.com/gvalkov/golang-evdev/device.go:181:15: undefined array length MAX_NAME_SIZE or missing type constraint
vendor/github.com/gvalkov/golang-evdev/device.go:183:9: undefined: ioctl
vendor/github.com/gvalkov/golang-evdev/device.go:183:38: undefined: EVIOCGID
vendor/github.com/gvalkov/golang-evdev/device.go:188:8: undefined: ioctl
vendor/github.com/gvalkov/golang-evdev/device.go:342:26: undefined array length MAX_NAME_SIZE or missing type constraint
vendor/github.com/gvalkov/golang-evdev/device.go:188:8: too many errors) (typecheck)
...

As such, this requires classic confinement as it needs to access arbitrary files from the host filesystem and fits within the supported category of compilers / debug tools.

2

Hi @alexmurray

It looks very reasonable to me and fits in the supported categories. Thus +1 from me for granting golangci-lint classic confinement

Thanks

3

Thanks @jslarraz - FYI unlike autoconnection requests etc, classic requests do not get voted on - but if a reviewer determines they meet the criteria then the normal process is to move to publisher vetting etc :wink:

4

Oh, thanks for the clarification @alexmurray ^^

Do you know if there is any specific reason for that? Classic is as powerful as any super privileged interface (if not more ). I feel that maybe granting classic should require the same voting process we have for auto-connection

5

The requirements for classic confinement are more clear-cut so there shouldn’t be a need to vote - either the request meets the requirements or not and so a single reviewer can assess that.

However, whilst that has been the way we have approached this in the past I am not opposed to changing the process to include voting etc if @reviewers feel this makes sense.

6

The requirements for classic are understood. Publisher is vetted. Granting use of classic. This is now live