spring-ai-alibaba 提交代码把 key 提交了，发现还真能用，用了半天后刚刚终于失效了
https://github.com/alibaba/spring-ai-alibaba/commit/3941921f4af865b7820db949dcc076413c53de73
72 条回复 • 2025-05-30 16:35:46 +08:00
 |
1
SodaPopBoy 8 天前
外面看笑话，里面腥风血雨
|
 |
2
gangstar902 8 天前
草台班子
|
 |
3
BeautifulSoap 8 天前 via Android  10
我都不用猜，肯定是设环境变量嫌麻烦直接临时硬编码改配置，改完后一套无脑
git add . git commit git push 丝滑小连招导致的🤣 |
 |
4
exploretheworld 8 天前 via Android
世界是个巨大的草台班子
|
 |
5
Meld 8 天前
commit 写的很烂啊
 |
 |
6
crocoBaby 8 天前
跟想象中的超级大厂不一样
|
 |
7
hahastudio 8 天前
讲道理，这不应该清 history 么，为啥是 PR/commit
|
 |
8
SilenceU 8 天前
@hahastudio 已经泄漏了，当然是重置 key 了
|
|
9
hahastudio 8 天前
@SilenceU 重置 key 是肯定要做的，但 git history 也应该清理啊
|
 |
10
wu00 8 天前
@hahastudio #7 为什么要清呢，掩盖问题么？
|
 |
11
coolcoffee 8 天前
安全和方便就像鱼和熊掌不可兼得。
我曾经接手过一个别人写的 java spring 项目，一拿到源码，里面一看 dev 、test 、prod 的配置都在里面，一键使用起来的确很方便。哪像我之前维护的项目，每启动一个环境就到处找环境变量配置。 |
 |
12
ano 8 天前
太正常了，下次还有
|
 |
13
irrigate2554 8 天前
@hahastudio 没有清的必要，强制 push 不可取
|
 |
14
craftsmanship 8 天前 via Android
@coolcoffee 吐血 环境变量是真的难找 文档缺失的情况下 从哪来的根本摸不着头脑
|
 |
15
guanzhangzhang 8 天前 14
工作越久就发现世界就是个草台班子，有技术和细节追求的人很少，大部分人只是个上班的，无法教导所有人的
|
 |
16
k9982874 8 天前
@hahastudio #7 一般开发不可能有 force push master 的权限，那么为啥组织甚至部长要给 Aias00 擦屁股？
|
 |
17
anivie 7 天前 1
阿里著名草台班子了，闹过的乐子太多了
|
 |
18
nanrenlei 7 天前
这种很正常，测试用的 key ，提交的时候忘了删除了，但是一般都应该写到配置文件里，这个配置文件是忽略的
|
 |
19
dddd1919 7 天前
还试图用 commit 改掉配置，更乐子了
|
 |
20
chesha1 7 天前
@hahastudio #7 用 force push 清了也没用，可以在 activity 里查到，除非把整个仓库删掉重建
|
 |
21
dynastysea 7 天前
@crocoBaby 再大的厂也不排除有蠢货啊。。已经反反复复的强调这种事情，有些人就是不在意。甚至提交代码都有钩子检查，这些人也不注意。只能说活该。等着受处分了
|
 |
22
me1onsoda 7 天前
@hahastudio #9 清除有什么意义?维护大厂的脸面?
|
|
23
me1onsoda 7 天前
这人什么级别,提交代码没人审核?
|
 |
24
Biggoldfish 7 天前 4
这跟人蠢有什么关系，正常情况应该是有自动检测根本没法 commit 的。是个人都会犯错，不去检讨流程而是检讨员工那才是更大的草台班子
|
 |
25
nenseso 7 天前 2
没人能保证永远不写 bug 的，出了事应该立刻想办法从流程上去规避，而不是骂别人是蠢货
|
 |
26
yb2313 7 天前
我私人仓库一直是硬编码, 也想过用环境变量, 但再一想就我一个人用用鸡毛环境变量, 一把嗦多轻松快乐
|
 |
