shadowsocks-libev: support cipher none

[liudongmiao]

Maintainer: me / @yousong
Compile tested: ath79-generic-openwrt-23.05 (docker sdk tag)
Run tested: ath79/generic, OpenWrt 23.05.2, Netgear WNDR3800

Description: backport none method to shadowsocks-libev
Please note, the encrypt should be done in plugin.

[yousong]

This does not look like a backport. I cannot find it in the upstream project. Maintaining custom patch here in the downstream should be avoided whenever possible.

[liudongmiao]

see shadowsocks/shadowsocks-libev#2993 However, as shadowsocks-libev is bug fix only now, it won't be merge forever.

[BKPepe]

Maintaining custom patch here in the downstream should be avoided whenever possible.

💯

Why do we need to suddenly needs this patch? In the referenced pull request, which was created today or based on @yousong comment, there is missing commit description in the commit in the upstream repository.

[liudongmiao]

I just forget to make a new pr in upstream. Howerver, in the new pr, I give the history of this feature (cipher none), and actually, there was a similar pr, the author first choose not to merge, then several years later, cipher none are supported by all implementation expcep shadowsocks-libev. And again, as the upstream say it's bug fix only, we can rename the patch prefix.

[liudongmiao]

Just force push, and use the patch from upstream pr, and mention it in commit message:

101-support-cipher-none.patch: shadowsocks/shadowsocks-libev#2993

[BKPepe]

Why this goes first to the stable branch instead of master? Anyway, I dont see why point, when upstream does not care, why we should. Why we should have this patch for ages and keep it in our repo?

[1715173329]

I still vote to shadowsocks-rust, adding local patches to a (mostly) deprecated branch doesn't look alright to me.

[liudongmiao]

@1715173329 I don't think low embedded devices like mips can use shadowsocks-rust.
And actually, there is a pcre2 patch in openwrt's shadowsocks-libev.

For cipher none, it's useful for low embedded devices, there is no need to double encrypt, one in shadowsocks-libev, and one in https (direct connection except https is not a good idea, and cannot use cdn).

[1715173329]

I don't think low embedded devices like mips can use shadowsocks-rust.

Why not?

[liudongmiao]

I don't think low embedded devices like mips can use shadowsocks-rust.

Why not?

You check whether it's in OpenWrt. And, shadowsocks-rust requires more storage.

[1715173329]

You check whether it's in OpenWrt. And, shadowsocks-rust requires more storage.

Makefile is already there, it would be very easy to get supported.
A slim sslocal build takes about 2.3-2.4 MiB, this is a reasonable size for modern devices.

[liudongmiao]

Why this goes first to the stable branch instead of master? Anyway, I dont see why point, when upstream does not care, why we should. Why we should have this patch for ages and keep it in our repo?

@BKPepe

1. about upstream don't care.. upstream choose shadowsocks-rust instead of shadowsocks-libev, and shadowsocks-rust it not included in OpenWrt. (OpenWrt prefer OpenSSL over MbedTLS just for about 1M, I don't think OpenWrt would introduce a 5M+ shadowsocks-rust.)

2. about add this patch in OpenWrt...If OpenWrt'd like to provide shadowsocks-libev, make it compatible with shadowsocks-rust and / or other implementation should be acceptable.

[liudongmiao]

@BKPepe Just change the pr from latest stable branch to master.
@yousong Could you review this patch?

[liudongmiao]

@1715173329 As I change the pr, merge into master (previous is openwrt-23.05), could you remove label "OpenWrt 23.05"?

[BKPepe]

For cipher none, it's useful for low embedded devices, there is no need to double encrypt, one in shadowsocks-libev, and one in https (direct connection except https is not a good idea, and cannot use cdn).

Still I am against to introduce such opinion based on security. You always want to encrypt it, no matter what and introducing such change only for you. Does not make sense, though. As you said, upstream does not care, we dont care as well.

Should be done in upstream not here.

[liudongmiao]

Still I am against to introduce such opinion based on security. You always want to encrypt it, no matter what and introducing such change only for you. Does not make sense, though. As you said, upstream does not care, we dont care as well.

Should be done in upstream not here.

Cipher none doesn't mean no encryption, it's a way to avoid duplicate encryption.

In real situation, it's like this, shadowsocks client + cipher --> https --> shadowsocks server + cipher, if there is no cipher none, it's double encrypted, one in the cipher of shadowsocks, one in https.

There is cipher none in upstream shadowsocks-libev's next shadowsocks-rust. However, there is no shadowsocks-rust in OpenWrt. @BKPepe

[yousong]

@liudongmiao The rust variant is not here simply because no one has the time/motivation yet to do it, preferably in a way compatible with current uci config.

The same reasoning also applies to maintaining custom patches here in the downstream. We simply do not have the manpower.

As for the pcre2 patch, you can be sure that we are all the same reluctant to add it. We did it because we wanted to keep what's already working to continue to be that way. That treewide transitioning to pcre2 is a good thing. In the end, there will be a point when shadowsock-libev is not maintainable here and we have to drop support for it.

[liudongmiao]

@yousong Thanks.

I'm working for a compatible libevent based sip003 plugin for OpenWrt that cannnot install v2ray-plugin.

On x64 machine, the libevent based plugin is a little faster than v2ray-plugin client.
And, it seems the speed is almost same for cipher none and cipher chacha on x64.

On mips, it seems cipher none is 25% faster than cipher chacha with the libevent based plugin.