feat: Gateway.DeserializedResponses config flag

[hacdias]

Pair PR of ipfs/boxo#252.

I simply update Kubo to use the new configuration structure and I keep all the defaults of Kubo, that is, everything is a trusted gateway unless DeserializedResponses is set to false in the configuration. Also added a simple test to check if DeserializedResponses is honoured. Further tests can be found in Boxo.

Steps:

• Merge feat(gateway)!: deserialised responses turned off by default boxo#252
• Update here, approve, merge.

[lidel]

Could tweak the name/meaning in Kubo, and add OnlyTrustless to the config?
It is a pretty important feature: people who want to run public gateway but don't want to be responsible for phising etc could easily remove the risk by enabling this.

This way, we don't need to deal with migrations / changing default behavior in Kubo (OnlyTrustless being false by default), but allow people to opt-in if they want.

[Jorropo]

Also tests please ?

[hacdias]

@Jorropo I added a very simple test. Don't forget that most of this is tested in Boxo.

[Jorropo]

Don't forget that most of this is tested in Boxo.

We still want to check that the 2 lines of code plumbing the config to the boxo field are correct. 🙂

[Jorropo]

LGTM ty

[lidel]

TrustedMode → DeserializedResponses

See ipfs/boxo#252 (review) for details

[lidel]

I've switched this PR to the latest version from ipfs/boxo#252 (review).

Good overall, but we need better UX and regression tests for all config variants.

I know this is extra work, would not ask normally for this level of paranoia, but misconfiguration of this flag could expose potential Trustless Gateway operators to risks that come with hosting deserialized data – details below.

addressed

[lidel]

Thanks!

Switched to boxo main branch, added changelog and some tests, merging.