From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 5499746184 for ; Mon, 8 May 2023 17:11:03 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 569D468BD58; Mon, 8 May 2023 20:11:01 +0300 (EEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B5FFD68AE36 for ; Mon, 8 May 2023 20:10:54 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id C236B240003 for ; Mon, 8 May 2023 17:10:53 +0000 (UTC) Date: Mon, 8 May 2023 19:10:52 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230508171052.GT1391451@pb2> References: <20230506132503.9524-1-michael@niedermayer.cc> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 1/3] avformat/dashdec: fail on probing non mpd file extension X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============7384670838448415691==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============7384670838448415691== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/asd063ZXkk5ILJU" Content-Disposition: inline --/asd063ZXkk5ILJU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 08, 2023 at 04:05:40PM +0200, Tobias Rapp wrote: > On 08/05/2023 14:00, James Almer wrote: >=20 > > On 5/6/2023 10:25 AM, Michael Niedermayer wrote: > > > Its unexpected that a .avi or other "standard" file turns into a > > > playlist. > > > The goal of this patch is to avoid this unexpected behavior and possi= ble > > > privacy or security differences. > > >=20 > > > This is similar to the same change to hls > > >=20 > > > Signed-off-by: Michael Niedermayer > > > --- > > > =A0 libavformat/dashdec.c | 11 +++++++---- > > > =A0 1 file changed, 7 insertions(+), 4 deletions(-) > > >=20 > > > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c > > > index 29d4680c68..294e14150d 100644 > > > --- a/libavformat/dashdec.c > > > +++ b/libavformat/dashdec.c > > > @@ -2336,10 +2336,13 @@ static int dash_probe(const AVProbeData *p) > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "dash:profile:isoff-li= ve:2011") || > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "dash:profile:isoff-li= ve:2012") || > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "dash:profile:isoff-ma= in:2011") || > > > -=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "3GPP:PSS:profile:DASH1")) { > > > -=A0=A0=A0=A0=A0=A0=A0 return AVPROBE_SCORE_MAX; > > > -=A0=A0=A0 } > > > -=A0=A0=A0 if (av_stristr(p->buf, "dash:profile")) { > > > +=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "3GPP:PSS:profile:DASH1") || > > > +=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "dash:profile")) { > > > +=A0=A0=A0=A0=A0=A0=A0 if (!av_match_ext(p->filename, "mpd")) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 av_log(NULL, AV_LOG_ERROR, "Not de= tecting dash with non > > > standard extension\n"); > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return 0; > > > +=A0=A0=A0=A0=A0=A0=A0 } > > > + > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 return AVPROBE_SCORE_MAX; > > > =A0=A0=A0=A0=A0 } > >=20 > > Failing because it didn't match an extensions sort of goes against the > > point of probing, which even has a low score return value that's > > basically "it matched extension" as a sort of last resort. True > >=20 > > I'd say wrap this in a FF_COMPLIANCE_STRICT check (since i assume the > > spec does state mpd must be the extension), but i think we have no > > access to the AVFormatContext here? Thats not what this was intended to do. The whole idea is more like a user clicking on a readme.txt and not expecting that to downloade a list of URLs in it because it happens to be a valid list or URLs The problem here is the information available to the user suggests one thing but the action of the user of opening this file does something different, s= omething unexpected Thats not an issue if the difference is between 2 of 1000 similar formats but If the user believes the format cannot open random local and remote=20 URLs but is just a single monolithic file and then when she clicks it does open other things without the user even ever knowing. That is not ideal. >=20 > DASH is usually transferred over HTTP where file extensions are of minor > interest, the relevant type information is in the Mime-Type header. yes, true >=20 > I think we already have the "format_whitelist" API for applications that > want to restrict the list of formats when loading a file from untrusted > sources? [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. --/asd063ZXkk5ILJU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZFktFwAKCRBhHseHBAsP q4N5AJ0R7aIt/8nMKSaxcqpNWGs/sTkulACfVRJQU5eWoIa6QVEsBVUyZvYCPLo= =tS9x -----END PGP SIGNATURE----- --/asd063ZXkk5ILJU-- --===============7384670838448415691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============7384670838448415691==--