You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working with @karannewatia on a project written in Fabric, I've noticed that there are some overly restrictive labels for various data structures in the fabricated.util package.
Another place this shows up is the begin label of add: https://github.com/apl-cornell/fabric/blob/master/src/lib/collections/src/fabricated/util/AbstractList.fab#L61. Here, there appears to be an assumption that the code calling the add method should be running with a PC label that allows for modifying the item being added. This is overly restrictive: there are plenty of reasons to allow a list of elements that everyone can read but cannot write!
I believe we need to add more test cases for using these structures with structures labeled differently from their contents to determine whether the labels are flexible enough for reasonable use cases.
The text was updated successfully, but these errors were encountered:
While working with @karannewatia on a project written in Fabric, I've noticed that there are some overly restrictive labels for various data structures in the
fabricated.util
package.As a simple example,
ArrayList
and otherList
s seem to assume that the label on the contents (the label parameterL
) should also be the label on theList
's size: https://github.com/apl-cornell/fabric/blob/master/src/lib/collections/src/fabricated/util/ArrayList.fab#L131. This and other related issues make it so that aList
is generally required to be of the same confidentiality as the contents it holds.Another place this shows up is the begin label of
add
: https://github.com/apl-cornell/fabric/blob/master/src/lib/collections/src/fabricated/util/AbstractList.fab#L61. Here, there appears to be an assumption that the code calling theadd
method should be running with a PC label that allows for modifying the item being added. This is overly restrictive: there are plenty of reasons to allow a list of elements that everyone can read but cannot write!I believe we need to add more test cases for using these structures with structures labeled differently from their contents to determine whether the labels are flexible enough for reasonable use cases.
The text was updated successfully, but these errors were encountered: