Can golang package source with *no imports* be assumed “safe”? (AKA auditing golang with `grep import`)

<p>TL;DR- Can we audit golang file providing function supposed to have no side-effects with just <code>grep import</code>?</p> <p>Given golang source file, providing functions, structures, that does not import anything, can I assume that this package works with no other side-effects than within package scope, cpu and memory usage upon calls I make to it?</p> <p>Therefore that it is safe, in sense that I can expect (after consumption of cpu,memory for required computations) that all it will do will be returning computed results for given parameter in function calls?</p> <p>Giving more concrete exmaple: Assuming I have api/protocol specification, how I&#39;d like to interact with library, for sake of discussion, let it be <code>f takes string-&gt;string dictionary and returns new string-&gt;string dictionary</code>.</p> <p>Let&#39;s assume I&#39;d like to take given implementation of <code>f</code>, Can I just make test <code>grep import provider_of_f.go</code> and in case of zero &#34;import&#34; lines assume that all it does it returns dictionary, given dictionary, according to function prototype?</p> <p>Assumptions: let&#39;s assume no compiler bugs (and of course no wired hardware bugs).</p> <p>Originally posted here: <a href="https://security.stackexchange.com/q/177352/4077" rel="nofollow">https://security.stackexchange.com/q/177352/4077</a></p> <hr/>**评论：**<br/><br/>0xjnml: <pre><p>No. A package can have no imports but still do unsafe things using assembler code.</p> <p>Side note: <code>grep</code> won&#39;t help anyway, use <code>go list</code>.</p></pre>TheMerovius: <pre><p>There are also <a href="https://research.swtch.com/gorace" rel="nofollow">data races</a> which can be used to implement any unsafe operations you want.</p> <p>If you want to isolate Go code, use <a href="https://github.com/golang/go/wiki/NativeClient" rel="nofollow">nacl</a>, it&#39;s what the playground is running on.</p></pre>epiris: <pre><p>No matter what there is always a better solution than arbitrary code execution. This is a XY problem though given your description, since it is impossible to require code execution as you described it. This is because given the constraints of <strong>no imports</strong> and the function signature:</p> <pre><code>func F(map[string]string) map[string]string { ... } </code></pre> <p>F must use a deterministic algorithm, since it is a deterministic algorithm it can be represented in a finite state machine. Since it can be represented by a finite state machine it could be represented by a graph. Since it can be represented by a graph it may be represented by a structured encoding. So you could create a library that allows a user to give it source, and generate the encoded schema. This is actually a much simpler effort in Go than it sounds since the <a href="https://golang.org/pkg/go/" rel="nofollow">go</a> package provides a powerful set of libraries to prove the source meets your constraints. For example:</p> <p>Create your grammar:</p> <ul> <li>Declare your function as F(in, out map..) so you don&#39;t need to allow them to call the make() built in.</li> <li>Declare a numerical constant of Length that is always the size of the in param of F.</li> <li>Blacklist all statements and expressions.</li> <li>Allow string literals / constants / concatenation</li> <li>Allow a for statement in the form of for i := 0; i &lt; Length; i++</li> <li>Allow the minimal expressions with well defined bounds until you are satisfied.</li> <li>This has the benefit that you can allow call expressions that are safe, such as strings.HasSuffix()</li> </ul> <p>Now you can transform the AST into a FSM, this process will further prove the program is correct. From here you can serialize the program to run later, or if building ends up super cheap (probably will be) you can skip the work of serialization and only store the src and execute the FSM, i.e.:</p> <pre><code>func Build(src string) *FSM { } func (*FSM) Run(in map[string]string) (out map[string]string, err error) { ... } </code></pre> <p>It&#39;s more work sure, but under no case would I suggest you execute arbitrary code even under nacl, unless you understand all the potential attack vectors that remain. For example no matter what you set as upper bounds for system resources, the potential for exhaustion through busy loops or allocations will always be susceptible to denial of service. This is mitigated for golang.org because it lives within Google IP space so is protected by a 600 billion dollar tech giant. Attacking them is futile so they don&#39;t need to even quantify the risk of DDoS.</p></pre>tgulacsi: <pre><p>Just dump all the &#34;imported&#34; code into a file, rewrite the names, and use it. Packages gives you comfort, ease of reuse, but it&#39;s just code that can be copied and reused after all.</p></pre>TheMerovius: <pre><p>Not really. e.g. you can&#39;t copy <code>unsafe</code> or <code>runtime</code> and without that (or doing the equivalent stuff in assembler) you can&#39;t have any side-effects.</p> <p>Like, I agree that imports aren&#39;t much of a security feature, but copying the code alone isn&#39;t really a way to break it either.</p></pre>epiris: <pre><p>for {}</p></pre>