27
chengkai1853 7 天前
这很正常吧。不就测试的 api key 提交了，后台重置 key 就行了，又没有任何风险。
|
 |
28
imnpc 7 天前
从配置文件调用参数和 key 不是基本要求？就算是新手入职也要培训下这个
|
 |
29
Artemisr 7 天前 25
大家好，我是 spring-ai-alibaba 社区的贡献者，这个 pr 是我提交的内容。我是一名外部贡献者，非阿里内部员工。
这次提交的 key 是我个人账号申请的免费测试 key 。 昨晚上因为处理问题过程中，检查疏忽了导致出现了这次的问题，今天上午发现之后也是优先选择了失效 key ，然后还原代码重新提交了。 也是社区的其他贡献者给我转发了这个帖子，我才知道原来大家已经拿我的事情当乐子来看了。 由于这种事我也是第一次遇到，所以处理问题的方案未必是最优解，也希望大家能够理解吧 |
 |
30
devilte 7 天前
 以为楼上是预言，没想到是真的  |
|
32
me1onsoda 7 天前
原来是社区贡献者.没参与过开源贡献,一般的社区贡献者也有权限可以直接 merge 到主分支上吗?这不怕人捣乱吗?
|
 |
35
jackerbauer 7 天前
谁不犯错啊，正常正常，大家都是草台班子的一份子
|
|
36
Artemisr 7 天前
我更多还是觉得开源社区的氛围是我比较喜欢的，我愿意花时间投入到社区贡献当中，属于是为爱发电了。
花时间投入当然是为了让社区能向好的方向发展，如果因为我个人导致了不好的事情，那我难免会愧疚的 |
 |
37
fy718 OP @Artemisr 大佬，还有个错没改啊，配置文件里的 toolcalling: weather: enabled: enable ，这是 true ，不是 enable 啊，用 enable 代码不起效果，你昨天把 true 改成了 enable 。。
|
 |
42
kzfile 7 天前
阿里内部的 git 统一做了配置，我记得不会把各种 key 提上去，因为出过事
|
 |
44
Aitisikuoliv1d 7 天前
外包/临时工又主动出来背锅了 怪不得每次出事都是这个说辞 看来是真管用
|
 |
45
jiangbingo 7 天前
这是 main 分支啊，branch pull_request 到 main 和 code review 环节都没有的吗？
|
|
46
jiangbingo 7 天前
@kzfile git merge 到 main 的时候工作流定义里至少要有两步骤吧？自动化 review 和人工 review 。
|
|
47
jiangbingo 7 天前
@me1onsoda 自动化审核就能规避，说明没有设置 git 自动化审核规则。
|
 |
49
yiton 7 天前
这个框架好用么
|
 |
50
yingqi1 7 天前
特地搜了一下，没有看到 pre-commit / hook 之类的 secret scan.
|
 |
51
hllpark 7 天前 11
大家好，我是 Spring AI Alibba PMC 成员，GitHub ID chickenlj 。
首先，非常感谢大家对我们项目的关注和善意提醒，这次确实是我们在开源流程中的一次疏忽。还好发现得及时，没有给 Aias00 造成实际的财务损失。 Aias00 作为 spring-ai-alibaba 的重要协作者之一，为开源社区做出了很大的贡献， 在这里也感谢 Aias00 和其他贡献者对开源社区的支持。 我本人作为一名长期贡献开源的普通人，过去也犯过类似错误，处理的时候实际上挺慌张的，感谢各位的理解，我们非常珍视每一个为开源社区付出的贡献者的努力。 大家关于项目流程的建议都非常好。理论上，GitHub 的 Secret Scanning 应该能检测到类似问题，但这次没有生效，我们会进一步排查原因。 接下来，项目 PMC 成员们会一起商量如何强化此类流程检查，规范项目协作，防止类似事情再次发生。 也欢迎大家多多使用 spring-ai-alibaba 以及阿里的其他开源产品，提出宝贵意见。如果能参与代码贡献就更好了：） |
 |
