Shadowsocks-windows: Discuss infrastructure improvements for the next major release

[Stzx]

To be re-edited

[ghost]

That means we may need drop single exe + builtin blob. Managed version of libsscrypto may necessary too.

For Linux, both WPF and WinForm won't work. Another UI is needed for cross platform, maybe use RESTAPI + Electron? If you do so, I can do JavaScript part.

[Stzx]

Yes, at present, if you use independent publishing, the file size has exceeded 150M.

Framework-dependent publishing seems to have become the preferred choice.

[ghost]

And UWP, #1177. If we add non-win32 platform, then system proxy/VPN setting shouldn't included in stdlib.

[celeron533]

This project is focused on Windows platform. For other platforms, they have libev, qt or other implementation.

[ghost]

This project is focused on Windows platform. For other platforms, they have libev, qt or other implementation.

They lost qt implementation two months ago...

[ghost]

At least we can make stdlib cross platform.

[celeron533]

They lost qt implementation two months ago...

The original project is no longer maintained.
wait....
It is open source.

[ghost]

So we will neither release a Linux version nor provide support to possible Linux user here.

But I still suggest decouple stdlib and OS:

• Give the community one more chance, there are some issue about port this project to other platform.
• UWP, or S mode is still a target platform.
• Just make core logic clean.

[Stzx]

At present it seems that I have to give up the I18N I just rewritten (and need to rewrite) because TextFieldParser is not applicable to .NET Standard. :sweat_smile:

We use CsvHelper ?

[ghost]

https://www.infoq.com/news/2019/02/VB-File-IO-Core/

[Stzx]

Yes, I forgot. Another way is to port it to win lib.

[ghost]

You can just use CsvHelper, Or ignore I18N now, pass compile first...

[Stzx]

Split non-ui I18N content into separate files ?

@studentmain
@celeron533

[ghost]

OK, stdlib has nothing to do with UI.

[stonedreamforest]

The UI framework can try Xamarin.

[Stzx]

UI related work has not been fully started, you can discuss it first.

[ghost]

The UI framework can try Xamarin.

Even stdlib will run in mutiple platform, we'll only officially support win32 platform here, I'm not sure use a cross platform UI framework here is a good choice. If we really need a cross platform UI, maybe Electron is better? It has official Linux support and we needn't know how GTK works.

[ghost]

1230 FYI

@ohsorry

[ohsorry]

整体提议很好。我个人认为没必要做linux平台兼容。因为玩linux的有libev版的。
如果做做兼容可以使用.net core开发一个跨平台的无UI的可执行文件。在linux上用命令行+配置文件运行；在win上有个UI壳子去执行命令行+配置文件这个动作。
因为这就是个windows版的项目（方便所有人配置、使用），我感觉最重要的就是重构下代码结构，让社区方便维护就好了。
安全通信协议这块可以考虑抽象下，提供常用标准加密，同样支持混淆、自己开发的协议……
但是不要搞得太复杂（出发点就是个上网小工具），新小白用户（甚至专业的）学习配置都要半天，那岂不是废了。对小白友好，对社区友好就行了。
就这些吧。
因为现在的代码我也没有读完，可能需要重构后我才能参加维护。

[Stzx]

现在 shadowsocks-csharp-dotnet-core-stdlib 中加密那块是通过委托方式和 win-lib 做的交互，Utils 那块该移动（也许? ) 的也迁移完了。可以先看下代码讨论下？

需要交互的委托都集中在此: Delegates.cs

Win 的委托相关实现: DelegatesInit.cs

