[FFmpeg-devel] [PATCH] RTSP: pass TLS args for RTSPS

[Michael Niedermayer]

On Sun, Oct 16, 2016 at 01:43:24PM +0000, Jay wrote:
> On Sat, Oct 15, 2016 at 10:44 PM Michael Niedermayer <michael at niedermayer.cc>
> wrote:
> 
> > On Sat, Oct 15, 2016 at 08:31:23PM +0000, Jay wrote:
> > > Thank you for the feedback. I have been trying to get RTSPS cert
> > validation
> > > incorporated for several weeks. I would greatly appreciate someone on the
> > > core team helping me guide this to completion. Please find your questions
> > > answered below.
> > >
> > > > the get_file_handle extensions should be in a spererate patch than
> > > > the rtsp changes
> > >
> > > I am process agnostic, but the RTSP changes are dependent on the TLS
> > > changes. There is a check for peer addr in RTSP that is based on the file
> > > descriptor.
> >
> > The TLS changes do not depend on the RTSP changes, they can be in a
> > seperate patch, applied before. TLS and RTSP are seperate "modules"
> > changes to them are cleaner if split
> >
> >
> OK.
> 
> 

> > >
> > > > also is it safe for all to use the input file handle that way ?
> > > > for example if one used a fifo the input state would not match the
> > > > relevant output neccessarily
> > >
> > > I do not think the peer addr check is necessary. My goal is a minimal
> > > patch, making RTSPS work with basic TLS options.
> >
> > Is that the only use of the file handle ?
> >
> >
> I took another look. The peer addr is used later to setup output streams
> and in the setup request. File handle is required for TLS+RTSP.
> 
> To fully answer the previous question, getpeername will not work on a fifo.
> It will fail with ENOTSOCK. In practice this should not be a problem. Named
> pipes are not supported by RTSP to my knowledge.

the code would never even know theres a fifo if there is one
just that there will be data in the fifo while the tcp socket it sees
has no new data for example.
The code cannot know of a fifo inside a TLS lib

See our UDP code for example, it uses a fifo and a background thread
if a tls lib does something similar then the data availability on
the tcp socket will not 1:1 match the data availability at the libs
decrypted output

this was my concern about the design, but i did not check if there are
any pathes where such data availability races can occur in relation to
this patchset ... (thats why iam asking ...)


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161016/c01aa196/attachment.sig>