最近开发遇到的一些问题:
1.SSL升级3.0后,JDK8-JDK11下运行报错,原因是SSL生成的https证书默认为PBES2加密算法,需要JDK8U302或JDK12+版本运行。
2.AES加密的JNI开发对接。C语言中,可以使用openssl提供的依赖,但是这个依赖比较大,windows系统默认也没有安装此依赖,最终选用tinyC-AES这个项目,仅十几K代码,但是需要注意是使用tinyC-AES,需要自己搞定padding部分,这部分容易出错。
3.Java里,尤其是网络协议(不是标准的本地磁盘物理文件地址统统视为网络协议地址),不能保证每次都读取到指定字节的stream流,这不影响最终读取结果,但是某些场合如加密可能会有影响。
4.最近调研并二开了Apache Knox这个开源代理和SSO框架,坑太多太多,测试极其不严谨,食之无味弃之可惜,无论是文档还是设计架构,糟糕得令人发指。
5.chrony是个很好的NTP服务,但是很多人不理解chrony的设计思路,误解很多。
6.firewalld相比iptables,好看,但是鸡肋,规则导入极慢,且缺少很多功能,仅适用于规则少于20条以内的场景。
1.SSL升级3.0后,JDK8-JDK11下运行报错,原因是SSL生成的https证书默认为PBES2加密算法,需要JDK8U302或JDK12+版本运行。
2.AES加密的JNI开发对接。C语言中,可以使用openssl提供的依赖,但是这个依赖比较大,windows系统默认也没有安装此依赖,最终选用tinyC-AES这个项目,仅十几K代码,但是需要注意是使用tinyC-AES,需要自己搞定padding部分,这部分容易出错。
3.Java里,尤其是网络协议(不是标准的本地磁盘物理文件地址统统视为网络协议地址),不能保证每次都读取到指定字节的stream流,这不影响最终读取结果,但是某些场合如加密可能会有影响。
4.最近调研并二开了Apache Knox这个开源代理和SSO框架,坑太多太多,测试极其不严谨,食之无味弃之可惜,无论是文档还是设计架构,糟糕得令人发指。
5.chrony是个很好的NTP服务,但是很多人不理解chrony的设计思路,误解很多。
6.firewalld相比iptables,好看,但是鸡肋,规则导入极慢,且缺少很多功能,仅适用于规则少于20条以内的场景。