Posts List

NilAway:实用的 Go Nil Panic 检测方式

原文:NilAway: Practical Nil Panic Detection for Go 译者:madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT Uber 由于 Go 语言的高性能,广泛采用其作为实现后端服务和库的主要编程语言。Uber 的 Go monorepo 是 Uber 最大的代码库,包含 9000 万行代码(并且还在增长)。这使得编写可靠 Go 代码的工具成为我们开发基础设施的重要组成部分。 指针(保存其他变量的内存地址而不是其实际值的变量)是 Go 编程语言的一个重要组成部分,有助于高效的内存管理和有效的数据操作。因此,程序员在编写 Go 程序时广泛使用指针,出于多种目的,如原地数据修改、并发编程、数据共享优化、内存使用优化以及支持接口和多态性。虽然指针功能强大且被广泛使用,但必须谨慎和明智地使用它们,以避免诸如空指针解引用导致的 nil panic 等常见陷阱。 nil panic 问题 nil panic 是指程序尝试解引用一个 nil 指针时发生的运行时 panic。当一个指针为 nil 时,意味着它不指向任何有效的内存地址,尝试访问它指向的值将导致 panic(即运行时错误),错误信息如图 1 所示。 图 2 显示了在实现 Go 标准库(特别是 net 包)中发现并解决的最近一次 nil panic 问题 的示例。由于在第 1859 行直接调用了方法 RemoteAddr() 的返回值上的 String() 方法,假设它总是非 nil 的,如图2所示,从而引发了 panic。当接口类型 net.

Home Assistant 小米门铃视频本地存储

小米的门铃,免费的云存储时间只有 72 小时,希望保存更多时间的视频,只能去充钱。后来网上搜了一下,通过 Home Assistant 的小米插件可以实现这样的功能。刚好家里有一台闲置的 Macbook 用来发挥余热不是刚好。其实我之前已经安装好了,只不过手残把镜像文件删掉了,这样刚好出个教程从头来一次。 Home Assistant 安装 Home Assistant 支持多种安装方案,不过他们主推的是他们自己的一款软硬件一体的方案。其实家里是有一台软路由的,不过软路由担心把网络搞出问题,还是选择使用那台闲置的 Mac。官网里面也包含了 MacOS 的安装方案。因为 Home Assistant 用的是比较低版本的 Linux 系统,所以基本都还是需要使用虚拟机。首先需要安装 VirtualBox。另外就是需要下载 Home Assistant 的镜像文件。对于虚机,有一个推荐的配置,下面都以贴图的形式展现。 这个步骤里面的虚拟硬盘,记得需要使用前面下载下来的 vdi 文件。 接着需要把虚机的网络里面去配置桥接,官方文档里面说必须要使用有线连接网络,但是我的笔记本使用 WIFI 也没有什么问题。 系统全都配置好了之后,就直接启动系统,等待系统初始化好后即可。系统初始化好后,即可进入页面 http://homeassistant.local:8123/ 。一般进入页面的时候可能还需要等待一段时间初始化。 初始化完成后,创建账户。 选择家庭地址 进入主页 以上就是 Home Assistant 的安装,主要就是一个虚机的配置,其它基本只要下一步就可以。不过这个还是只是第一步,还需要安装 HACS,它是一个插件商店,通过这个商店才可以去安装小米的插件。 HACS 安装 HACS 需要尝试通过终端去安装,我尝试过直接在虚机里面去直接执行命令,但是是不可以的。需要安装终端插件去执行命令,这里我推荐使用 Terminal & SSH 插件,比另外一款插件好用,另外一款插件总是初始化失败。在设置里面,找到 Add-ons,然后在 ADD-ON 商店里面去搜索,不过这里有一个坑是默认搜不到这个插件的,需要在设置里面把高级模式打开。 插件安装好了,可以参考官方文档去安装 HACS。按照 Terminal 插件之后就可以直接执行命令: wget -O - https://get.hacs.xyz | bash - 安装完毕后,需要重启一下 Home Assistant,可以直接在终端里面通过 reboot 来进行重启。安装重启之后,还需要在 Settings > Devices and Services > Add Integration > HACS 里面添加一下。因为 HACS 需要使用 github 去更新,你可能还需要一个 github 账号来进行配置,输入验证码后,即配置成功。

大佬,您这是在借鉴嘛

今天闲来没事看到一篇文章,感觉质量挺好的,就想翻译一下。之前写过一个将文档导出成 markdown 的插件,因为这个插件一开始是为了翻译 Medium 文章开发的,但是后来因为 Medium 的 json 接口启用了,所以这个插件后面也不怎么维护了。不搜不知道,一搜吓一跳,居然发现一个和插件差不多的插件,不会吧,这么烂的插件也有人抄?后来仔细看了一看,这个大佬应该是在借鉴我的插件,辛苦地改了几个中文。 两款插件名名字几乎一模一样,只是这个借鉴者加了一个后缀:掘金翻译计划版。不确定和掘金有没有关系,我知道掘金是有一个翻译项目的,以前我也参与过。 对比 插件介绍 我的插件 李鬼插件 代码对比 上面的简洁基本上已经展现了浓重的李鬼味道,本着客观严谨的态度,我还是去看了一下代码。 我的插件 李鬼插件 除了一个 js 文件的引用,几乎可以说是一模一样了。核心的文件是 widget.js 这个文件,这个属于插件自身的 js 文件。 从这代码对比,可以看得出这个借鉴者巨大的工作量。 总结 鄙人的这款插件是在 GitHub 上开源的,当时也是出于个人需求搞得这么个小玩意,但是没想到居然还有李鬼借鉴,还真是离谱他妈给离谱开门。大家如果有空的话,还是动一下发财的小手点一下 Report,这个李鬼插件还是下架比较好。我也联系了这个开发同学,希望他能及时下架。

如何使用 Git 撤消(几乎)任何操作

原文:How to undo (almost) anything with Git 译者:madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 任何版本控制系统最有用的功能之一就是能够“撤消”错误。在 Git 中,“撤消”可能意味着许多略有不同的事情。 当你进行新的 commit 时,Git 会及时存储你的仓库在该特定时刻的快照;之后,你可以使用 Git 返回到项目的早期版本。 在这篇文章中,我将介绍一些你可能想要“撤消”所做更改的常见场景,以及使用 Git 执行此操作的最佳方法。 撤销一个“public”修改 场景: 你刚刚运行了 git push,将你的修改 push 到 GitHub,现在意识到有一个 commit 有问题。你想把这个 commit 撤销。 撤销: git revert <SHA> 结果: git revert 将创建一个与给定 SHA 相反的新 commit。如果旧 commit 是“matter”,则新 commit 是“anti-matter”——旧 commit 中删除的任何内容都将添加到新 commit 中,而旧 commit 中添加的任何内容都将在新 commit 中删除。

Google Drive 的信息检索

对于使用 Google 全家桶的公司,Google 文档类的信息泄露也时常发生。出现这种情况主要的原因是文档的权限设置问题,用户可能将文档配置为 anyoneCanFind, anyoneWithLink, domainCanFind, domainWithLink,这四种权限都属于比较公开的权限。后两个属于在域内可以查看到文档,一般来说也是不提倡如此设置,尤其是文档中包含敏感信息的。 Auth 如果要使用 Google Drive 的 API,毫无疑问,Google Workspace 的 Auth 则是第一步。对于 Auth,一般可以通过 OAuth 或者 service account 来进行实现,但是 service account 有一个问题是,默认这个 service acount 并没有赋予这个 servive account 这个域内所有资源的访问权限。必须要将这个文档分享给 service account,它才可以访问。这将会影响到对于 domainCanFind 以及 domainWithLink 的文档的搜索。解决办法是需要 delegate domain-wide authority,相当于是对于这个 service account 进行额外的授权,详细的介绍可以参考这个文档。当然,这个授权需要管理员账号来进行,如果申请比较麻烦的话,还可以通过使用 OAuth 的方式来进行认证,这也是 Google Drive API 文档指引中介绍使用的方式。 通过 OAuth 来使用 Drive API 也需要三个步骤: 启用 API 配置 OAuth 应用 生成 Credentials 详细介绍可以参考谷歌的文档介绍,基本上每一步都有详细的介绍。建议可以按照文档的方式来进行操作,OAuth 生成方式会用到一个 credentials.json 文件。如果对 OAuth 流程比较了解的话,应该知道流程中会有一个授权的流程。Go 的官方文档已经提供了一个授权的 demo,通过运行代码可以获取 autorization code,通过 aurhorization code 可以生成 token.

菜腿的骑行通勤

现在,自行车骑行越来越流行。B 站上经常可以刷到各种骑行的视频。当时,就想着平常上下班开车特别堵车,骑自行车既可以通勤,还可以减肥,一举两得。选车的时候也没有特别讲究,都说迪卡侬售后比较好,平常也喜欢在迪卡侬瞎逛,在店里也稍微试骑了一下。三月份的时候就直接在迪卡侬买了最基础的公路入门车 rc100。选的是到店自提,有 100 块的优惠券,加上安装了站脚和水壶架,差不多 1700 多一点。虽然说这个车一直涨价到 1799,但还是非常火的入门公路车之一。推荐到店自提,自己安装可能还是有一点麻烦,自提会省心不少,还可以帮你把配件也一起安装了。 好多人一买车了,就各种装备,比如码表、自行车灯、手机支架等等。考虑到自己只是上下班通勤而已,才买的时候还偶尔出去骑行一下,但是后面除了上下班,基本也不骑。高德地图足够使用了,可以记录速度和里程,用来统计骑行继续就基本够用了。自行车灯买过一个,可是还没用几天,就被人偷了。手机支架就多多买了一个很便宜的硅胶支架,还挺稳,手机没有掉过。在迪卡侬买过一个骑行裤,但我感觉似乎并没有什么用,穿着也不是特别舒服,不知道是不是因为买的不够贵的原因。一般如果骑行不超过两个多小时的话,应该也不太需要骑行裤,而且骑行裤通勤的话也不太方便。 对于我个人而言,自行车在通勤上更加有优势一点。如果开车去公司的话,路程15公里左右,大多数情况早上基本都要 50 分钟多,遇到更堵的时候甚至要一个多小时,也是家常便饭。遇到最夸张的一次是堵了我将近两个小时。另外,开车去公司还要交停车费。自行车通勤,现在基本稳定在40分钟左右,最快的记录 36 分钟,通勤距离将近 12 公里。通勤时间上来说,自行车比开车其实还更节约时间。 后来从三月份开始就基本断断续续用自行车通勤,一般不下雨的时候骑自行车,下雨就开车。梅雨季那段时间,雨水比较多,那段时间基本都是开车。下雨的时候骑自行车还是挺不方便的,后来买过一款迪卡侬的徒步的雨衣,99.9,使用过一次,基本还能用。但是如果是那种大雨,其实本身骑行雨衣基本就不太管用了。另外,骑行的比较重要的装备就是手套了。不仅可以防晒,握车把会舒服一些,而且万一摔了的话,对于手掌还有一点保护。骑行一共就摔过两次,一次是前面的电动车突然急刹车,另外一次是电动车自己骑太快滑到了把我撞到了,还好两次我基本都没有受伤。骑行的时候还是需要注意安全,不要骑行过快,和他人要保持安全距离。另外就是往旁边移动的时候,一定要先往后面看看。 市区通勤的话,路况还是比较重要的。公路车比较吃路况,但是现在路面经常各种各样的补丁,导致骑起来非常不舒服。另外就是红绿灯多的话也非常影响配速,后来自己摸索了一条路,基本是最快的,这个是地图导航没有的路线。大部分的公路车用的都是法式嘴,也是这一次我知道了有法式嘴、英式嘴、以及美式嘴。英式嘴比较古老,以前那种老式自行车使用的,美式嘴最通用,汽车以及一般的电动车都是美式嘴,而公路车一般用的都是法式嘴。法式嘴的特点就是细长,并且把塑料帽拧下来之后还要把上面的金属帽拧松。之前一开始补气的时候一直打不进去,后来才知道是这个原因。 夏季骑行最大的困难就是太阳比较大,比较热。前面的一段时间基本都放弃不骑了,太热就不想骑。后面,上海的一场大雨把我四个轮子和两个轮子的电动车都跑坏了,就只能骑自行车了。现在习惯了,感觉骑行太舒服了,那种破风疾驰的感觉实在太爽。早上六点多的时候是骑行最舒服的时候,不热并且太阳也基本没有,我偶尔起来的早的话,就直接出发去公司了。本来是买了迪卡侬的渔夫帽遮阳,但这个渔夫帽有一个问题就是帽檐经常被风吹到上面或者下面,吹到上面不能遮阳,吹到下面遮挡视线,不太好用。后面入了洛克兄弟的骑行帽,可以把脸部和脖子全部遮挡。有了悍匪造型的加成,现在骑行感觉没有一点问题。 如果你的通勤距离和我类似,建议你可以试试自行车通勤。可能比开车或者地铁更加方便快捷。当然说到最开始的初衷,减肥,反正我是一点也没瘦,自从骑车后,就比以前更饿,吃得更多,没有长胖就已经不错了。

