#79 墨菲安全 CLI

2022-04-25

OSCHINA 上听说墨菲安全, 是一个 Golang 写的 cli 工具, 收集项目的依赖信息提交到服务器端, 查询可能的安全风险。
根据官方文档,目前支持 Java(maven,gradle),Golang(go mod),Node(npm,yarn),Python(pip)语言。

本文档就是简单的试用一下。

总结:我感觉挺好的,一般来说对于依赖我们都不上心,其实是有很大安全风险在里面。我觉得应该对线上业务的依赖都应该有严格的审查。
如果是安全方面的需求没有那么强烈,用这个工具可以为依赖的管理提供一些帮助。
可以考虑和 CI/CD 继承,如果有安全风险就发出告警信息。

#76 如何面试程序员

2022-04-13

之前写的关于面试的文章都是站在求职者的角度,今天这一篇是站在招聘者的角度。工作一些年之后,总是会偶尔参与到公司的招聘流程中。在做面试官之后,应该如何来考察一个开发者的工作能力呢?

#75 解释解释什么叫 “包容性命名”

2022-04-02

开发者想必都有耳闻,过去一两年间,因为一些美国政治风波的影响,各大社区都被政治正确问题所困扰,然后有一些相关改名的操作。
PS: 连黑人牙膏(高露洁旗下)都改名 “好来牙膏” 了。

最著名的可能就是 GitHub 中的默认主干分支从 master 改成 main,然后很多项目宣布将主从表述由 master/slave 改成 primary/replica,黑名单 Blacklist 改叫 Denylist 或者 Blocklist。

我最近听说有个叫包容性命名促进会的组织(Inclusive Naming Initiative)。
https://inclusivenaming.org/

他们列了一个清单,将开发过程中常用的一些有冒犯性的词,按照冒犯级别分三类,然后还给出来一些他们建议的替换词。

#73 2022 BUG

2022-01-28

前些天应该都看过微软 Exchange Server 开发者跨年改 BUG 的新闻了吧 (相关链接)。

Exchange Server 的邮件过滤器采用了 yymmddHHMM 格式的时间,存储在 long 类型字段中。
PS: 微软的 C++ Compiler 会将 long 当做 32 位 int。

32 位有符号整形能够表达的范围:[$-2^{31}$, $2^{31} - 1$],也就是 [-2147483648, 2147483647]。

到了 2022 年,就会超出范围,比如 2022-01-01 12:00:00, 会被存储为 2201011200,会超出 signed int 的表达范围。

2147483647
2201011200 # 超出

可能有一些系统采用 int 类型存储 yymmdd + 4 位数字做编号的方式,比如 2101011234。
相同的原因,到了 2022 年,就行不通了。

2147483647
2201011234 # 超出

最好的办法是改成 long long, 或者 unsigned int

PS: Linux 下的 C/C++ 编译器——GCC、CLang/LLVM 都是将 long 当做是 64 位。

参考资料与拓展阅读

#72 西安一码通的“优化”

2022-01-07

西安一码通半个月内两次宕机,值此西安疫情突发之时,可是严重的安全故障。相关负责人(西安大数据资源管理局局长)已经停职检查。

为确保系统运行更高效,他们将一张图片从1MB压缩到500KB,再从500KB优化到100KB。这样的工作看似简单,却蕴含着高技术含量,他们连续两天两夜守在电脑前,终于攻下难关。

#69 转载:正则表达式历史

2021-12-19

正则表达式在我们日常的软件开发过程中被广泛使用,例如编写 Nginx 配置文件、在 Linux 与 macOS 下查找文件,然而不同软件不同操作系统对于正则的应用有着不一样的行为,主要原因是正则表达式演进过程中,出现 POSIXPCRE 派系之分。

#68 程序员的 10 个习惯

2021-12-08

