proganalysis / type-inference

Automatically exported from code.google.com/p/type-inference
Other
26 stars 23 forks source link

Should not disallow Secret parameter for non-private static methods #3

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
==Problem==

In order to have more straightforward type errors, we disallowed SECRET 
parameter for non-private static methods. Suppose we have the following static 
method:

static String escape(String url) {
  // some operations on url
  return url;
}

And we have the following constraint for newUrl1 = StringUtil.escape(oldUrl1):

oldUrl1 <: newUrl1 |> url;

If both oldUrl1 and newUrl are inferred as Secret, then url becomes {Secret, 
Poly}. 

In another statement like newUrl2 = StringUrl.escape(oldUrl2) where oldUrl2 is 
inferred as Secret while newUrl2 as Tainted. Clearly, we have a flow violation, 
but this won't be caught here, because `url` would become {Secret} and this 
above constraint still holds. Eventually, this type error would be caught at 
somewhere, but that is not good. 

Therefore, we disallowed parameters of non-private static method to be Secret. 
However, it leads to another problem when the parameter can be Secret. For 
example, 

public static bool find(String id) {
  @Secret String searchId = ...;
  if (id.equals(searchId) {
    ...
  }
}

Where disallowing `id` to be Secret would lead to an unnecessary type error. 

==Solution==

We should disallow such parameters to be Secret when we solve the constraints. 

Original issue reported on code.google.com by csweihu...@gmail.com on 6 Sep 2013 at 6:59

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Fixed in r18

Original comment by csweihu...@gmail.com on 7 Sep 2013 at 9:00