[FFmpeg-devel] Fix NTP time in RTCP SR packets

[Michael Niedermayer]

On Mon, Feb 18, 2008 at 08:56:07PM +0100, Reimar D?ffinger wrote:
> Hello,
> 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
> properly).

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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080218/645cb04b/attachment.pgp>