3 ms·
To me it hardly sounds like a problem for code-signing in general either. You presumably don't need to sign your binaries during development, so you'll only be
by ryanlol 9y ago
To me it hardly sounds like a problem for code-signing in general either.
You presumably don't need to sign your binaries during development, so you'll only be signing them when pushing updates to prod. I don't know how often and how urgently you usually do that, but it sounds like a small delay in pushing out prod builds caused by a timestamp server issue wouldn't be much of a problem to most orgs.
- josteink 9y agoIt’s often a nesting/dependency problem which is hard to solve after the fact. A website may depend on libraries, which depends on other libraries. They must all be signed. They are all interlinked against a known version during build, and signing them after linking may not be an option. The website may offer a download, which is probably a setup file of sorts, which must be signed. It will of course contain binaries, which must be signed too. The website itself may also be something packaged in another setup file, which too must be signed. Now how do you “just” sign something like that before releasing to prod? You don’t. Signing (and time stamping!) must be a intergrated part of every step of the build process. It takes more work than you would expect to get this done properly, systematically and reliably for every part of your build process. It does take effort and expertise. That said, for certain build-types (like pure CI) we disable things like timestamping. We’re not crazy :)