53
ttyy22007 7 天前
@Aitisikuoliv1d 人家正主不是自己出来解释了么，咋还搁这儿阴谋论呢
|
 |
56
edcopclub 7 天前 via Android 2
之前 leader 一直要求代码至少要看 3 次，每次给他提 pr 时候都会问我次数看没看够。保持这个习惯之后，错误真的能减少很多。
|
 |
57
y1y1 7 天前
多大点事
|
 |
58
FrankAdler 7 天前
@Artemisr 我非常好奇，你写的代码不会在提交的时候再自己检查一遍吗，但凡不是工具生成的，而是亲手写的，都需要检查下吧。
|
 |
59
kkk1234567 7 天前
哈哈，这个帖子都有公众号截图，作为罪证去了。
士风日下，人心不古 🐶 |
 |
60
cherrychen 7 天前
是不是操作的时候 git add . 然后 commit 了
|
|
61
FrankAdler 7 天前
@FrankAdler 我再逼逼几句，大部分写代码的人都多用点心呗，提交之前自己 review 下，那种临时注释掉，方便调试的修改，但凡检查下，都不会提交到仓库，包括我所在的公司很多人，写完自己简单测试下好像没问题，就提交了，一堆文件，哪些修改是真有用的，哪些没有也不管，出了问题再提交去修正，不觉得太低级了吗？不觉得污染历史记录吗？
典型的案例：我们有个系统，入口文件做了鉴权，本地调试的时候自己构造不出来带有效期的 token ，所以调试起手就是把鉴权那一行注释掉，然后就有人把他提交上去，拜托，不罚你个开除就不长记性是吧，动动脑子看一眼就知道那一行能不能提交。 |
 |
62
Yadomin 7 天前
虽然是外部贡献者写的，但是你们合代码都没有 review 出来吗
|
|
63
Artemisr 7 天前
@FrankAdler 谨遵教诲，我下次注意
|
 |
64
duanzhanling 7 天前
@crocoBaby 哈哈，你想多了
|
 |
65
Hyxiao 7 天前
git 在提交的时候不是会对这种密钥属性的 key 进行提醒，不允许提交的吗
|
 |
66
ca2oh4 7 天前
阿里竟然没有 git pre check
|
 |
67
csfreshman 7 天前
@Shatyuka 绝了，第一句 alibaba 就打错了，哈哈哈哈
|
 |
68
ciki 7 天前 1
多大点事，现在的人天天在这装圣人吗？自己不会犯错？
|
 |
69
realpg 7 天前
@BeautifulSoap #3
我们也嫌设置环境变量麻烦 但是我们都是 .env.sample 然后.gitignore 里忽略 .env.dev .env.testing .env.release .env.production |
|
70
BeautifulSoap 7 天前 via Android
@realpg 那么请问 假设 .env.testing 用于本地调试，里面原本放着平时开发主要用的 key ，这时候因为开发调试需要，要临时修改.env.testing 换成另一个 key 调试一两天然后换回来，偶尔可能还要再换回去。因为你.env.testing 添加了 ignore 那么就没有版本控制，如何恢复被覆盖的原本的 key ？
当然解决方法多的是，找个笔记记录下原本的 key ，或者复制一份 env 再恢复。但最简单粗暴的还是直接硬编码，然后在提交代码之前不 stage 这个变更就行。当然，这次阿里这事是最后一步玩脱了 |
 |
71
realJamespond 6 天前
@BeautifulSoap .env.testing1 ， .env.testing2 ， .env.testing3 。。。这样？
|
|
72
BeautifulSoap 6 天前 via Android
@realJamespond ummmm ，那么如何切换 env 文件？一般通过一个比如叫 APP_ENV 的变量比较多吧。APP_ENV=testing1 或者 APP_ENV=testing2 这样来决定使用什么 env 文件
那么问题来了，绕了一圈，最终问题又回到了怎么管理 APP_ENV 这个环境变量上了 |
Select Language