28 comments

[ 5.1 ms ] story [ 73.3 ms ] thread
The code signing process has sucked and always been deeply cryptic, even on macOS - getting something usable and improvable that's cross platform is a fantastic win.
(comment deleted)
(2022)
Yes please add 2022, because when I looked at the PR, I was wondering why it took nearly 2 years to release after the PR was merged.
Added. Thanks!
this is great. I remember having to write a build system that fulfills Apple's shitty requirements for signing on their service, and it sucked hard.
Thanks! Macroexpanded:

Achieving an open-source implementation of Apple Code Signing and notarization - https://news.ycombinator.com/item?id=32386762 - Aug 2022 (51 comments)

Off topic but I've seen you mention "Macroexpanded" a lot of times, is it something regular users can do, and how?
From one I’ve understood, that’s referring to Lisp code that runs as dang and automatically makes this sort of reply where it takes links to stories that people comment, and it replies with title of story, month and year it was posted and number of comments.

Only dang can do that sort of thing. Not us mere mortals.

I've wondered too if it was automatic or something dang runs (or triggers) manually. It seems like it only runs on a small percentage of them, usually the more popular stories, so I tend to think it requires some manual intervention on his end.
(comment deleted)
> Not us mere mortals.

A javascript bookmarklet could likely extract that text for clipboard copy.

I mean specifically the ability to run Lisp code server side on HN
Comments posted by my account are always ones that I personally write and personally post. Never automatic. Even though a lot of the moderation comments are repetitive to put it mildly, it would feel wrong to do it any other way.

I do have software the makes it easier to find past threads and to create the text of the form Title - link - month/year - number of comments, as well as to speed up countless other repetitive tasks, but it's all software that I'm using personally.

I think you should definitely automate this. I've seen browser plugins do it - so it could be done entirely with javascript if you don't want to mess around with Arc.
I think it's literally just dang typing out the title and giving more context.
It's basically just a joke, so yes, everyone can do it.

I do have the idea, though, of letting the software offer to macroexpand people's links to past HN threads in this way (i.e. turn a raw link into an annotated one that mentions the title and date of the thread, and number of comments - because this makes the links more useful to the reader, who can more clearly decide whether to click or not). So maybe it will be more than a joke someday!

Okay :-)

Thanks for your answer. Yep, sounds like a good idea. Or links could be automatically expanded like this when they appear on their own lines, possibly with a "[...]" footnote prefix.

(comment deleted)
How does signing work here? You submit a certificate to Apple which validates who you or organization. Then with your “signed” app, end users can see its source come from you or organization.
Basically. The first part is creating a certificate request for a developer certificate, then apple creates a signing certificate for you. Then each executable part of your distribution needs to be signed with that signing certificate.

The second part is the notarization. This is where you upload a .zip, .pkg, or .dmg to apple and they build a hash of your distribution and serve that to folks through gatekeeper. You can also staple the notarization to the package and then you don’t need to talk to the apple servers.

This way apple can revoke your notarization and users will get warnings about your software being maleware.

Title is a bit confusing in that this doesn't seem to be a open source implementation of the actual notarization process. It's "just" a tool which talks to Apple servers to handle the notarization (if I'm reading this right: https://github.com/marketplace/actions/apple-code-signing). I guess the main advantage over Apple's tool is that it also runs on Linux and Windows.
We have an enhancement opened with Apple to have a way to delete .cstemp files if the tool runs into them. You'd think we could just add a `find . -name '*.cstemp' -exec rm {} \;` to our build toolchains before building, but we're in a large mono-repo and that would add a lot of time to our builds. Having something like a `--force` to delete the .cstemp files instead of quitting and reporting an error would make us change to this tool pretty quickly I'd think.
Have you tried doing `find . -name '*.cstemp' -exec rm {} +`? This provides as many arguments (filenames) as possible to the executed command (rm) rather than the `\;` which executes the command per file. This provides a massive speed improvement.