[erlang-questions] Avoiding Problems

[Edmond Begumisa]

On Sun, 16 Dec 2018 16:44:13 +1000, Michael Truog <mjtruog@REDACTED>  
wrote:

> On 12/14/18 7:52 AM, Edmond Begumisa wrote:
>>
>> WOW! This persistent_term module is very interesting [1], and already  
>> see many places in both my private and work codebase where it will be a  
>> godsend.
>>
>> However, I fear that there is going to be a lot of abuse.
>>
>> The temptation to use this as a global shared memory quick-and-dirty  
>> alternative to more elaborate better thought through designs is going  
>> to be too irresistible to many. The downside to many projects these  
>> days using rebar3 and the resulting deep dependencies, is that it's  
>> increasingly more difficult to avoid abuse instigated by others being  
>> introduced into your system (as we're seeing with quick-and-dirty NIFs).
>>
>> I foresee many projects looking at those warnings in the  
>> persistent_term docs and thinking "I've weighed it, and I think my  
>> project is 'special' enough to call put/1 and erase/1 a little more  
>> frequently than the documentation suggests, or have more entries than  
>> is recommended, and I have my reasons for not using ETS instead". With  
>> deep dependencies pulled down from github, this kind of thinking gets  
>> compounded and infectious.
>>
>> I wish there was a way of providing protections against that sort of  
>> thing. I can't think of one.
>
> For avoiding NIFs/port-drivers and other problems that relate to  
> security, I created https://github.com/okeuday/pest .  PEST is a static  
> analysis tool that looks for function calls it knows are problematic in  
> Erlang source code and provides information about where the problems  
> occur.  You could also use the PEST source code to identify other  
> function calls that should be avoided if you are concerned about  
> persistent_term.
>
> Best Regards,
> Michael
>

This is very helpful tool. You might want to drop the "security" in the  
description because it could be used as part of general code review.  
Thanks for this. I'm going to start using it.

I was thinking of something along the lines of persistent_term internally  
doing some sort of tracking at runtime and warning when it's being called  
in such a way that would degrade performance. And perhaps the NIF API too.  
Neither seem practical though.

- Edmond -

-- 
Using Opera's mail client: http://www.opera.com/mail/