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一起使用责任链模式然后依赖注入或者动态加载？