[FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway

[Mark Gaiser]

Hi all,

On the IPFS side we do have a solution for that with CAR files, you can
read more about that here [1].
Within the scope of this ipfs gateway protocol handler there isn't a
solution yet to use CAR files, it is on our radar but still in the
discussion phase.

On the cURL side we had this same discussion with 2 possible solutions [2].
For completeness, i'll list them here in full too:

1. An error message that gives no example but instead points the user to
documentation on how to get it working.
=== cURL example
$ curl ipfs://bafkreicysg23kiwv34eg2d7qweipxwosdo2py4ldv42nbauguluen5v6am
Error: local gateway not found and/or IPFS_GATEWAY is not set
Learn how to run one: https://docs.ipfs.tech/install/command-line/
===

2. An error message that makes the user aware of IPFS and provides a
solution to get it working immediately.
=== cURL example
$ curl ipfs://bafkreicysg23kiwv34eg2d7qweipxwosdo2py4ldv42nbauguluen5v6am
Error: local gateway not found and/or IPFS_GATEWAY is not set.
Try: IPFS_GATEWAY=https://ipfs.io
or run your own: https://docs.ipfs.tech/install/command-line/
===

Within the cURL implementation we're going for point 1.
The same idea can very well apply to ffmpeg too. Different texts that match
the different context, but in the same spirit.

Now ffmpeg is a bit different here. First and foremost because it predates
the curl.
But also because the default fallback gateway was an explicitly requested
feature from the ffmpeg side to give an "it always works" feeling.
ffmpeg therefore has a fourth option: Do nothing and keep it as-is.

I'm very much looking forward to which approach is right for the ffmpeg
folks. I will provide a patch implementing that approach.
I'm specifically looking forward to a reply from Michael Niedermayer in
this context.

Best regards,
Mark Gaiser

[1] https://docs.ipfs.tech/reference/http/gateway/#trusted-vs-trustless
[2] https://github.com/curl/curl/pull/8805#issuecomment-1199427911

On Thu, Aug 11, 2022 at 2:08 PM Timo Rothenpieler <timo at rothenpieler.org>
wrote:

> On 11/08/2022 00:27, Derek Buitenhuis wrote:
> > A gateway can see everything, and we should not be shipping a hardcoded
> > default from a third party company; it's a security risk.
> >
> > Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
> > ---
> >   libavformat/ipfsgateway.c | 11 ++++-------
> >   1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
> > index 5a5178c563..907b61b017 100644
> > --- a/libavformat/ipfsgateway.c
> > +++ b/libavformat/ipfsgateway.c
> > @@ -240,13 +240,8 @@ static int translate_ipfs_to_http(URLContext *h,
> const char *uri, int flags, AVD
> >           ret = populate_ipfs_gateway(h);
> >
> >           if (ret < 1) {
> > -            // We fallback on dweb.link (managed by Protocol Labs).
> > -            snprintf(c->gateway_buffer, sizeof(c->gateway_buffer), "
> https://dweb.link");
> > -
> > -            av_log(h, AV_LOG_WARNING,
> > -                   "IPFS does not appear to be running. "
> > -                   "You’re now using the public gateway at
> dweb.link.\n");
> > -            av_log(h, AV_LOG_INFO,
> > +            av_log(h, AV_LOG_ERROR,
> > +                   "IPFS does not appear to be running.\n\n"
> >                      "Installing IPFS locally is recommended to "
> >                      "improve performance and reliability, "
> >                      "and not share all your activity with a single IPFS
> gateway.\n"
> > @@ -259,6 +254,8 @@ static int translate_ipfs_to_http(URLContext *h,
> const char *uri, int flags, AVD
> >                      "3. Define an $IPFS_PATH environment variable "
> >                      "and point it to the IPFS data path "
> >                      "- this is typically ~/.ipfs\n");
> > +            ret = AVERROR(EINVAL);
> > +            goto err;
> >           }
> >       }
> >
>
> ACK, hardcoding a public gateway is a huge NO from me.
> Also in string favour of backporting this to 5.1, since it should have
> never made it in there in the first place.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>