目前的实现不太满意( 需要多写很多重复的代码。 :confused:

[ohsorry]

我看了下，那几个加密库我觉得选一个轻量级就好了。
做interop的wrapper只能这么写了，就是麻烦点。

_其实这些可以扔了，声明几个有限的加密方式接口，默认提供纯c#实现就好了。我比较倾向 精简。
我是觉得安全方面几个可选加密方式够了。_
_那几个是cpp环境的加密库，.net自带库里不是有好多加密实现？_
_BouncyCastle.Crypto 不知道怎么样？_

[ghost]

其实这些可以扔了，声明几个有限的加密方式接口，默认提供纯c#实现就好了

要考虑的问题：

• 和旧版本兼容性（已证明不安全的rc4-md5仍然由于某些原因大量使用）
• 是否有能力及时跟进服务端的更新（就像3.x到4.x时一样）
• 纯C#的性能是否会造成问题（C++实现对AES有硬件加速）
• 第三方密码学库的可靠性（会不会遭遇供应链攻击）

[ohsorry]

如果重构还不考虑新建一个仓库？不是major release吗。
我觉得性能问题在这里不用考虑（用interop已经内存拷贝了，还指望cpu指令级的优化么）。
现在不都是第三方的开源加密库，著名的openSSL还出过心脏滴血漏洞呢。再Geek一点，那就自己设计加密算法了。
纯属个人看法。

[imba-tjd]

加密算法，我们自己实现出来安全性只可能更差，更别提设计了= =

[ohsorry]

加密算法，我们自己实现出来安全性只可能更差，更别提设计了= =

不是说按照维基百科去实现，可以直接移植或拷贝现有的代码。这轮子不用造。

[ghost]

如果重构还不考虑新建一个仓库

需要考虑如何把用户请过去。如果这个仓库长期不发布新版本，用户更可能认为是我们凉了。现在的自动更新机制可能没法处理换仓库这种复杂的问题。

都是第三方的开源加密库

供应链安全不得不加以考虑，来历不明的软件包显然不能乱安。不过考虑到.NET Core WCF也在用，看来问题不大。

我觉得性能问题在这里不用考虑。

需要数据支撑，我认为近年的桌面平台上使用AES系列时能够达到100Mbps即可用于客户端。（廉价VPS常用100Mbps线路速度，能跑满最好）

心脏滴血漏洞

既然提到OpenSSL了，我顺便抱怨一句：

• 整个计算机行业都在用
• 是同类软件事实标准
• 活跃维护者一只手数得清
• 没有全职开发人员
• 没有哪家公司提供支持

在这些地方上我们和当年的OpenSSL项目一样有经验。

[ohsorry]

需要考虑如何把用户请过去。

那不是小事么，现有仓库告诉用户已经不维护了。自动更新以后静默更新。

需要数据支撑

有空就测下呗，没准更快呢。这也不是服务端加解密，也不是写服务器，我是觉得没必要考虑这点性能差异。

[ghost]

静默更新

反对在用户不知情的情况下更新并安装。

更新通道本身不安全（先安装假证书然后中间人攻击即可做到）的情况下，我们就是在给用户下载安装恶意软件。

有空就测下

换密码库的事情，我们可以在测量之后再做进一步讨论。当然个人也是希望使用跨平台密码库的。

[ohsorry]

反对在用户不知情的情况下更新并安装。

嗯，只是个提议。其实现在每隔几天提示我该更新了。然后我关闭ss，解开ss_temp目录的压缩包，覆盖到主目录。操作好几次了。

[ohsorry]

我补充下“对社区友好”的意思。
就是说比如 一个有5年C#经验的人第一次接触这个项目（假设他有足够的网络编程知识和经验例如socket、加解密等）。他能根据开发文档3分钟定位功能代码，半个小时看懂整个工程的思路，并能自己二次开发，那就可以了。所以工程的结构要简单清晰，突出重点。面向抽象编程。比如他要修改或扩展日志、加密、服务器选择策略等，能快速定位到那一部分，不需要阅读全部代码，而且修改起来对其他部分几乎完全没影响。就这个意思，这样就差不多算一个容易维护的工程了。

其实不需要什么Model、View、Controller，太复杂了。我的思路差不多就 #1230 里的。
仅供参考。

[ghost]

https://github.com/shadowsocks/shadowsocks-windows/issues/2714#issuecomment-562828659

Here is why we have both OpenSSL, mbedTLS and libsodium

我觉得性能问题在这里不用考虑

I think so... Maybe we can remove OpenSSL? And #934 has some old discussion we interested.

[ohsorry]

我不说了么，我认为这里计较一点性能差异没意义。.net自带的实现或者专业的.net加密库够专业了。
如果追求性能，面向服务器开发的，那我会整个工程选择c/c++开发，肯定x64的。
而且加密算法这东西不定什么时候淘汰，不定什么时候出新算法。所以下一版把工程重构才是重点。
没准windwos第一版作者也是图省事直接模仿python版实现，包装了下那几个加密库。
现在的windows版本太复杂了，要是我就全部用c#来写。连本地ss-local的server也用c#写，不用privoxy。
还是，仅供参考。

[ohsorry]

而且现在有gfwlist，还有个user-rule，还有pac，太乱了。想配置规则都是个挑战。

[ghost]

现在 shadowsocks-csharp-dotnet-core-stdlib 中加密那块是通过委托方式和 win-lib 做的交互，Utils 那块该移动（也许? ) 的也迁移完了。可以先看下代码讨论下？