公众号四猿外的文章《这 10 个程序员的好习惯,让我变强了》,很有同感,这里总结一下:

  1. 要看官方文档,网上的资料鱼龙混杂
  2. 开发者的可靠性:自测没有问题了再交付
  3. 日志设计合理,保证调试时,有恰当的信息来定位问题
  4. 精通 Git
  5. 优先功能实现,别急着优化
    过早优化是魔鬼,应该根据实际运行的情况来优化
  6. 先做明确的需求,不确定或者模糊的需求先往后放
  7. 积极主动:发现问题,提出方案,解决问题
  8. 开发时间评估,保证有冗余时间,以处理可能的意外
  9. 学习编程主要靠上手写代码,不要光看文档
  10. 英语。不需要很好,能看懂英文文档就行

#67 Susam Pal:Curl 计时

2021-11-28

Here is a command I use often while measuring why an HTTP request is taking too long:

curl -L -w "time_namelookup: %{time_namelookup}
time_connect: %{time_connect}
time_appconnect: %{time_appconnect}
time_pretransfer: %{time_pretransfer}
time_redirect: %{time_redirect}
time_starttransfer: %{time_starttransfer}
time_total: %{time_total}
" https://example.com/

Here is the same command written as a one-liner, so that I can copy it easily from this page with a triple-click whenever I need it in future:

curl -L -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_pretransfer: %{time_pretransfer}\ntime_redirect: %{time_redirect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" https://example.com/

Here is how the output of the above command typically looks:

$ curl -L -w "namelookup: %{time_namelookup}\nconnect: %{time_connect}\nappconnect: %{time_appconnect}\npretransfer: %{time_pretransfer}\nstarttransfer: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
...
</html>
time_namelookup: 0.001403
time_connect: 0.245464
time_appconnect: 0.757656
time_pretransfer: 0.757823
time_redirect: 0.000000
time_starttransfer: 0.982111
time_total: 0.982326

In the output above, I have omitted most of the HTML output and replaced the omitted part with ellipsis for the sake of brevity.

The list below provides a description of each number in the output above. This information is picked straight from the manual page of curl 7.20.0. Here are the details:

  • time_namelookup: The time, in seconds, it took from the start until the name resolving was completed.
  • time_connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.
  • time_appconnect: The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed. (Added in 7.19.0)
  • time_pretransfer: The time, in seconds, it took from the start until the file transfer was just about to begin. This includes all pre-transfer commands and negotiations that are specific to the particular protocol(s) involved.
  • time_redirect: The time, in seconds, it took for all redirection steps include name lookup, connect, pretransfer and transfer before the final transaction was started. time_redirect shows the complete execution time for multiple redirections. (Added in 7.12.3)
  • time_starttransfer: The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.
  • time_total: The total time, in seconds, that the full operation lasted. The time will be displayed with millisecond resolution.

An important thing worth noting here is that the difference in the numbers for time_appconnect and time_connect time tells us how much time is spent in SSL/TLS handshake. For a cleartext connection without SSL/TLS, this number is reported as zero. Here is an example output that demonstrates this:

$ curl -L -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_pretransfer: %{time_pretransfer}\ntime_redirect: %{time_redirect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" http://example.com/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
...
</html>
time_namelookup: 0.001507
time_connect: 0.247032
time_appconnect: 0.000000
time_pretransfer: 0.247122
time_redirect: 0.000000
time_starttransfer: 0.512645
time_total: 0.512853

Also note that time_redirect is zero in both outputs above. That is because no redirection occurs while visiting example.com. Here is another example that shows how the output looks when a redirection occurs:

$ curl -L -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_pretransfer: %{time_pretransfer}\ntime_redirect: %{time_redirect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" https://susam.in/blog
<!DOCTYPE HTML>
<html>
...
</html>
time_namelookup: 0.001886
time_connect: 0.152445
time_appconnect: 0.465326
time_pretransfer: 0.465413
time_redirect: 0.614289
time_starttransfer: 0.763997
time_total: 0.765413

When faced with a potential latency issue in web services, this is often one of the first commands I run several times from multiple clients because the results form this command help to get a quick sense of the layer that might be responsible for the latency issue.