[asterisk-bugs] [JIRA] (ASTERISK-24517) TLS support for Solaris, Ming and non-glibc Linux systems

[Timo Teräs (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=224819#comment-224819 ] 

Timo Teräs edited comment on ASTERISK-24517 at 2/9/15 7:36 AM:
---------------------------------------------------------------

I'm willing to start working on this now.

I looked at how widely the funfile() return FILE objects are used, and it looks like it is limited to http.c, manager.c, tcptls.c and res_http_websocket.c.

I'm wondering which of my options I should pursue:
1. remove "FILE f" and "int fd" on the related structs, and implement a custom "ast_file" or similar file io wrapping layer (unfortunately ast_filestream is too tied to audio files, channels and frames)
2. consider using socketpair() + thread + fdopen() to implement funopen like functionality via additional thread

Though, I would prefer probably options 1, as it's less resource intensive. Additionally the way you use both the file descriptor and FILE object interleaved is non-portable and not guaranteed to work as expected, especially since fd seems to be in non-blocking mode. To my understanding stdio is not required to work in non-blocking mode at all. Doing #1 would also clean up the code, as there is a lot of mixed of use of the fd (for polling) and FILE for reading/writing.

It also seems to be rather useless to use FILE in non-buffered mode - since the whole idea of stdio FILE is to provide buffering. Now it is used only to provide the abstraction in non-conforming ways. So this would justify removing FILE altogether and implementing the required abstraction internally. This would allow also removing the helper functions like ast_careful_fwrite() as the semantics could be written properly in the abstraction layer.


was (Author: fabled):
I'm willing to start working on this now.

I looked at how widely the funfile() return FILE objects are used, and it looks like it is limited to http.c, manager.c, tcptls.c and res_http_websocket.c.

I'm wondering which of my options I should pursue:
1. remove "FILE f" and "int fd" on the related structs, and implement a custom "ast_file" or similar file io wrapping layer (unfortunately ast_filestream is too tied to audio files, channels and frames)
2. consider using socketpair() + thread + fdopen() to implement funopen like functionality via additional thread

Though, I would prefer probably options 1, as it's less resource intensive. Additionally the way you use both the file descriptor and FILE object interleaved is non-portable and not guaranteed to work as expected, especially since fd seems to be in non-blocking mode. To my understanding stdio is not required to work in non-blocking mode at all. Doing #1 would also clean up the code, as there is a lot of mixed of use of the fd (for polling and 

> TLS support for Solaris, Ming and non-glibc Linux systems
> ---------------------------------------------------------
>
>                 Key: ASTERISK-24517
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24517
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Core/Portability
>    Affects Versions: 12.7.0, 13.0.0
>            Reporter: Timo Teräs
>            Assignee: Rusty Newton
>
> TLS is not working on systems without funopen(3) or fopencookie(3). This is a major portability issue as both functions are non-standard extensions.
> Per comment in ASTERISK-15490 I'm creating this improvement issue, as I don't see this bug being created earlier. ASTERISK-24515 is also related, but it is about *regression* of now defunct regular (non-TLS) connections. This bug is about adding the TLS-support for platforms that have never worked earlier.



--
This message was sent by Atlassian JIRA
(v6.2#6252)