[FFmpeg-devel] Fix NTP time in RTCP SR packets
Mon Feb 18 21:51:25 CET 2008
On Mon, Feb 18, 2008 at 08:56:07PM +0100, Reimar D?ffinger wrote:
> On Mon, Feb 18, 2008 at 07:16:41PM +0100, Michael Niedermayer wrote:
> > On Mon, Feb 18, 2008 at 12:56:01PM +0100, Reimar D?ffinger wrote:
> > > On Mon, Feb 18, 2008 at 09:18:42AM +0100, Luca Abeni wrote:
> > > > Summing up, an "av_gettime_more_secure() based" solution is ok in a large
> > > > number of cases, but not always...
> > > > I believe the AVFMT_FLAG_USE_TIME flag can solve the problem, but I do not
> > > > know if it is overkilling. What do you think about it?
> > >
> > > Maybe it does not matter much in this server case, but in general I
> > > think a flag to distinguish between the "I want to keep as many
> > > information/features as possible" and "I want to create a file I'd like
> > > to publish (almost) anonymously" modes of operation would be desirable.
> > The max anonymity is always default, i just think you are overparanoid with
> > the time in the case of streaming. Its not as if this would be stored in a
> > file ...
> I mostly admitted to that, at least I intended to it.
> Nevertheless, the
> specification does not really require this information,
The part quoted said:
"A sender that has no notion of wallclock or elapsed time may set the NTP
timestamp to zero."
ffmpeg as a POSIX program, has a notion of wallclock and elapsed time thus
this statement does not really apply. It just says if you dont know X you
may set it to 0. It does not say you may set X to 0 as you see fit.
Thus if we set it to 0 we likely violate the spec, and as luca already
said it does cause problems in practice as well.
> so being able to
> suppress it might be helpful for testing as well.
> > Also iam curious, can you point at a concrete case where knowing the exact
> > time of a system would significantly weaken its security?
> How "concrete"?
> Probably the answer is "no".
> Though I know that some people have been stupidly using srand(time)
> for security-critical stuff
> (knowing exact time would only make it
> slightly easier to exploit though).
Yes, its like removing a wall a child could step over.
> And as I said you could like this easily detect systems with a
> completely wrong system clock (usually not easy to exploit either
> though, but at least you then know it is a system nobody looks after
A simple note in the docs, saying set your time correctly if you stream
RT*P should be enough here and that note should be there anyway ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel