Dominik,<div><div><br></div><div>While relative imports are discouraged in =
Go, I could see it making it sense in the context of highly sensitive code =
such as wireguard.</div><div>The go dependency system, including `go get`, =
don't guarantee as to whether the code is authentic (e.g. signed).=
</div><div><br></div><div>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&nbsp;after the user deleted his =
account:&nbsp;https://redd.it/7vv9zz</div><div><br></div><div>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.</div><div><br></div><br><signature>=E2=80=94 Patrick =
Glandien</signature><div id=3D"n1-quoted-text-marker"></div></div>