GitHub 更新了 RSA SSH host key

今天在 push 自己 GitHub 仓库代码的时候遇到了报错,后来发现是 GitHub 已经将 RSA SSH host key 进行了更新。依据官方博客,GitHub 于 3月24日 05:00 UTC 时间 由于安全原因将 RSA SSH host key 进行了更新。主要是为了避免 GitHub 用户的 git 操作被任何不法分子监听。这个变更仅影响基于 RSA 的 SSH 协议使用 GitHub 进行 git 操作的用户。变更也只影响 RSA 算法,不影响 ECDSA 或者 Ed25519 用户。 GitHub 这周发现了他们的 RSA SSH 密钥在公共仓库中暴露。根据他们的调查结果,这个问题暂不涉及 GitHub 任何系统或者用户信息被窃取。依据他们的解释是保险起见进行 host key 的更新。 报错信息可能如下: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

行车记录仪对比 - 盯盯拍mini5 vs 海康威视C8

最近把之前的盯盯拍 mini5 行车记录仪换下来了,换了海康威视 C8。这两款行车记录仪都是小鹏官方商城里面的行车记录仪,之前卖的是盯盯拍 mini5 和 mini3,但后来不知道盯盯拍就下架了。下架之后只有海康威视的这个型号。我算行车记录仪的重度用户,经常拿来举报违章,所以好用的行车记录仪非常重要。盯盯拍是市面上比较受欢迎的 4K 行车记录仪之一。使用将近两年的时间,基本没有什么特别大的毛病,不过前段时间在老家行车记录仪经常重启,可是回到上海之后又莫名其妙正常了。不过还是购入新的海康威视的让售后帮忙安装,因为网上关于这两款行车记录仪的对比评测不算特别多,所以分享一下对于这两款行车记录仪的使用对比。 外形 盯盯拍:⭐⭐⭐⭐⭐ 海康威视:⭐⭐⭐ 因为网上都有两款行车记录仪的照片,这里就不再贴图。行车记录仪的屏幕个人觉得特别鸡肋,因为行车记录仪只是作为记录使用,屏幕并没有什么作用,可能还会干扰视线,浪费电能。这两款行车记录仪都是不带屏幕的。盯盯拍 mini5 体型比较小,外形比较好看,质感比较好一些。不过这样带来的负面影响就是散热比较差,夏天特别烫手。有的时候可能会因为高温重启。海康威视相对来说体积大一些,散热好一些,镜头可以上下调节。但这一点基本上也没大的区别,因为行车记录仪一旦安装之后也不需要调整镜头。 新的行车记录仪是让小鹏的售后安装的,安装的比较整洁,线材都埋在了摄像头的盒子里面。当然也是因为三目摄像头的原因,记录仪也安装在比较靠下的位置。但是颠簸路面的状况会有一点点异响,可以接受。 APP 海康威视:⭐⭐⭐⭐⭐ 盯盯拍:⭐⭐⭐ 行车记录仪的 APP 对于行车记录仪来说特别重要,因为这是使用行车记录仪最频繁的场景。海康威视有一个独特的优势就是小鹏车机里面集成了 APP,可以在车机里面使用行车记录仪。不过限制只有 P 档的时候才能使用,我觉得是比较鸡肋。因为我之前使用行车记录仪的场景基本都是打开 APP,连接行车记录仪,然后 APP 就自动下载违章视频,有空的时候再去举报。盯盯拍的 APP UI 方面设计的比较精细一点,海康威视的相对来说就比较古老一点。但是,盯盯拍每次打开还有开屏广告,没有海康威视干净。虽然看起来丑了一点,但是明显干净了很多。盯盯拍之前 APP 经常无法连接强制退出,不过后面某个版本修复之后就没遇到过这种问题了。因为两款行车记录仪都是支持 5G WIFI 的,所以下载速度还是比较 OK 的。 因为 APP 的连接原理都是手机连上记录仪的 WIFI,从连接速度上面来说,海康威视要比盯盯拍快,而且盯盯拍还经常有连接失败的情况。视频预览的形式也不一样,盯盯拍是把回放视屏连接在了一起,而海康威视则是一段段的视频,这一点盯盯拍更好一点,预览视频更直观。 成像 盯盯拍:⭐⭐⭐⭐⭐ 海康威视:⭐⭐⭐⭐ 专业的参数评测可能网上已经有对比了。按照之前盯盯拍的使用体验来说,虽然是 4K 的行车记录仪,但是如果想拍清楚车牌的话,基本上必须一个车身位的距离才能拍清楚。强光环境,或者夜晚环境,可能都会差一点。还有就是那种车速特别快的,基本也是拍不清楚的。两款记录仪参数上来说基本上一致,只不过海康威视的光圈大一些而已。成像质量最好的一般都是在隧道里面,有稳定光源的。如果希望进行违章举报的话,必须要拍清楚车牌。所以一般为了拍清楚违章车辆的车牌,可以稍微靠近违章车辆,拍清楚车牌,这样举报成功率才会高一些。 不过两款行车记录仪的图片角度来看,盯盯拍的似乎更好一点,海康威视不知道是不是因为镜头角度的问题,拍出来的画面有一点点畸形的感觉,没有盯盯拍看起来那么自然。从画面成像的角度来看我更喜欢盯盯拍。另一方面盯盯拍的图片的水印看起来也更舒服一些。 停车监控 海康威视:⭐⭐⭐⭐ 盯盯拍:⭐⭐⭐ 因为这两款行车记录仪小鹏商城里面都是降压线版本,所以都有停车监控的功能的。盯盯拍的停车监控有两种功能,一种是缩时录影,另外一种是持续录像。缩时录影就是隔几十秒拍一张,这种主要是避免行车记录仪消耗太多电量,导致小电瓶没电。但有一次我我车在停车场被蹭,通过缩时录影拍到了别人的车牌,但因为不是实时的录像,也不能作为直接的证据。所以缩时录影也比较鸡肋,基本上只能简单的录一下。持续录像的话,主要的问题就是 4K 视频占用存储比较大,可能录不了多长时间就被覆盖了。另外就是小电瓶可能经常就没电了。海康威视是只有持续录制的选项,可以选择录制的时间,但是默认也是缩时录影的形式。不过感觉海康威视的停车监控似乎比盯盯拍稳定一些,盯盯拍之前经常因为小电瓶电压的问题关闭了。 可拓展性 海康威视:⭐⭐⭐⭐ 盯盯拍:⭐⭐⭐ 这两款行车记录仪都是支持 4G 模块的。通过 4G 模块可以远程查看行车记录仪摄像头的实时画面。之前大多数新能源汽车可以远程查看的,不过去年因为数据安全的问题就被政府叫停了,现在市面上车辆的摄像头都不能直接查看了,虽然我觉得特别不合理,因噎废食。海康威视的 4G 模块可以外接,可拓展性相对来说更强一点。盯盯拍则是集成到支架上面,如果要升级的话,相对来说更麻烦一点,需要将原有的支架拆除,更换为新的支架。 存储方面,盯盯拍只支持内置存储,这也是更换行车记录仪的原因之一。因为之前买的是64 GB 的版本,64 GB 对于 4K 行车记录仪来说还是太小了,不够用。海康威视使用 SD 卡来进行存储,拓展性相对来说好一点。不过最大也就只支持 128 GB,如果可以支持到 256 就好了。

