lldb ...

[René J.V. Bertin]

On Monday September 05 2016 16:23:23 Rainer Müller wrote:

> I see no problem in generating certificates automatically. We also add
> users to the system or create launchd configurations without forcing the
> user to do it manually.

Yeah, exactly, I'm not really comfortable with adding users to the system either. Adding launchd configurations is a bit different, those are just files that can simply be suppressed/edited, and they're unambiguously part of the content of the port that installed them.

Hmm. About that ... what if a port requiring certain binaries to be signed simply installed its own keychain file into ${prefix}/var/macports/home/Library/Keychains (or ${portdbpath}/home/Library/Keychains ?)  ? I don't think anything is stopping them from doing this right now, and I also fail to see what kind of attack vectors that could open up. Advantages:

- port maintainers can set up the keychain exactly as works best, tested locally. I'm assuming that trust settings are stored in the keychain here.
- no need to design a possibly complex system for generating certificates with the appropriate policies and trust settings
- signing is guaranteed to use the same data for everyone, making builds and installs more reproducible

> > So, why would you force an expiration date on users? Say they install
> > lldb-3.x and stay at that version for whatever reason. That port isn't
> > going to change anymore at some point, so why force people to go through
> > the hassle even of de/re-activating. That seems rather unheard of, and a
> > first step on planned and forced obsolescence (where software stops
> > working after a given date).> 
> I am not forcing it on them. x509 certificates have an expiry date. That
> is just a fact.

Doh, indeed. Hadn't noticed that that's set to 1 year if you just use the certificate assistant. Cannot even recall seeing an option to set it to something else.

> That's expected behavior. The permissions on the file itself are not
> relevant for unlinking, only permissions of the directory matter.

Ah, indeed. I hadn't noticed the inode thing when I was surprised by the owner and group changes. 
Still, it is kind of surprising that the utility accepts to sign a file that you don't own and don't have write-access to. For one thing, signing of app bundles is *not* possible when you don't have write access to the directories inside them that need to be modified (and that behaviour is just as expected).

> But yes, that means we have to take care of preserving the permissions
> when codesigning.

If we stick with the idea of specifying a signing user for the moment, this works:

{{{
                    set home [glob "~${user}"]
                    ui_info "Signing ${app} with ${identity} from ${user}'s keychains under HOME=${home}"
                    if {[catch {system "env HOME=${home} codesign -s ${identity} --preserve-metadata -f -vvv --deep ${app}"} err]} {
                        ui_error "Signing ${app} with ${identity} from ${user}'s keychains under HOME=${home}: ${err}"
                    } else {
                        return 0
                    }
}}}

> hy set HOME when you can use --keychain?

Maybe that will work just as well, but we might still need to set HOME (from `man codesign`):

"Note that the standard keychain search path is still consulted while constructing the certificate chain being embedded in the signature.
Note that filename will not be searched to resolve the signing identity's certificate chain unless it is also on the user's keychain search list."

That 2nd note may mean that my idea of ports installing a keychain into ~macports will only work if there's also a possibility to add them to the user's keychain search list...
`security list-keychains`  only allows to set the search list, not to add/delete items (that would require some Tcl coding)
`security add-trusted-cert` seems to allow everything we (or a port) might need. 

However, a keychain created with `security create-keychain` is no longer added to the keychain search list, and doesn't show up in the Keychain utility. It has to be added by hand, or by adding it to `security list-keychains` programmatically (and that, btw, has to filter out the System keychain lest it appear twice in the final search list). That limitation of programmatic keychain creation isn't documented anywhere; the API (and docs) haven't changed since 10.6 where new keychains were still added to the search list. Maybe this has been corrected in newer OS X versions?

One final thing: if you set `macportsuser` to something other than "macports" the HOME variable will still be set to ~macports during the activate phase ... but apparently ~macports belongs to the actual macportsuser, not user macports. Something that will need to be documented somewhere, if confirmed.

Here's a breakdown of what I've been trying while composing this message:

%> sudo -u macports -H security create-keychain blabla
(works after ensuring macports has write-access to ~macports/Library, and creates ~macports/Library/Keychains/blabla

%> sudo -u macports -H security list-keychains
"/Library/Keychains/System.keychain"

%> sudo -u macports -H security list-keychains -s ~macports/Library/Keychains/blabla
%> sudo -u macports -H security list-keychains
    "/opt/local/var/macports/home/Library/Keychains/blabla"
    "/Library/Keychains/System.keychain"

I then exported the lldb_codesign certificate and public key from my own keychain to files in /tmp and imported those:

%>sudo -u macports -H security import /tmp/lldb_codesign.cer -k blabla
1 certificate imported.
%>  sudo -u macports -H security import /tmp/lldb_codesign.pem  -k blabla
1 key imported.

%> sudo -u macports -H /Applications/Utilities/Keychain\ Access.app/Contents/MacOS/Keychain\ Access

Opens the Keychain utility which shows the expected items in the blabla keychain

However:

%> sudo -u macports -H codesign --keychain ~macports/Library/Keychains/blabla -s lldb_codesign -vvv /opt/local/bin/asciitopgm
lldb_codesign: no identity found
%> sudo  codesign --keychain ~macports/Library/Keychains/blabla -s lldb_codesign -vvv /opt/local/bin/asciitopgm
lldb_codesign: no identity found
%> sudo -u macports -H security find-identity -v
     0 valid identities found

That's probably because of a missing private key (which I can't seem to export from my own keychain)

Then I created a new blabla keychain for myself, copied the working set of lldb_codesign keys and certificate in there, tested if I could still codesign, and then copied that keychain file into ~macports/Library/Keychains, with the appropriate permissions. The Keychain utility now showed the 3 lldb_codesign items in that keychain, but I still get 

%> sudo codesign --keychain ~macports/Library/Keychains/blabla -s lldb_codesign -vvv /opt/local/bin/asciitopgm
lldb_codesign: no identity found

I have the impression I must be missing something, but cannot put my finger on it.

R.

PS: I think I understand why the Security framework uses HOME instead of an API call to determine the home directory: 
%> env HOME=/opt/local/var/macports/home sudo security list-keychains
    "/Volumes/Debian/MP9/var/macports/home/Library/Keychains/blabla"
    "/Library/Keychains/System.keychain"
%> sudo -H security list-keychains
    "/private/var/root/Library/Keychains/login.keychain"
    "/Library/Keychains/System.keychain"

IOW: using $HOME means a user can do `sudo codesign` or any other call that uses the Security framework, and still end up using his/er own keychains instead of those of root.

R.