Releases: CSCI-2390-Project/privacy-go
Releases · CSCI-2390-Project/privacy-go
Add support for interceptors
v1.99.0: Complete `isActionAllowed` function and include tests (#2)
This commit:
1. Reorganizes file names - all public methods now go into
`public_methods.go`, all private methods not related to policies goes
into `private_methods.go`, and all policy-related functions in
`policies.go`. Files used in test cases are now in `testing`.
2. Finishes implementing the `isActionAllowed` function. This currently
only supports iterating through the current call stack, but will pass on
all the desired testcases.
3. Adds tests to `policies_test.go` that test the behaviour of
`isActionAllowed`.
4. Added an example implementation of specifying function *ordering* as
opposed to just function names. This allows a lot of specificity and
control for the end user.
5. Implement loading in the policies file completely. By default, this
only loads in the policy file once on library import. It turns out to be
too complicated to refresh policy files after an interval, and honestly
its not actually all that important to have.
6. (Proposed) Drops support for allowing conditions to pass if message
fields have a certain decrypted attribute. The reason this is dropped is
because none of our publicly exported methods `PermissionedDecrypt`, etc.
actually have access to the *entire* message - just to the field we want
to encrypt. I'm also worried it'll just add room for weird conflicts
where an attribute doesn't want to be decrypted inside a function but we
decrypt it anyway just to check on its internals.
Another reason why I no longer think it's worth the effort to implement
this is because it's probably not going to be all that relevant if we
support function order whitelisting (as this commit implements). A user
can accomplish the same effect as `message.foo = X` for attribute `bar` by:
- Adding a policy rule `{allowed: true, if: "allowed_function"}` for
attribute `foo`
- Adding a policy rule `{allowed:true, if:
"function_called_only_if_foo_passes < allowed_function"}` for
attribute `bar`
- Writing code that checks if `message.GetFoo() == X` in
`allowed_function` and only then
doing `message.GetBar()` inside `function_called_only_if_foo_passes`
immediately after.
Basically, if the use case is supporting conditional processing, then
you can use function order whitelisting for the exact same effect and
with more security overall.
Finish policies
Complete `isActionAllowed` function and include tests (#2)
This commit:
1. Reorganizes file names - all public methods now go into
`public_methods.go`, all private methods not related to policies goes
into `private_methods.go`, and all policy-related functions in
`policies.go`. Files used in test cases are now in `testing`.
2. Finishes implementing the `isActionAllowed` function. This currently
only supports iterating through the current call stack, but will pass on
all the desired testcases.
3. Adds tests to `policies_test.go` that test the behaviour of
`isActionAllowed`.
4. Added an example implementation of specifying function *ordering* as
opposed to just function names. This allows a lot of specificity and
control for the end user.
5. Implement loading in the policies file completely. By default, this
only loads in the policy file once on library import. It turns out to be
too complicated to refresh policy files after an interval, and honestly
its not actually all that important to have.
6. (Proposed) Drops support for allowing conditions to pass if message
fields have a certain decrypted attribute. The reason this is dropped is
because none of our publicly exported methods `PermissionedDecrypt`, etc.
actually have access to the *entire* message - just to the field we want
to encrypt. I'm also worried it'll just add room for weird conflicts
where an attribute doesn't want to be decrypted inside a function but we
decrypt it anyway just to check on its internals.
Another reason why I no longer think it's worth the effort to implement
this is because it's probably not going to be all that relevant if we
support function order whitelisting (as this commit implements). A user
can accomplish the same effect as `message.foo = X` for attribute `bar` by:
- Adding a policy rule `{allowed: true, if: "allowed_function"}` for
attribute `foo`
- Adding a policy rule `{allowed:true, if:
"function_called_only_if_foo_passes < allowed_function"}` for
attribute `bar`
- Writing code that checks if `message.GetFoo() == X` in
`allowed_function` and only then
doing `message.GetBar()` inside `function_called_only_if_foo_passes`
immediately after.
Basically, if the use case is supporting conditional processing, then
you can use function order whitelisting for the exact same effect and
with more security overall.
Go mod
Update exported names
v1.0.6 Minor name change
Add recursive permissioning for message printing
v1.0.5 Include more permissioned methods
Add PermissionedDecrypt and PermissionedEncrypt
v1.0.4 Support permissioned decryption and encryption
Make identifiers private except Marshal and Unmarshal
v1.0.3 Make only Marshal and Unmarshal public
Upgrade dependencies again
v1.0.1 Upgrade dependencies
Release updated privacy.go
v1.0.0 Use the older Go code instead of our fork, avoids cycles