为什么 2022 年是漏洞赏金奖破纪录的一年

为什么 2022 年是漏洞赏金奖破纪录的一年 原文:Why 2022 was a record-breaking year in bug bounty awards 译者:madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 每年,GitLab 的应用安全团队 都会回顾 GitLab 漏洞赏金计划的亮点。 对于整个行业的安全团队来说,2022 年是忙碌的一年,我们很幸运收到了大量出色的报告,帮助我们确保 GitLab 及其客户的安全。 随着我们在 2021 年 11 月 增加我们的漏洞赏金奖励金额和研究人员参与度的提高,我们在 2022 年期间奖励超过 100 万美元,打破了新纪录! 如果没有我们的漏洞赏金社区的合作,我们就不会取得今天的成就,我们认为这些奖励非常有益,而且钱花得值。 2022 年的数字 在 221 份有效报告中获得总计 1,055,770 美元的奖金,高于去年的 337,780 美元! 三名研究人员在他们的多份报告中获得了 10 万美元以上的收入,另外七名研究人员的收入超过了 2 万美元。 2022年共收到424名研究人员的920份报告。 解决了 158 份有效报告并公开了 94 份 - 今年,我们收到了一些信息泄漏报告,与漏洞不同,这些报告不需要公开 GitLab 问题。 今年有 138 名安全研究人员提交了一份以上的报告,表明他们对我们的计划做出了积极的贡献。 向提交三份或更多有效报告的研究人员授予八份 GitLab Ultimate 许可证。 注:数据为截至 2022 年 12 月 16 日。