需要交互的委托都集中在此: Delegates.cs

Win 的委托相关实现: DelegatesInit.cs

目前的实现不太满意( 需要多写很多重复的代码。 😕

平台库不应过问标准库使用什么方式实现加密，标准库能够列举它当前支持的所有加密（List<CipherInfo> ListAllCiphers()）并能够按名称提供加密方式（Encryptor GetEncryptor(string name)）即可。

[ghost]

而且现在有gfwlist，还有个user-rule，还有pac，太乱了。想配置规则都是个挑战。

2746 的确如此

[ohsorry]

平台库不应过问标准库使用什么方

其实不知道你们说的平台库标准库是什么意思。这个软件一共没多少代码，不用抽象什么库。按功能模块划分就行了。

[ghost]

不懂密码学，需要帮助：在经过两天的尝试之后，我仍然没有成功地使用BouncyCastle.Crypto生成与现有实现兼容的密文。

[Stzx]

新的加密实现将不再支持 Stream Ciphers。

Shadowsocks - Wiki - Stream Ciphers

[ghost]

新的加密实现将不再支持 Stream Ciphers。

Shadowsocks - Wiki - Stream Ciphers

步子太大了，我们连rc4-md5都还没废除掉，建议到2021年再提废除流加密的事情。

[ghost]

加密的问题可以在shadowsocks-org发issue告知一下，顺便看看其他主要实现有什么计划。个人希望在今年年中或者明年的某个版本把其他流加密也标记为弃用，在2022年年初移除并切换到纯.NET加密实现，不过仅仅是目前的个人想法。不过可以在v5移除rc4-md5那些已经证明不安全的。

[Stzx]

目前正在看以前的代码，尝试替换为 BouncyCastle.Crypto。

[ghost]

一些自上而下重新设计程序结构的尝试，仅仅是尝试，不要太期待。https://github.com/studentmain/shadowsocks-windows/tree/experimental

[Stzx]

Encryption

@studentmain 看看现在初步的结构?

还有这个已完成的 I18N

[ghost]

还行，但是注册重启这些东西就不必塞core里面了。改注册表这种完全不跨平台的不需要在里面绕一圈，一切围绕服务器管理来。

[ghost]

https://github.com/TongxiJi/shadowsocks-java 一则纯Java实现，密码学部分使用的BouncyCastle Java版，有AEAD，使用MIT发布，或许可以抄作业

[Stzx]

@studentmain 我看了下，如果需要适应现在的结构需要改的也不是太多。作业还是可以抄的。

[ohsorry]

.NET 3.0 增加了对 AES-GCM 和 AES-CCM 密码的支持

[celeron533]

还行，但是注册重启这些东西就不必塞core里面了

core的任务需要精简，按照参数连接到某一个远程端口（这个端口甚至可以是本地插件端口），并且客户端这边只监听socks5。

[ghost]

只监听socks5

这种情况下难以实现同端口监听HTTP

[celeron533]

同端口监听HTTP

PAC打算怎么处理呢？和HTTP一起使用责任链模式然后依赖注入或者动态加载？

[ghost]

和HTTP一起使用责任链模式然后依赖注入或者动态加载？

是个办法，server.Listen(int port, Listener[] additionalListener)？

[celeron533]

Split non-ui I18N content into separate files

I remember that weblate uses separate language files.

[celeron533]

Person thoughts for the new infrastructure:

1. Abandon the current design, start from scratch.
2. Three main components: core, core-extensions(not the plugin), UI.
3. No necessary to always have single exe file. Could have a set of DLLs, configurations files in a folder.

Core

1. Prefer to be all .Net code, .Net Core is better, for cross platform.
2. Only have the fundamental functions. Begin from accept a local Socks5 (or plus HTTP if required) request to receive response from remote server.

Core-Extensions

1. Simple server manager. Every time just use one server.
2. Complex server manager. Use a server pool to activate more than one server in the pool and route the network stream guided by policies such as load balance, Geo-IP.
3. PAC.
4. Geo-IP.
5. Connection statistics + load balance.
6. Command line interface.
7. Others.

UI
Server options for implementing UI on different platforms:

• Electron. One solution for all platform, but a bit heavy.
• Xamarin. One solution for all platform, still heavy.
• Web page. Lightweight, but need to implement web server. Also need a bit platform related code to show tray icon.
• Qt. emmmmmm.
• WPF. Currently is windows only. Not quite sure the cross platform on MS. (no more WinForm)
• Anything else?

[ghost]

If we drop single exe, we can have an official installer. That mean we can register protocol handler and run sysproxy as service (if it still exists at that time).

Complex server manager need some design: how to configure it easily? About route: we can put router in two place: PAC file and socks5 server, choose which one, or choose both.

Prefer move CLI to UI section. Electron is way TOO heavy, 50MB chrome and 3MB program. I prefer WPF for Windows and web page for all other platform. There are so many simple HTTP server implementation in C#, API server needn't use same local port with proxy server.

[celeron533]

If we drop single exe, we can have an official installer

Alternatively, user could also unzip the archive file without installation.

run sysproxy as service

With the new infrastructure, sysproxy may have different implementation not limited as a service. Service is good but the file is always occupied by the service itself unless you delete the service. At that time, user is difficult to move, delete, replace the dll file. Moreover, register the service requires privilege escalation. That's my concern.

[ghost]

新的加密实现将不再支持 Stream Ciphers。
Shadowsocks - Wiki - Stream Ciphers

步子太大了，我们连rc4-md5都还没废除掉，建议到2021年再提废除流加密的事情。

Based on https://github.com/edwardz246003/shadowsocks , I think we need do it as soon as possible. I wonder to know how many user aren't using AEAD.

[Stzx]

新的加密实现将不再支持 Stream Ciphers。
Shadowsocks - Wiki - Stream Ciphers

步子太大了，我们连rc4-md5都还没废除掉，建议到2021年再提废除流加密的事情。

Based on https://github.com/edwardz246003/shadowsocks , I think we need do it as soon as possible. I wonder to know how many user aren't using AEAD.

I personally think it is better to delete the encryption method that is no longer secure.

[ghost]

I agree we need remove them. Then we need deprecate them in next (minor) release. And we can implement only 2 ciphers (aes-gcm and chacha20-poly1305 with different length) after do this, that make life easier.

[ohsorry]

如果一个知道服务端密码的客户端企图让服务端的socks5去relay一个服务器的局域网内地址，现在的服务端会怎样？比如服务器IP是192.168.1.2，客户端代码让服务端代理192.168.1.3:8080。

[ghost]

如果一个知道服务端密码的客户端企图让服务端的socks5去relay一个服务器的局域网内地址，现在的服务端会怎样？比如服务器IP是192.168.1.2，客户端代码让服务端代理192.168.1.3:8080。

取决于服务端配置，毕竟代理局域网也算是一种合理需求（对，真的有人拿这东西做内网代理）

[ohsorry]

我前两天看代码考虑的问题。这样都能做内网扫描了。

[ghost]

我前两天看代码考虑的问题。这样都能做内网扫描了。

客户端对于服务端处理内网地址显然做不了什么……

[ohsorry]

客户端对于服务端处理内网地址显然做不了什么……

能做的真不少。
举个例子，服务器局域网内有个开着 8080 http服务的管理角色的节点，有局域网的管理权限，恰好这个8080连密码都不用输…… 你搜下内网渗透之类的。

[ghost]

客户端对于服务端处理内网地址显然做不了什么……

能做的真不少。

客户端是可以换的。换一个没做那些的客户端，我们做的一下就没用了。

[celeron533]

I agree we need remove them. Then we need deprecate them in next (minor) release. And we can implement only 2 ciphers (aes-gcm and chacha20-poly1305 with different length) after do this, that make life easier.

And use BouncyCastle.Crypto to get rid of interop.

Also, if user has plugin and the plugin tunnel has its own encryption, need to consider bring back plain (no encryption) or even rc4-md5 back to save CPU.

[ghost]

Benchmark for aes-gcm reported high enough(Gbps) perfomance. This is Windows PC which even can run a fancy desktop environment.

Here's an old benchmark result by go-shadowsocks2: https://github.com/shadowsocks/shadowsocks-org/issues/41#issue-206248343

And we remove stream cipher due to security reason, there's no reason bring back plain mode for every users, server side support is another problem. At least I suggest provide plain only when: user has a plugin and user enabled plain mode via command line or config file.

P.S: traditional table mode is another option if we want provide perfomance in exchange of security.

[ghost]

bring back plain (no encryption) or even rc4-md5 back to save CPU.

https://github.com/studentmain/shadowsocks-windows/tree/net-rc4 make old cipher suite great(?) again

[ohsorry]

我最近有意愿重构一下这个项目，不知道有多少人有这个想法？
现在有几个人维护这个项目？ @studentmain

[ghost]

@ohsorry 活跃的维护者一只手数的出来，重构的想法可以说所有的活跃维护者都有……

[ohsorry]

@studentmain 暂时有个构思，我试着写写了，等差不多了我新建个项目，到时发过来。

[celeron533]

目前正在看以前的代码，尝试替换为 BouncyCastle.Crypto。

@Stzx

research branch, will be removed when done (or surrender :P )
https://github.com/celeron533/shadowsocks-windows/tree/BouncyCastle

[Stzx]

我的分支代码在合并中丢掉了一些 ;(

我看了下分支中的几个提交。

你应该也发现了，代码比较少很简洁就可以实现一些基本的算法。 而相对于个别算法来说没法一步到位， 如：chacha20-ietf-poly1305 。

我推荐使用 CipherUtilities、ParameterUtilities 等工具来获取相关对象。

官方的示例也有很多可以参考的例子： https://github.com/bcgit/bc-csharp/tree/master/crypto/test

年后工作较忙，我的进度比较慢，如果你们首先完成了目标，我会切换到进度较快的分支，以早日完成所有目标。

@celeron533

[ghost]

不急，慢慢来，从宣布废除流加密（我们甚至还没发新版本宣布）到真正移除它要有一定的缓冲期。

另外重构过程中估计也要时不时发几个prerelease，自动更新的代码要相应修订以避免意外更新到这些多半不兼容的版本上。

[ohsorry]

如果重构的话，核心可以用.NET Standard写；如果核心用.NET Standard重写了，那也应该跨个平台。毕竟核心写完了，用核心写个app就是套个壳子的事情。而且.NET的性能也还可以，所以可以把跑在Linux上的服务端也写了。我计划设计跨平台的版本！
Windows版的有界面，Linux的用命令行。
你们怎么考虑的？

[ohsorry]

另外计划增加简单的混淆功能。可以使用自带的或快速编写自己的混淆组件。

[ghost]

如果重构的话，核心可以用.NET Standard写；如果核心用.NET Standard重写了，那也应该跨个平台。毕竟核心写完了，用核心写个app就是套个壳子的事情。而且.NET的性能也还可以，所以可以把跑在Linux上的服务端也写了。我计划设计跨平台的版本！
Windows版的有界面，Linux的用命令行。
你们怎么考虑的？

服务端？好啊，不过到时候肯定要另外开仓库。图形界面本身是不打算跨平台的，不过有希望搞出来一个跨平台的基本命令行。

另外计划增加简单的混淆功能。可以使用自带的或快速编写自己的混淆组件。

遵循标准就行了，标准提供了混淆组件的接口，上一个“增加简单的混淆功能”的是ssr。

[ohsorry]

ssr的混淆不好使还是怎么了？挂了？

标准提供了混淆组件的接口

你说的接口标准在哪？
混淆不用单独的进程。

[ghost]

他们最终从“简单的混淆”变成了复杂的混淆，我认为我们维护不来。另外当初原作者不干了对他们社区冲击太大，至今没有恢复……

现行标准在 https://github.com/shadowsocks/shadowsocks-org/issues/28

单独的进程的额外好处是不限制语言和方便调试，你可以用java或者python实现混淆插件，同时使用原生的调试器直接调试插件。

[ohsorry]

单独的进程的额外好处是不限制语言和方便调试

是有好处。但是写IPC的程序太麻烦了，IPC太累。就算到了适合开进程的时候，别忘了.net还有AppDomain呢。
如果设计上留了混淆的接口，那么会写C#的人可以开发自己的混淆，各种各样。

[ghost]

考虑到用户和我们的复杂度，内置还是外置实际上是单选题——而且我们已经选过了。另外，现行插件实际上可以脱离程序本体运行，开发过程和开发常规网络程序没什么区别。

[ohsorry]

这让我想起了当初ss->kcp->udp_raw。姿势太丑了。我先写着玩下吧。

[celeron533]

BouncyCastle 性能还不错，2倍到3倍时长

[ohsorry]

测的AES么，托管的实现这速度可以了。想快点可以试试平台自带的AesGcm。

飞快。
https://github.com/ohsorry/Test/blob/master/Program.cs

[ghost]

新协议的草案 https://github.com/shadowsocks/shadowsocks-org/issues/157

我认为新版本比新协议先准备好，那样的话就在新版本上测试新协议，完全实现新协议后把版本号滚到v6。反之在老版本上测试新协议的部分功能，然后在新版本上最终实现。

[ohsorry]

我是重构，暂不考虑socks6了。
写一半了，谁给我新建个仓库？

[ohsorry]

核心我重构的差不多了，你们要不要看看，来一块加代码？ @studentmain , @celeron533
加密部分AES用自带就行了，其他不耗cpu的用托管的实现。

[celeron533]

写一半了，谁给我新建个仓库？

OK. 你起个名字，我去开新的repo

[ohsorry]

我起了名字叫Shadowsocks-Net。还在整理代码

[celeron533]

我起了名字叫Shadowsocks-Net

Created
https://github.com/shadowsocks/Shadowsocks-Net
Your are free to push the code directly.

[ohsorry]

好的，我稍微写点README。一会我传上去你们有时间看看思路先。

[ghost]

试图完全移除libsscrypto，在使用BouncyCastle提供的MD5, HKDF和手写的sodium_increment替换MbedTLS和libsodium的相应实现之后几乎可以用，HTTP好的，TLS不行。另外shadowsocks-java没有chacha20-ietf-poly1305的作业可以抄，我们得自己做。

@ohsorry 如果要加混淆（涉及到协议更改以及URL格式注册等），应该同时到shadowsocks-org提交标准草案。另外记得测试一下和旧服务端的兼容性。

[ohsorry]

@studentmain 好的，有空看下我写的，Minimal版能测了。我测了客户端和服务端跟现有的能互相替换的。
暂时就hkdf用了下BouncyCastle。nonce递增递减我就用整数++和--写的。BouncyCastle有chacha20和poly1305但是没合起来，有人提交实现了，可以测下。nuget上也有写好的。
另外本地http我也写了，用着很好使。Minimal版现在自带http。

[wordlesswind]

请问下一代版本有计划支持 GeoIP 分流吗？
因为 GFWList 已经有超过5个月没有更新了。
而且鉴于 GitHub 被中间人攻击来看，可能分流访问是个不可避免的趋势了。

[ghost]

@wordlesswind #2746 #2827 https://github.com/Hackl0us/SS-Rule-Snippet/issues/105

[ghost]

Working on a general purpose (not couple with shadowsocks network stack) routing module: https://github.com/studentmain/shacks

[florianmonfort]

Hi all, any updates on UWP support? So many apps now are UWP, it's getting difficult to do anything haha.

[ghost]

Hi all, any updates on UWP support? So many apps now are UWP, it's getting difficult to do anything haha.

https://github.com/YtFlow/YtFlowApp

[florianmonfort]

Hi all, any updates on UWP support? So many apps now are UWP, it's getting difficult to do anything haha.

https://github.com/YtFlow/YtFlowApp

Does this app have any executable to install instead of having to build a VS solution manually? 😂 It would be quite troublesome to keep an installation of VS active on my machine only just to build this app no?

[bdbai]

@florianmonfort YtFlow is now available through

1. GitHub Releases
2. Microsoft Store (private link)

Thanks for your interest in YtFlow.

[florianmonfort]

@florianmonfort YtFlow is now available through

1. GitHub Releases
2. Microsoft Store (private link)

Thanks for your interest in YtFlow.

Wow this is great! Thanks for recommending

[Stzx]

Move to #2979

[johnx7271]

For ui, how about Avalonia.Desktop?

"Avalonia is a WPF/UWP-inspired cross-platform XAML-based UI framework providing a flexible styling system and supporting a wide range of Operating Systems such as Windows (.NET Framework, .NET Core), Linux (via Xorg), MacOS and with experimental support for Android and iOS."

Btw, three things I dont like:

1. privoxy, this one is not really needed anymore, but is carried along from old times. My fork of this project has remove it already.
2. many overlapping crytography libraries.
3. now there are many branches of servers and clients, and each branch has its own versions, and the interroerbility is now a thing that needs to be addressed.
   for issue 3, a simple preliminary solution is to add a function to return the current server's branch (git repository url, tag etc).

[database64128]

@johnx7271 #2962, #2966, #2979.

To address your concerns,

1. privoxy is the infrastructure to provide HTTP proxy. You’re welcome to write an alternative solution and open a PR.
2. Please elaborate.
3. I hope you at least know enough about this project to realize that we have no server implementations. It seems you also have very limited experience with git. So I won’t go into detail here. But I can assure you that stale branches have already been removed.

[johnx7271]

1. privoxy is not needed, socks5 is more than enough, http proxy and socks4 are no longer needed.
   browsers earlier than IE 11 may need privoxy.
   privoxy introduces more code complexity and maintainance, external dependence, and reduce runtime performance, should be totally discarded.
   I have a fork with this left-over removed, it works fine.

2. mbedtls, libsodium, openssl all have its own implementation of some cryptography algorithm, they have lots of overlapping.

3. I know more than enough about git and this project and related projects.
   I think you misunderstood me.
   What I meant is, for server, there are shadowsocks, ~-go, ~-python, ~-libev, and there are alternatives like ~R, or ~RR version, under different persons or organizations. The same situation goes with the client.
   So if you use one client to work with a server, it may not work, and when this happens, there is no way to know what really is the problem.

I dont think it's good manner and polite to point-finger or blame ppl so easily and early.

[ghost]

不同的实现，即使may not works，也是有益的。（据我所知，在两端配置相同的情况下，主流实现均可正常工作）

• 即使本项目的开发者全部被卡车撞死，无法继续开发，clash for windows, v2rayN（对，他们也支持shadowsocks）, shadowsocksrr等项目仍然可以使用
• 即使本项目突然爆出了极为严重的安全漏洞，clash for windows, v2rayN, shadowsocksrr等因为是独立开发，仍然可以使用
• 如果本项目决心推行一个错误连篇的标准，clash for windows, v2rayN, shadowsocksrr等会因为其错误而拒绝执行

至于socks4，https://github.com/shadowsocks/shadowsocks-windows/issues?q=socks4

[ghost]

密码学库功能重复的问题上，如果你看了最近的commit，你就会知道再也没有什么openssl，mbedtls和libsodium了

[johnx7271]

@studentmain , I dont understand you, and I dont think you have understood me.
Let me explain.
There does exist the interroperbility issue, e.g. a machant provides server service, and someone who picked up the configuration posted on web by the machant, the user may use whatever client he happens to like, and it may not work with the server version. But the problem is, the user has no mean to find out which server implementation are used by the marchant, and what client version he should use.

"如果你看了最近的commit，你就会知道再也没有什么openssl，mbedtls和libsodium了",
I dont think so, these are all wrapped up in libsscrypto.dll !

[ghost]

如果不同实现间确实存在互操作问题，你可以向相应实现的作者反馈。

I dont think so, these are all wrapped up in libsscrypto.dll

The Legion of the Bouncy Castle Inc. 听了会很伤心的

[johnx7271]

"你可以向相应实现的作者反馈", 1. it's not "作者", but the vendor who provides the servers that should be contacted at first. 2. more often than not, the contact information for the vendor is not readily available. 3. only after that, you can ask the vendor for the specific implementation and the author of the server ssr.
You see, this process is cumbersome.

[ghost]

显然我们不可能阻止任何人从头实现一个类shadowsocks协议并封闭源代码。因此即使shadowsocks只有一个开源实现——甚至更极端一点，一个都没有——你仍然会面临互操作问题。