basic support for SIP SHA-256 digest

[alberanid]

This PR introduces support for SHA-256 in SIP authentication.

What's missing:

• support for other algorithms specified in https://datatracker.ietf.org/doc/html/rfc8760
• support in src/httpauth/digest.c and (maybe?) src/turn/turnc.c

Also notice that right now it only works if OpenSSL is available; sha1.c doesn't support sha2 algorithms
and I'm not sure which of the various implementations is better to be included in Baresip.

An example of SIP server that supports SHA-256 digests is FlexiSIP.

Any help to improve this PR is welcome.

[sreimers]

Thanks, can you add a test case for sip_auth_encode() in retest (the PR title has to match)?

[alberanid]

Thanks, can you add a test case for sip_auth_encode() in retest (the PR title has to match)?

I gave it a try, but I fear I don't know enough of the Baresip internals to do a proper test.

In the attachment, a draft of implementation:
test_sip_auth_encode.txt

but it fails with:

  CC      build-x86_64/src/sip.o
src/sip.c: In function ‘test_sip_auth_encode’:
src/sip.c:878:8: warning: implicit declaration of function ‘sip_auth_encode’; did you mean ‘sip_addr_encode’? [-Wimplicit-function-declaration]
  878 |  err = sip_auth_encode(mb, auth, met, uri);
      |        ^~~~~~~~~~~~~~~
      |        sip_addr_encode
src/sip.c:878:8: warning: nested extern declaration of ‘sip_auth_encode’ [-Wnested-externs]

Since sip_auth_encode is not directly accessible.

Also, isn't it already covered by the test_sip_drequestf test?

Thanks.

[sreimers]

I have added a new test case baresip/retest@78ea4df
If algorithm is not specified, pl_strdup fails with EINVAL.

[sreimers]

@alberanid could you take a closer look at the failed test?

[alberanid]

@sreimers I hope to be able to do so in the next few weeks, but I can't guarantee any timeline at the moment.

[alberanid]

@alberanid could you take a closer look at the failed test?

See baresip/retest#39 - let me know is something else is needed. Thanks.

[alfredh]

is it possible to make the sha256 code into a separate PR ?

this way it is easier to test and to review ...

[alfredh]

hi @alberanid

it looks like your patch have some merge conflicts now.
is there any chance you could rebase on top of HEAD ?

[alberanid]

is there any chance you could rebase on top of HEAD ?

Unfortunately for the next few weeks I'll be really busy, but I'll try to do it as soon as possible.

[alfredh]

hi @alberanid

we have added wrappers for sha256:

#306 (comment)

so if you rebase your patch, the patch should be smaller :)

[alfredh]

hi @alberanid

if there is no progress here, I suggest to close the PR and open a new one when you have time to work on it.

I am happy to help with this

[alberanid]

hi @alfredh , yes, it's fine for me.

I'd like to merge our implementation, but right now I can't commit to any timeline. Feel free to use the code in this PR, in any case.