CircleCI 20230104 安全事件报告

CircleCI 20230104 安全事件报告 原文:CircleCI incident report for January 4, 2023 security incident 译者:madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 2023 年 1 月 4 日,我们提醒客户 一起安全事件。 今天,我们想与您分享发生的事情、我们学到的知识以及我们未来不断改善安全态势的计划。 我们要感谢我们的客户对于重置密钥的关注,并对此次事件可能对您的工作造成的任何干扰表示歉意。我们鼓励尚未采取行动的客户采取行动,以防止未经授权访问第三方系统和存储。此外,我们要感谢我们的客户和社区在我们进行彻底调查期间的耐心等待。为了实现负责任的披露,我们已尽最大努力在共享信息的速度与保持调查的完整性之间取得平衡。 本报告包含: 发生了什么? 我们怎么知道这个攻击向量已经关闭并且可以安全构建? 与客户的沟通和支持 如何判断我是否受影响? 可能有助于您的团队进行内部调查的详细信息 我们从这次事件中学到了什么以及我们下一步将做什么 关于员工责任与系统保障措施的说明 安全最佳实践 结语 发生了什么? 除非另有说明,否则所有日期和时间均以 UTC 报告。 2022 年 12 月 29 日,我们的一位客户提醒我们注意可疑的 GitHub OAuth 活动。此通知启动了 CircleCI 的安全团队与 GitHub 的更深入审查。