Re: wireguard-go relative imports

Re: wireguard-go relative imports

[Patrick Glandien]

(Pardon for previously sending an HTML response)

Dominik,

While relative imports are discouraged in Go, I could see it making it
sense in the context of highly sensitive code such as wireguard.
The go dependency system, including `go get`, don't guarantee as to
whether the code is authentic (e.g. signed).

This is a problem to the entire ecosystem of the language as recently
witnessed when someone replaced a commonly used go package hosted on
github after the user deleted his account: <https://redd.it/7vv9zz>.

I have not looked into the wireguard-go code very much, but if it's
merely meant to be a wireguard implementation in Go (not to be used as
a library) - then either relative import paths or top-level paths in
an isolated go workspace would be sensible and should not be changed
to the usual canonical URL imports.

=E2=80=94 Patrick Glandien

Re: wireguard-go relative imports

[Patrick Glandien]

[-- Attachment #1: Type: text/html, Size: 1016 bytes --]

wireguard-go relative imports

[Dominik Süß]

Can someone tell me the reason why the wireguard-go package uses
relative imports? This breaks go build when the working directory is
inside of the /home/thesuess/workspace and thus wireguard-go cannot be inst=
alled via go
get.

What are the upsides to this approach?
=