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.

[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.

[ghost]

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

[ghost]

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

[stonedreamforest]

The UI framework can try Xamarin.

[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版的项目（方便所有人配置、使用），我感觉最重要的就是重构下代码结构，让社区方便维护就好了。
安全通信协议这块可以考虑抽象下，提供常用标准加密，同样支持混淆、自己开发的协议……
但是不要搞得太复杂（出发点就是个上网小工具），新小白用户（甚至专业的）学习配置都要半天，那岂不是废了。对小白友好，对社区友好就行了。
就这些吧。
因为现在的代码我也没有读完，可能需要重构后我才能参加维护。

[ohsorry]

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

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

[ghost]

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

要考虑的问题：

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

[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。

[cherinyy]

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

[ghost]

@wordlesswind #2746 #2827 Hackl0us/SS-Rule-Snippet#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只有一个开源实现——甚至更极端一点，一个都没有——你仍然会面临互操作问题。