podman: macos: podman cannot be opened because the developer cannot be verified

When I try to execute podman from cli I get:

“podman” cannot be opened because the developer cannot be verified. macOS cannot verify that this app is free from malware. Homebrew Cask downloaded this file on 30 August 2019 from github.com.

The only options are “Move to Bin” and “Cancel”, and neither of them seem to provide useful.

We need to assure that podman can be installed (brew) and executed on macos, without extra tricks.

Please do not suggest disabling system security. Last time I did this was years ago. In 2019 nobody should do that. Brew installed software compiles locally and does not need signing but pre-compiled casks must use valid Apple backed signing, for good reasons.

This still seems to be valid for the latest version of podman cask as brew cask outdated does return nothing:

$ brew cask info podman                                                                                                                                                    podman: 1.6.0-28-gdac7889d
https://github.com/containers/libpod/
/usr/local/Caskroom/podman/1.6.0-28-gdac7889d (2 files, 47.4MB)
From: https://github.com/Homebrew/homebrew-cask/blob/master/Casks/podman.rb
==> Name
podman
==> Artifacts
podman-v1.6.0-28-gdac7889d/podman (Binary)

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 5
Comments: 50 (20 by maintainers)

Most upvoted comments

This occurs because macOS Gatekeeper automatically applies the com.apple.quarantine extended attribute on the binary because the application is not notarized. See the Apple support page Safely open apps on your Mac for more information.

You can see that this is the case by viewing the extended attributes of the binary.

$ type podman
podman is /usr/local/bin/podman
$ xattr /usr/local/bin/podman
com.apple.quarantine

To resolve the issue, you can manually delete the quarantine attribute and then verify that you can now run podman:

$ xattr -d com.apple.quarantine /usr/local/bin/podman
$ podman --help
manage pods and images

Usage:
  podman [flags]
  podman [command]
...

To permanently fix the issue, the app should be notarized before distribution. See Apple’s information on notarizing macOS software before distribution. There is an extended HN discussion here with additional commentary.

hickeycm on Feb 6, 2020

After running a new downloaded binary that fails on unidentified developer, open your “System Preferences” -> “Security & Privacy” and you will see close to the bottom a message saying that process was blocked and a button “Allow Anyway”. Click the button and run the binary again, and then you will be able to approve it.

Looks something like this -

guymguym on Jan 16, 2020

I am keeping this open, since MAC support is a key feature we need to fully support.

rhatdan on Dec 31, 2019

What is the podman equivalent of export DOCKER_HOST=ssh://root@some.example.com?

export CONTAINER_HOST=ssh://root@some.example.com/run/podman/podman.sock

EDIT: The /var/run is deprecated by systemd, I think I was thinking of /var/run/docker.sock 😃

lrwxrwxrwx 1 root root 4 dec  7  2018 /var/run -> /run

afbjorklund on Aug 29, 2020

Update (on the signed-installer effort): This has been pushed down one notch on my TODO list for now. I’m currently focusing on erasing some automation technical-debt. Once that’s done, I’ll get back onto this effort. For end-users, debugging/playing, the solution @ashley-cui invented will hopefully be adequate. (thanks Ashley)

cevich on Aug 28, 2020

@ssbarnea try

brew cask uninstall podman 
brew install podman

Podman is now available through brew, not brew cask, and should not have the signing issue now.

ashley-cui on Aug 28, 2020

I hope this is not really stale. Having podman in macos is critical for it to become mainstream.

ssbarnea on Aug 6, 2020

Update: finished adding integration tests, and am now working on getting them merged in. I have some administrative tasks to attend to this week. So that will likely slow me down in terms of bringing up usage of my work under libpod.

cevich on Apr 7, 2020

Update: Got the proof-of-concept ported yesterday but noticed a rather large gap in my testing for it. I considered leaving it as good-enough. However, this github action / cirrus-ci interaction stuff is really tricky and non-obvious in it’s operation. So I’m going to take another day or two to add an integration test for it (a full compliment of unit-tests is already in-place). This will help validate any future changes such that they don’t break the most difficult and tricky, of all the tricky bits.

cevich on Apr 1, 2020

But gave up on the download links or releases, and made my own.

That’s the right thing to do.

I was wondering whether there are any updates on this.

Thanks for the reminder. Yes, I’ve been up to my eyeballs in this for the last few weeks. I’ve made quite a lot of progress solving the really difficult and security-sensitive challenges I mentioned above (relating to automatic but safe signing/certifying builds). It ended up requiring some tricky interactions across both the Github and Cirrus-CI GraphQL API’s, so I took additional time wrapping the whole thing up with lots and lots of tests.

As of today, I’ve finished the proof-of-concept and started porting a functional-prototype over to a new containers/automation repository. I’d like to finish that work by tomorrow. The next step is to begin using it in this repository, as the backbone for automatically building and uploading releases. Once that’s working to a basic degree, I’ll poke other people for some help getting the signing/certifying part implemented under Windows/MacOS (since I’m a moron WRT those platforms).

cevich on Mar 30, 2020