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

[Jay]

OK. I understand. I do not see anything like that in tls.

On Sun, Oct 16, 2016 at 11:06 AM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>