OK. I understand. I do not see anything like that in tls. On Sun, Oct 16, 2016 at 11:06 AM Michael Niedermayer <mich...@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 > <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 > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
