TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Git archive generation meets Hyrum's law

136 点作者 JamesCoyne超过 2 年前

13 条评论

pcj-github超过 2 年前
If it can't be made stable, `git archive` should specifically add random content (under a feature flag to be removed after a year or two) to so as to make the generated checksum completely unreliable and force users to adopt different workflows.
评论 #34636252 未加载
评论 #34635085 未加载
评论 #34636037 未加载
skywal_l超过 2 年前
Everybody who had to maintain an API knows this.<p>1. You can&#x27;t just rely on documentation (&quot;we never said we would guarantee this or that&quot;) to push back on your users&#x27; claims that you introduced a breaking change. If you care more about your documentation than your users, they will turn their back on you.<p>2. However if you start guaranteeing too much stability, innovation and change will become too costly or even impossible. In this instance, if the git team has to guarantee their hashes (which seems impossible anyway because it depends on the external gzip program) then they can never improve on compression.<p>Tough situation to be in.
评论 #34634275 未加载
评论 #34644245 未加载
评论 #34640827 未加载
mjw1007超过 2 年前
I don&#x27;t think this is really an example of Hyrum&#x27;s law. Hyrum&#x27;s law claims that even if you carefully document your contract, someone will rely on the observable behaviour rather than the documentation anyway.<p>But this is an example of a much weaker proposition: if you don&#x27;t document your contract, then people will guess what the contract is and some of them will guess wrong.<p>(In fact in this case it seems it&#x27;s more like &quot;if you don&#x27;t document your contract and your support staff sometimes say the behaviour is A, people will rely on the behaviour being A&quot;.)
评论 #34640658 未加载
vlovich123超过 2 年前
I wonder if transfer encoding the archive might be a better strategy. The client benefits from a stable format (tar) provided it’s generated in a stable order which generally easier for the server to guarantee. The network transfer occurs transparently compressed (transfer-encoding header in http parlance).<p>Checksums still work and protect against malicious tarballs which are generally riskier to unpack than plain steam compression &#x2F; decompression. The server and client gets the smaller file transfers and compression improvements can evolve transparently by negotiating the transfer encoding. The server can still cache the encoded form to avoid needing to compress the same file repeatedly.<p>Seems like a win win solution without requesting a drastic redesign of package managers everywhere and everyone walks away having won the properties of the system they value.
评论 #34638391 未加载
jancsika超过 2 年前
&gt; Hyrum&#x27;s law<p>Didn&#x27;t Google beat Hyrum&#x27;s law by using their weight to force middleboxes to accept some variation in some datum of an http header or something?<p>Edit: hint: something about rotating a value for some number of decades. Either forcing the hand of middleboxes or CAs, I can&#x27;t remember. In either case, it seemed like a real pain in the ass to keep the API observability concrete from hardening. :)
评论 #34636729 未加载
评论 #34640823 未加载
cratermoon超过 2 年前
From the post: &quot;it may well become necessary for anybody who wants consistent results to decompress archive files before checking checksums.&quot;<p>I&#x27;m certain there&#x27;s some exploit waiting to subvert the decompress algorithm and substitute malicious content in place of the actual archive files.
评论 #34636764 未加载
评论 #34636973 未加载
DelightOne超过 2 年前
Can&#x27;t Github just keep the old archive as it is for the already-existing releases and use the new format for new releases? Over time old releases phase out and the advantage of the new format is completely in effect. You can even use a time-based cut-off date if you somehow want to get it in sync.
评论 #34636314 未加载
评论 #34638170 未加载
评论 #34636266 未加载
评论 #34638402 未加载
评论 #34637085 未加载
AJRF超过 2 年前
HANG ON!<p>I think this just made me realise an issue I was having with Swift Package Manager a few months back. We have a bunch of ObjC frameworks in our app that we don&#x27;t want people to update anymore so we can rewrite them, and we just threw them all into a big umbrella project, but for some reason we couldn&#x27;t get the binary target URL from Github Enterprise to work on our self hosted Enterprise instance because the checksum would be different every time, but it worked perfectly for Github Cloud.<p>Is there anyone from Github here - Can you confirm that is the cause of issue for GH Enterprise?
评论 #34637187 未加载
travisgriggs超过 2 年前
Had to follow the links to figure out what Hyrum’s Law was (I like laws). The best link from that law is the obligatory xkcd at the very bottom. Reshared here:<p><a href="https:&#x2F;&#x2F;xkcd.com&#x2F;1172&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;1172&#x2F;</a>
评论 #34634478 未加载
评论 #34633503 未加载
meling超过 2 年前
Couldn’t they include two checksums; one for compressed, and if that fails, decompress and check the uncompressed content?
评论 #34640522 未加载
avgcorrection超过 2 年前
Mob engineering: you don’t have to read the documentation if a million other people also do not.
评论 #34634503 未加载
评论 #34636608 未加载
评论 #34634763 未加载
syntheticnature超过 2 年前
2018 Gentoo-dev called, wants to let you know this is old news: <a href="https:&#x2F;&#x2F;www.mail-archive.com&#x2F;gentoo-dev@lists.gentoo.org&#x2F;msg82037.html" rel="nofollow">https:&#x2F;&#x2F;www.mail-archive.com&#x2F;gentoo-dev@lists.gentoo.org&#x2F;msg...</a>
评论 #34633372 未加载
评论 #34637295 未加载
评论 #34632949 未加载
jmclnx超过 2 年前
&gt; more easily support compression across operating systems<p>I cannot help but wonder if this change was forced upon github by Microsoft because gzip is GPL 3, maybe this other version is a clean room clone. We all know corporations hate GPLv3, including the large corporation I work for.<p><a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;gzip&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;gzip&#x2F;</a>
评论 #34633117 未加载
评论 #34633047 未加载
评论 #34632953 未加载
评论 #34639523 未加载