[OpenSIPS-Devel] Re-organizing and de-duplicating digest code (related to the RFC8760 work)

Bogdan-Andrei Iancu bogdan at opensips.org
Thu Oct 8 08:55:13 EST 2020


Hi Max,

I see candidate 3) as the best. We already have this approach (under 
lib/ dir) for csv, path, registration related code.

The work you do looks very promising, thanks for your contribution on this.

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
OpenSIPS Summit 2020 online
   https://www.opensips.org/events/Summit-2020Distributed/

On 10/8/20 5:42 AM, Maxim Sobolev wrote:
> Hey folks,
>
> I am making good progress on implementing RFC8760 (SHA-XXX for digest 
> auth), basically the UAS side is functional and tested against our 
> Sippy Python implementation*.  Trying to organize and clean the code 
> as I go. Thanks to Liviu by the way for his help flushing some code 
> cleanups and fixes!
>
> The problem that I am hitting now is that we have digest computation 
> code duplicated in both modules (auth vs. uac_auth), which of course 
> is less than ideal from many perspectives (2x code to test, code 
> bloat, pain to add more algorithms etc).
>
> Now the question is what is the best way to deal with it. Couple of 
> options I have:
>
> 1. Make uas_auth use code from the auth module and add it as a 
> dependency. In general this seems to be the path the project takes to 
> solve this problem. The downside is perhaps some small performance 
> degradation as well some overhead to define and maintain API. Also 
> this method does not work for smallish bits and pieces, too 
> heavy-weight for an API.
>
> 2. Move code into the core. I think this is probably the wrong 
> direction, some application might not need auth at all. Just listing 
> it for completeness sake.
>
> 3. Move code into some kind of internal static library (say 
> "libospcore.a") and link both modules against that library. I really 
> like this approach since apart from some make-foo to get the library 
> compiled and linked with each of modules, the rest is pretty much 
> trivial. This avoids API/dependency overhead. With things like 
> link-time-optimization becoming de-facto standard in the next 2-3 
> years would give the best possible performance with very small size 
> overhead. Also works great for useful functions that are too small for 
> an API (for example function to convert binary into hex and the likes).
>
> Would love to hear what you guys think!
>
> -Max
> *) 
> https://github.com/OpenSIPS/opensips/compare/master...sippy:RFC8760?expand=1




More information about the Devel mailing list