restrict depositFor to initiator

[adhusson]

No description provided.

[Rubilmax]

If we don't also enforce initiator to the withdrawal, the following scenario could happen:

1. whitelisted user wraps USDC to verUSDC, deposits verUSDC to vault
2. Transfer vault shares to non-whitelisted user
3. non-whitelisted user redeems vault shares then unwraps verUSDC to USDC to the bundler (hypothetically whitelisted)
4. non-whitelisted user transfers USDC to themselves

[MathisGD]

Interesting case. Note that in any case (even if we prevent this) this scenario could happen:

1. non-whitelisted transfers underlying to whitelisted
2. whitelisted user wraps and supply
3. transfer vault shares to non-whitelisted
4. transfer back vault shares to whiltelisted
5. whitelisted withdraws and sends back underlying

What I mean is that due to the fact that it's impossible to whitelist vault shares transfers, a malicious whiltelisted person could always make people profit from a vault with an whiltelisted underlying asset.

I'm not sure if we need to make a change to withdrawTo. @adhusson wdyt

EDIT: hardcoding the receiver wouldn't even fix this case

[adhusson]

I may be missing something. withdrawTo unwraps, so the unwrapped token will always be transferable to the initiator, whether he is whitelisted or not. ie the following can happen:

1. whitelisted user wraps USDC to verUSDC, deposits verUSDC to vault
2. Transfer vault shares to non-whitelisted user
3. non-whitelisted user redeems vault shares then unwraps verUSDC to USDC to himself (hypothetically whitelisted)
4. non-whitelisted user transfers USDC to themselves

The only way to prevent this would be to also force morphoWithdraw's receiver to be initiator.

[MathisGD]

you're right, it wouldn't fix anything for classic implementations of permissioned wrappers