Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

“asciidoctor-web-pdf” cannot be opened because the developer cannot be verified. #455

Open
wh81752 opened this issue Apr 14, 2021 · 7 comments

Comments

@wh81752
Copy link
Contributor

wh81752 commented Apr 14, 2021

After downloading https://github.com/Mogztter/asciidoctor-web-pdf/releases/download/v1.0.0-alpha.12/asciidoctor-web-pdf-mac-v1.0.0-alpha.12.zip on MacOS Catalina (10.15.7) and extracting into local folder I'm not able to run it. I'm getting

“asciidoctor-web-pdf” cannot be opened because the developer cannot be verified.

@wh81752
Copy link
Contributor Author

wh81752 commented Apr 14, 2021

Btw, workaround is this one:

$> xattr -d com.apple.quarantine asciidoctor-web-pdf

@ggrossetie
Copy link
Owner

Btw, workaround is this one:

I didn't know this command, nice trick!
You can also authorize it in System Preferences > Security & Privacy, under the General tab. Click "Open Anyway" to confirm your intent to open or install the app.

Reference: https://support.apple.com/en-us/HT202491

"asciidoctor-web-pdf” cannot be opened because the developer cannot be verified.

The reason is that the binary is not notarized/signed. In order to notarize/sign an application, Apple requires an active subscription to their Apple Developer Program (99$/year).

In order to publish the Asciidoctor browser extension on Safari, the Asciidoctor community has decided to subscribe to the Apple Developer Program.
So, in theory, it should be possible to sign the application.

Since the release is automated, we will need to integrate the signing process using GitHub Actions. Apparently, it's possible, I found two articles:

Feel free to integrate the signing process in https://github.com/Mogztter/asciidoctor-web-pdf/blob/master/.github/workflows/release.yml. I can follow-up and by adding the secrets and testing.

@ggrossetie
Copy link
Owner

In the meantime, we can also improve the documentation to state how to workaround this warning message.

@ggrossetie
Copy link
Owner

@wh81752 I will probably give it a try this weekend unless you are already busy working on it?

@wh81752
Copy link
Contributor Author

wh81752 commented Apr 22, 2021

@Mogztter - please go ahead. Otherwise I will give it a try upcoming week. Right bit busy.

@ggrossetie
Copy link
Owner

Unfortunately it does not work because binaries created by pkg cannot be signed using codesign: vercel/pkg#66
It's also a bit tricky since we include Chromium and apparently we also need to sign Chromium binaries... sigh

As mentioned in a comment, it's possible to download and extract the archive using curl + unzip. In this case, macOS won't verify the binary:

curl -sL https://github.com/Mogztter/asciidoctor-web-pdf/releases/download/v1.0.0-alpha.12/asciidoctor-web-pdf-mac-v1.0.0-alpha.12.zip -o asciidoctor-web-pdf.zip
unzip -qq asciidoctor-web-pdf.zip -d asciidoctor-web-pdf-v1.0.0-alpha.12
rm asciidoctor-web-pdf.zip
./asciidoctor-web-pdf-v1.0.0-alpha.12/asciidoctor-web-pdf --help

@wh81752
Copy link
Contributor Author

wh81752 commented May 4, 2021

@Mogztter - Too bad.

Perhaps it's just fine to update the docu how to get going on MacOS:

  • (a) Download package and removecom.apple.quarantineon all files ; or
  • (b) use curl + unzip; or
  • (c) install via npm

Remarks on curl+zip:

  1. curl is indeed install by default on MacOS while wget is not. Therefore curl.
  2. curl+zip requires cannot be piped - that's why three command lines are necessary. TAR on the other hand could be piped and is also installed by default on MacOS while TAR is absent on Windows
  3. unzip -qq asciidoctor-web-pdf.zip is fine by now (thanks to resolves #456 add a root-folder in distribution bundles (zip files) #460) :-)

Remark on Chromium:

There has been a security update recently on Chromium, see https://www.debian.org/security/2021/dsa-4911. How would users update their installation in respect to such a security update? My idea is to exclude Chromium from the package and rather install during a post-install action (perhaps by a simple script).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants