On Sun, Oct 16, 2016 at 01:43:24PM +0000, Jay wrote: > On Sat, Oct 15, 2016 at 10:44 PM Michael Niedermayer <mich...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
