Re: lldb ...

[Jeremy Sequoia]

Sent from my iPhone...

On Sep 9, 2016, at 14:46, Lawrence Velázquez  wrote:

>> On Sep 9, 2016, at 4:59 PM, Jeremy Huddleston Sequoia  
>> wrote:
>> 
>>> On Sep 9, 2016, at 04:38, René J.V. Bertin  wrote:
>>> 
>>> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is 
>>> owned by a ${macports_operator} who's got admin rights (= myself) and 
>>> reserve use of actual root privilege to those few ports that require 
>>> setting up SETUID/GETUID executables or that need to create users or groups.
>> 
>> YES!  We should not be needing to do such things as root.  That is 100% 
>> true, and I am in full support of moving away from that and only using root 
>> for activate.  We should be able to use fakeroot 
>> (https://wiki.debian.org/FakeRoot) for destdir.
> 
> Isn't fakeroot GPL-licensed? We wouldn't be able to distribute it with base.

It isn't that complicated.  It should be fairly easy for someone to write the 
moral equivalent of it under a virus-free license.  I'd also be happy to 
sponsor/advise anyone interested in doing it for GSoC or self-ed.

--Jeremy

> 
> vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: newbie python - cmake build problem I can't seem to fix...

[Ryan Schmidt]

> On Sep 9, 2016, at 3:06 PM, Ken Cunningham wrote:
> 
>> 
>> It's not *bad*, just not ideal. If the build system doesn't respect 
>> PYTHON_EXECUTABLE, then upstream should fix that.
> 
> True.
> 
> As it turns out, I learned how to re-write the python to be compatible with 
> 3.x, and fixed the port that way. So that's probably the best outcome, and 
> I'll submit that upstream for them to fix someday.

That's good. But it still suggests that the port is building with whatever 
"python" is, which as you've seen is different on different systems. Does the 
code work with the very old version of python included on macOS Tiger? Will it 
work with the version of python included with whatever version of macOS comes 
after Sierra? You might not know. It might be better to pick a known good 
version of python, add that as a dependency, and make the port use that. This 
is not just a good idea but even required if the port were to do something like 
install a python module (because that python module would be for that one 
version of python), or needs python not just to build but to run (because it 
would run that version of python).


> Although I'd still like to know how to adjust the $PATH, if you feel so 
> inclined one day -- promise to use my powers for good and not for evil ...

I found a simple example of how to do this in the gupnp-igd port, which has 
this block:


variant python27 description {Enable Python 2.7 bindings} {
configure.args-replace  --disable-python --enable-python
depends_lib-append  port:py27-gobject
configure.python${prefix}/bin/python2.7
set python_prefix   ${frameworks_dir}/Python.framework/Versions/2.7
set python_pkg_config_path  ${python_prefix}/lib/pkgconfig
configure.pkg_config_path   ${python_pkg_config_path}
build.env-appendPATH=${python_prefix}/bin:$env(PATH)
}



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Lawrence Velázquez]

> On Sep 9, 2016, at 4:59 PM, Jeremy Huddleston Sequoia  
> wrote:
> 
>> On Sep 9, 2016, at 04:38, René J.V. Bertin  wrote:
>> 
>> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is 
>> owned by a ${macports_operator} who's got admin rights (= myself) and 
>> reserve use of actual root privilege to those few ports that require setting 
>> up SETUID/GETUID executables or that need to create users or groups.
> 
> YES!  We should not be needing to do such things as root.  That is 100% true, 
> and I am in full support of moving away from that and only using root for 
> activate.  We should be able to use fakeroot 
> (https://wiki.debian.org/FakeRoot) for destdir.

Isn't fakeroot GPL-licensed? We wouldn't be able to distribute it with base.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 9, 2016, at 04:38, René J.V. Bertin  wrote:
> 
> On Friday September 09 2016 12:10:05 Rainer Müller wrote:
> 
> 
>>> different than your case either.  Either way, the debugger and all
>>> its dependencies need to be signed by a valid certificate.
>> 
>> That does not seem to be the case. In my testing on OS X 10.10 Yosemite,
>> it is enough to sign /opt/local/bin/ggdb with a trusted certificate to
>> get it working.

It requires the ggdb executable and all libraries it links against to be 
signed.  The port is written such that it only links against Apple-provided 
executables, so that solves that dependency.

> And lldb requires only the debugserver executable to be signed.

Again, because debugserver uses entitlements, all its dependencies need to be 
signed as well.

$ otool -L  /opt/local/libexec/llvm-devel/bin/debugserver
/opt/local/libexec/llvm-devel/bin/debugserver:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 22.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
307.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1238.0.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 1348.1.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 1349.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 
228.0.0)

As you can see, all of its dependencies are system libraries, so they're all 
valid.

>> Did this change with El Capitan or Sierra?
> 
> I'm guessing that would somehow be evident from the lldb-3.9 CMake files and 
> build instructions...
>> At least on OS X 10.10 Yosemite, I can use any path to a keychain with
>> `codesign --keychain`. This keychain does not have to be listed in
>> `security list-keychains`.
> 
> Does `man codesign` still mention the search list  requirement in the 
> documentation for --keychain?

Yes, that is still a requirement.

> 
> On Friday September 09 2016 02:26:19 Jeremy Huddleston Sequoia wrote:
> 
 I'd hate that because I've set things up with macports_user=myself and
 everything under workpath owned by myself, to avoid constant need for
 UID changing. I kind of doubt I'm the only one maintaining lots of
 ports who does that.> > 
>>> I don't understand.  Can you elaborate?  Doesn't post_destroot{} run as
>>> root in order to setup desired permissions in the destroot?  That's a
>>> good place to handle the resigning.
> 
> I do a lot of development on projects for which I also maintain ports; in 
> fact, development that's tightly coupled to the fact the code is available 
> via a port. Doing all that work "as myself" only to transfer it to the port 
> afterwards is a hassle and waste of time as far as I'm concerned. It's not so 
> much that I want to avoid having to put sudo in front of each and every port 
> command (I'd write a `sport` wrapper/alias). I don't want to grow the habit 
> of putting sudo in front of everything I'm doing around those ports' build 
> directories and that I'd also be doing in development that's got nothing to 
> do with MacPorts. I also want to be able to open a port's source tree in an 
> IDE, run incremental builds in subdirs for ${build.dir}, etc. So I've set my 
> macportsuser to my own username, and most of the time I run everything up to 
> and including `port destroot` as myself (and set up symlinks to `port work` 
> for easy access). Typically, for -devel ports that use fetch.git I also 
> replace ${worksrcdir} with a symlink to the working copy under my own home 
> directory (that way I also won't lose local changes if I ever forget to use 
> -o or -k).
> Many of the contributions I've made to KDE over the past few years were 
> developed with this approach. I've used the standard approach (macportsuser = 
> macports) on a VM Bradley gave me access to, and it's definitely a lot less 
> productive.
> Evidently this is not the kind of advanced use we need to consider for 
> regular users, but port developers/maintainers are users too, and I think we 
> *could* consider their needs too.
> 
> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is 
> owned by a ${macports_operator} who's got admin rights (= myself) and reserve 
> use of actual root privilege to those few ports that require setting up 
> SETUID/GETUID executables or that need to create users or groups.

YES!  We should not be needing to do such things as root.  That is 100% true, 
and I am in full support of moving away from that and only using root for 
activate.  We should be able to use fakeroot (https://wiki.debian.org/FakeRoot) 
for destdir.

> MacPorts installs into a parallel prefix, and there are only few ports that 
> require access to system directories. 
> 
>>> That's because you're using su

Re: newbie python - cmake build problem I can't seem to fix...

[Ken Cunningham]

> 
> It's not *bad*, just not ideal. If the build system doesn't respect 
> PYTHON_EXECUTABLE, then upstream should fix that.

True.

As it turns out, I learned how to re-write the python to be compatible with 
3.x, and fixed the port that way. So that's probably the best outcome, and I'll 
submit that upstream for them to fix someday.

Although I'd still like to know how to adjust the $PATH, if you feel so 
inclined one day -- promise to use my powers for good and not for evil ...

Ken


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: newbie python - cmake build problem I can't seem to fix...

[Lawrence Velázquez]

> On Sep 9, 2016, at 2:44 PM, Ken Cunningham  
> wrote:
> 
> I would -- but I haven't quite finished writing the portfile that would need 
> the ticket filed against it!

Aren't you modifying this?

https://trac.macports.org/browser/trunk/dports/emulators/hatari/Portfile

> I'll see if I can fix it without monkeying with the $PATH -- I knew nobody 
> would like that idea...

It's not *bad*, just not ideal. If the build system doesn't respect 
PYTHON_EXECUTABLE, then upstream should fix that.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: newbie python - cmake build problem I can't seem to fix...

[Ken Cunningham]

> 
> You should also file a ticket against hatari.

I would -- but I haven't quite finished writing the portfile that would need 
the ticket filed against it!

I'll see if I can fix it without monkeying with the $PATH -- I knew nobody 
would like that idea... there's something amiss in the python configuration 
script in the port I think. Maybe I can get it that way.

K


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: newbie python - cmake build problem I can't seem to fix...

[Lawrence Velázquez]

> On Sep 9, 2016, at 1:56 PM, Ken Cunningham  
> wrote:
> 
> I might dig into the build script and see what's going on in there, but 
> before I do that is there a way to monkey with the $PATH for the build only, 
> and then set it back to the user's $PATH when we're done?
> 
> That's cheating, I know.. but I could put ${prefix}/bin/python2.7 at the head 
> of the $PATH temporarily...

PATH cannot contain filenames, only directory names.

I'm reluctant to tell you how to monkey with PATH or what you would add. It'd 
be better to figure out what the build system is doing.

You should also file a ticket against hatari.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: newbie python - cmake build problem I can't seem to fix...

[Ken Cunningham]

Thanks. Not working so well so far.

I might dig into the build script and see what's going on in there, but before 
I do that is there a way to monkey with the $PATH for the build only, and then 
set it back to the user's $PATH when we're done?

That's cheating, I know.. but I could put ${prefix}/bin/python2.7 at the head 
of the $PATH temporarily...

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #45251: request for lldb

[René J . V . Bertin]

On Friday September 09 2016 17:07:48 MacPorts wrote:

>  I'm ok with splitting up the port and would be happy do to so if we can
>  avoid build time regressions and setup sane dependencies.  

Building a redistributable, standalone libclang is a bit of a separate issue, 
no?
That said, it's also supposed to speed up compile times when using clang, as 
there are less shared libraries to load at each invocation.

>  I don't like
>  the current situation in which clang rebuilds libLLVM.dylib at build time
>  instead of using llvm-config to find the installed one to build and link
>  against.

No, I agree (all the more since build times for 3.9 appear to be almost 50% 
longer than the ones for 3.8).

That said, I tried my trick of calling make in the tools/clang. For once it 
doesn't work, probably because there are apparently 3 parallel directories that 
have to be built in the right order.

You probably saw my thread about standalone building of lldb. In short: it 
almost works. Of course I can only tell if it has any benefits over my current 
approach once I've gotten it to work ;)

>  If that is needed, it should be addressed as a patch to the build system
>  that can be integrated upstream.  Using install_name_tool can introduce a
>  dependency on cctools, which is a pain point as it can cause a dependncy

Can you explain? Why would that the be case as long as we don't tell the port 
to use the copy from cctools?

>  Let's track that in a separate bug (I filed #52196).  I'm of the opinion
>  that `llvm-config --ldflags` should "do the right thing" but it doesn't
>  setup rpath.

I've thought about this a bit more, and it may be a moot point. The official 
Linux builds I have on my Ubuntu rig also install libclang, libLLVM etc. 
somewhere that's not part of the standard ldconfig search path. IOW, 
cross-platform code already has to add the path to those libraries to its 
rpath, which should solve the issue on OS X too. No?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[René J . V . Bertin]

On Friday September 09 2016 12:12:34 Lawrence Velázquez wrote:

> I don't know why that would happen, unless drastic changes are released 
> (which does happen sometimes). It's not inherent to base; I update from trunk 
> all the time with no problems.

Yeah, well. I like stability in things that form the basis for stuff that might 
be in flux all the time (or not). And base is named appropriately :)
Also explains why I still haven't gotten myself to upgrade from 10.9 ...

> Any code pushed to the repository goes out to all users immediately. This is 
> nice for certain applications but not others. The whole point of trunk base 
> is to hit the middle ground of getting certain changes field-tested by other 
> devs quickly without affecting users.
> 
> If you're suggesting that we test the code by sending around patches outside 
> source control... well, that sounds like an antipattern to me.

The point remains that we may want to push this functionality out as soon as 
it's ready to be tested in the wild, at least as far as selective signing of 
specific applications is concerned. Otherwise a port like lldb will have to 
wait until base is updated, or it'd have to include a "preview copy" of the 
signing code.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: newbie python - cmake build problem I can't seem to fix...

[Ryan Schmidt]

On Sep 9, 2016, at 10:32, Ken Cunningham  
wrote:
> 
> Hi all, thanks in advance for the ongoing education, and I apologize for the 
> newbie questions.
> 
> 
> I'm working on updating a port (hatari) that only builds with python2.7 (or 
> more accurately, doesn't build with python35 selected , but does build with 
> python27 selected). it uses cmake, and FindPythonInterp to find python. 
> 
> 
> If I ensure "sudo port select python python27" and then build, all goes well. 
> if I have python35 selected, the build fails, on SL and on El Cap.
> 
> I've pulled my hair out trying to find a portfile command that will force it 
> to build with python27 even if the user has previously selected python35.
> 
> Here's what I've tried so far, none of which have worked to override the 
> user's set python. I know I'm missing something simple thanks.
> 
> Ken
> 
> 
> 
> 
> # port builds with python27 but not 3.5
> 
> #configure.python   ${prefix}/bin/python2.7
> 
> #build.env-append  PYTHON=${prefix}/bin/python2.7
> #build.env-append  PYTHONEXECUTABLE=${prefix}/bin/python2.7
> #build.env-append  PYTHON_EXECUTABLE=${prefix}/bin/python2.7
> #build.env-append  PYTHON_VERSION_MAJOR=2
> #build.env-append  PYTHON_VERSION_MINOR=7
> 
> 
> #configure.env-append  PYTHON=${prefix}/bin/python2.7
> #configure.env-append  PYTHON_EXECUTABLE=${prefix}/bin/python2.7
> #configure.env-append  PYTHON_VERSION_MAJOR=2
> #configure.env-append  PYTHON_VERSION_MINOR=7
> 
> 
> #configure.args-append  PYTHON_VERSION_MAJOR=2
> #configure.args-append  PYTHON_VERSION_MINOR=7
> 
> 
> but no matter, I get 
> 
> :info:configure -- Found PythonInterp: /opt/local/bin/python (found version 
> "3.5.2") 
> 
> and the build fails, unless I "sudo port select python python27" first.

You may not be missing anything. I've found cmake to be pretty awful. Maybe try:

configure.args-append -DPYTHON_EXECUTABLE=${prefix}/bin/python2.7



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: newbie python - cmake build problem I can't seem to fix...

[Rainer Müller]

On 2016-09-09 17:32, Ken Cunningham wrote:
> I'm working on updating a port (hatari) that only builds with
> python2.7 (or more accurately, doesn't build with python35 selected ,
> but does build with python27 selected). it uses cmake, and
> FindPythonInterp to find python.
> 

PYTHON_EXECUTABLE is a cmake variable. Unlike make, cmake does not fill
in variables from the environment. Instead, you have to set/override
variables with command line arguments.

Try this:

configure.args-append   -DPYTHON_EXECUTABLE=${prefix}/bin/python2.7

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Lawrence Velázquez]

> On Sep 9, 2016, at 10:28 AM, René J.V. Bertin  wrote:
> 
>> On Friday September 09 2016 09:27:31 Lawrence Velázquez wrote:
>> 
>> If our release process is too cumbersome and infrequent, we should change 
>> that. I don't see reason to divide base's functionality more than it already 
>> is.
> 
> In my perception, "base" updates usually come with a lot of updating 
> installed ports and quite the share of stress if everything is going to work 
> like before. There should indeed be no need for that; it should usually be 
> possible just to update a file or two, at least as far as the Tcl library is 
> concerned.

I don't know why that would happen, unless drastic changes are released (which 
does happen sometimes). It's not inherent to base; I update from trunk all the 
time with no problems.

>> And I would definitely not want any security-related functionality to be 
>> implemented in a portgroup, which is immediately pushed to all users.
> 
> Who said everything about immediately, before it's well tested? The only 
> thing that I'm taking into consideration is the fact that we may not hit the 
> ideal implementation immediately that has all the required functionality and 
> flexibility.

Any code pushed to the repository goes out to all users immediately. This is 
nice for certain applications but not others. The whole point of trunk base is 
to hit the middle ground of getting certain changes field-tested by other devs 
quickly without affecting users.

If you're suggesting that we test the code by sending around patches outside 
source control... well, that sounds like an antipattern to me.

>> Apple provides developer certificates that can be used for signatures.
> 
> Yes they do. But usually that's between Apple and the developer who pays to 
> sign his/her software.

I do wonder whether there would be legal considerations.

> In MacPorts it means that basically anyone with commit access can start using 
> that certificate for free.

Sort of. I expect portmgr would be responsible for it. They already delegate 
responsibility for the integrity of our software via commit privileges, and 
committers already piggyback on their reputation when archives get signed and 
distributed from Buildbot.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

newbie python - cmake build problem I can't seem to fix...

[Ken Cunningham]

Hi all, thanks in advance for the ongoing education, and I apologize for the 
newbie questions.


I'm working on updating a port (hatari) that only builds with python2.7 (or 
more accurately, doesn't build with python35 selected , but does build with 
python27 selected). it uses cmake, and FindPythonInterp to find python. 


If I ensure "sudo port select python python27" and then build, all goes well. 
if I have python35 selected, the build fails, on SL and on El Cap.

I've pulled my hair out trying to find a portfile command that will force it to 
build with python27 even if the user has previously selected python35.

Here's what I've tried so far, none of which have worked to override the user's 
set python. I know I'm missing something simple thanks.

Ken




# port builds with python27 but not 3.5

#configure.python   ${prefix}/bin/python2.7

#build.env-append  PYTHON=${prefix}/bin/python2.7
#build.env-append  PYTHONEXECUTABLE=${prefix}/bin/python2.7
#build.env-append  PYTHON_EXECUTABLE=${prefix}/bin/python2.7
#build.env-append  PYTHON_VERSION_MAJOR=2
#build.env-append  PYTHON_VERSION_MINOR=7


#configure.env-append  PYTHON=${prefix}/bin/python2.7
#configure.env-append  PYTHON_EXECUTABLE=${prefix}/bin/python2.7
#configure.env-append  PYTHON_VERSION_MAJOR=2
#configure.env-append  PYTHON_VERSION_MINOR=7


#configure.args-append  PYTHON_VERSION_MAJOR=2
#configure.args-append  PYTHON_VERSION_MINOR=7


but no matter, I get 

:info:configure -- Found PythonInterp: /opt/local/bin/python (found version 
"3.5.2") 

and the build fails, unless I "sudo port select python python27" first.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Binary archives are never fetched for files in my local port repository

[Mojca Miklavec]

On 7 September 2016 at 09:25, Joshua Root wrote:
> On 2016-9-6 23:58 , Brandon Allbery wrote:
>> On Tue, Sep 6, 2016 at 5:56 AM, Mojca Miklavec wrote:
>>
>> I recently figured out that ports that I have in my local repository
>> are *never* updated from the binary archives, but always compiled from
>> sources. MacPorts doesn't even try to fetch the binary archives, it
>> goes straight to fetching the sources.
>>
>>
>> Every repository has its own binary archives. After all, if you have it
>> in your local repository, this is a pretty obvious indication that you
>> are doing something different from the port in the main repo that has
>> the binary archive, and that the binary archive for the main port
>> therefore can't be considered compatible with your local port.

In my case I try my best to stay compatible and up-to-date.

> That's right. If you look at portarchivefetch::get_full_archive_sites_path
> in src/package1.0/portarchivefetch.tcl, it deliberately doesn't fall back to
> the default resources path.
>
> If there is a _resources/port1.0/fetch/archive_sites.tcl in the repo, it
> will be used.

Thank you, adding that file solved the problem.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[René J . V . Bertin]

On Friday September 09 2016 09:27:31 Lawrence Velázquez wrote:

>> I know there's been talk about making at least parts of "base" updateable as 
>> a port; this could be an easy alternative.
>
>If our release process is too cumbersome and infrequent, we should change 
>that. I don't see reason to divide base's functionality more than it already 
>is.

In my perception, "base" updates usually come with a lot of updating installed 
ports and quite the share of stress if everything is going to work like before. 
There should indeed be no need for that; it should usually be possible just to 
update a file or two, at least as far as the Tcl library is concerned.

>And I would definitely not want any security-related functionality to be 
>implemented in a portgroup, which is immediately pushed to all users.

Who said everything about immediately, before it's well tested? The only thing 
that I'm taking into consideration is the fact that we may not hit the ideal 
implementation immediately that has all the required functionality and 
flexibility.

> We have no evidence either way, so appealing to an invisible mass of
> developers is not a convincing line of argument.

It would just be a pity if that evidence starts coming in when people start 
complaining about things that are no longer as feasible as before. But I know 
I've probably raised an issue that's going to oblige me to start jumping 
through all kinds of additional hoops .

>  Apple provides developer certificates that can be used for signatures.

Yes they do. But usually that's between Apple and the developer who pays to 
sign his/her software. In MacPorts it means that basically anyone with commit 
access can start using that certificate for free.
And yes, revoking was exactly the risk I was thinking about.
Either way, I'm just thinking aloud. If it's all FUD, so much the better.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Lawrence Velázquez]

> On Sep 9, 2016, at 6:00 AM, Rainer Müller  wrote:
> 
>> On 2016-09-09 03:38, Jeremy Sequoia wrote:
>> You are describing a system to automatically create and automatically
>> trust a code signing certificate that contains a private key in a file
>> on disk that is not encrypted with a passphrase and only depends on file
>> system ACLs to protect it.
>> 
>> That is trivially insecure and attack-prone.
> 
> Adding trust for an additional certificate also only relies on the
> filesystem permissions. If I get root write access to System.keychain, I
> can add my own certificate.
> 
> If we add a trusted certificate to System.keychain and the corresponding
> private key is only accessible by root, that would still be the same
> level of security in my opinion.

If the private key isn't encrypted, doesn't that basically eliminate the 
cryptographic security? At that point we're just relying on the OS to maintain 
access control.

vq
Sent from my iPhone

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Lawrence Velázquez]

> On Sep 9, 2016, at 7:38 AM, René J.V. Bertin  wrote:
> 
> I do a lot of development on projects for which I also maintain ports; in 
> fact, development that's tightly coupled to the fact the code is available 
> via a port. Doing all that work "as myself" only to transfer it to the port 
> afterwards is a hassle and waste of time as far as I'm concerned. It's not so 
> much that I want to avoid having to put sudo in front of each and every port 
> command (I'd write a `sport` wrapper/alias). I don't want to grow the habit 
> of putting sudo in front of everything I'm doing around those ports' build 
> directories and that I'd also be doing in development that's got nothing to 
> do with MacPorts. I also want to be able to open a port's source tree in an 
> IDE, run incremental builds in subdirs for ${build.dir}, etc. So I've set my 
> macportsuser to my own username, and most of the time I run everything up to 
> and including `port destroot` as myself (and set up symlinks to `port work` 
> for easy access). Typically, for -devel ports that use fetch.git I also 
> replace ${worksrcdir} with a symlink to the working copy under my own home 
> directory (that way I also won't lose local changes if I ever forget to use 
> -o or -k).
> Many of the contributions I've made to KDE over the past few years were 
> developed with this approach. I've used the standard approach (macportsuser = 
> macports) on a VM Bradley gave me access to, and it's definitely a lot less 
> productive.
> Evidently this is not the kind of advanced use we need to consider for 
> regular users, but port developers/maintainers are users too, and I think we 
> *could* consider their needs too.

Meh. There really aren't that many port developers, and I bet a lot fewer of 
them set macportsuser than you think.

We have no evidence either way, so appealing to an invisible mass of developers 
is not a convincing line of argument.

> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is 
> owned by a ${macports_operator} who's got admin rights (= myself) and reserve 
> use of actual root privilege to those few ports that require setting up 
> SETUID/GETUID executables or that need to create users or groups. MacPorts 
> installs into a parallel prefix, and there are only few ports that require 
> access to system directories.

We consider the fact that we install as root to be a security feature. One can 
already install MacPorts as a non-root user if they want to.

 Isn't that a bit of a special case, with you certainly having Apple's
 benediction to work on that particular product?> > 
>>> XQuartz isn't any more blessed in that respect than MacPorts.
> 
> And the fact you're an Apple's payroll doesn't have anything to do with it 
> either? Currently Apple doesn't have a say in the admission and upgrade of 
> each and every port in MacPorts, do they? In a way I'd even hope they cannot 
> force the exclusion of a port (other than ones clearly doing unlawful 
> things); signing everything with an official key seems like a way to give 
> them (more) leverage to control over the ports tree.

What? Apple provides developer certificates that can be used for signatures. 
Jeremy is suggesting we take advantage of this. Third-party developers do this 
all the time. Using a certificate doesn't give Apple review power over anybody 
(other than revocation in case of abuse).

vq
Sent from my iPhone


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152443] trunk/dports/science/gildas/Portfile

[mf2k]

> On Sep 9, 2016, at 3:10 AM, sma...@macports.org wrote:
> 
> Revision
> 152443 Author
> sma...@macports.org Date
> 2016-09-09 02:10:21 -0700 (Fri, 09 Sep 2016)
> Log Message
> 
> gildas: Update to version 201609a.
> Modified Paths
> 
> trunk/dports/science/gildas/Portfile 
> 
> Diff
> 
>  <>Modified: trunk/dports/science/gildas/Portfile (152442 => 152443)
> 
> --- trunk/dports/science/gildas/Portfile  2016-09-09 08:46:43 UTC (rev 
> 152442)
> +++ trunk/dports/science/gildas/Portfile  2016-09-09 09:10:21 UTC (rev 
> 152443)
> @@ -6,7 +6,7 @@
>  PortGroup   active_variants 1.1 
>  
>  namegildas
> -version 201607c
> +version 201609a
>  revision1
When increasing the version, please remember that you need to reset the 
revision to 0. Since that is the default value, normally the revision line is 
deleted entirely. 

>  set my_version  [string tolower [clock format [clock scan 2000-[string 
> range ${version} 4 5]-10] -format %b]][string range ${version} 2 3][string 
> range ${version} 6 end]
>  categories  science
> @@ -28,11 +28,12 @@
>  plotting, widgets).
>  
>  homepagehttp://www.iram.fr/IRAMFR/GILDAS/gildas.html 
> 
> -master_siteshttp://www.iram.fr/~gildas/dist/ 
> 
> +master_siteshttp://www.iram.fr/~gildas/dist/ 
>  \
> +http://www.iram.fr/~gildas/dist/archive/gildas/ 
> 
>  distname${name}-src-${my_version}
>  
> -checksums   rmd160  59d79cda36518f6de8deb782b0e43aeacca4e4ee \
> -sha256  
> cabdf76ac370090d225dee419c76743ca76355c58ca4b1f89c30d649ee243576
> +checksums   rmd160  4cc0ec9ff2483827c3ca07337d7eb7b19e78fe57 \
> +sha256  
> dcaecc7776c778a75ed40a36d217bc2f18df6063288086261292498fa74d2efd
>  
>  patch.pre_args  -p1
>  patchfiles  patch-admin-Makefile.def.diff \
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org 
> 
> https://lists.macosforge.org/mailman/listinfo/macports-changes 
> 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Lawrence Velázquez]

> On Sep 9, 2016, at 4:17 AM, René J.V. Bertin  wrote:
> 
> As a side-thought: it shouldn't be particularly difficult to implement a 
> "base" feature which defines a set of PortGroups to be included by default by 
> every port, if such a thing doesn't already exist.

As Josh has said previously, this is called "base".

> I know there's been talk about making at least parts of "base" updateable as 
> a port; this could be an easy alternative.

If our release process is too cumbersome and infrequent, we should change that. 
I don't see reason to divide base's functionality more than it already is.

And I would definitely not want any security-related functionality to be 
implemented in a portgroup, which is immediately pushed to all users.

vq
Sent from my iPhone
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[René J . V . Bertin]

On Friday September 09 2016 14:25:53 Rainer Müller wrote:

>I think you misunderstand this sentence. codesign will search in this
>keychain for the certificate itself, but the keychain will not be used
>to find other certificates in the certificate chain (all intermediates
>up to a root CA). With a self-signed certificate, there is no additional
>certificate in the chain.

In my experience the security framework simply doesn't find keychains that 
haven't been added to the search list, not even if you just created that 
keychain via the Security framework itself (as opposed to installing a 
pre-existing keychain file from some source).

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152440] trunk/dports/net

[Eric A. Borisch]

On Friday, September 9, 2016, Ryan Schmidt  wrote:

>
> > On Sep 8, 2016, at 11:28 PM, ebori...@macports.org  wrote:
> >
> > Revision
> > 152440
> > Author
> > ebori...@macports.org 
> > Date
> > 2016-09-08 21:28:04 -0700 (Thu, 08 Sep 2016)
> > Log Message
> >
> > zabbix3: New port.
>
>
> > Added Paths
> >
> >   • trunk/dports/net/zabbix3/
>
>
> > +--with-gnutls=/opt/local \
> > +--enable-ipv6
>
> Surely that should be "${prefix}" not "/opt/local"?
>
>
> > +eval xinstall -m 755 -W ${worksrcpath}/database/${DBFILES} \
> > +data.sql images.sql schema.sql \
> > +${destroot}${prefix}/share/zabbix/scripts
>
> It doesn't look like this needs eval -- I don't see a list. If a list were
> being used, the expansion operator ("{*}") should be used instead of eval.
>

Yes on both parts. Thanks for catching those; I'll clean them up.

 - Eric
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Rainer Müller]

On 2016-09-09 13:38, René J.V. Bertin wrote:
>> At least on OS X 10.10 Yosemite, I can use any path to a keychain with
>> `codesign --keychain`. This keychain does not have to be listed in
>> `security list-keychains`.
> 
> Does `man codesign` still mention the search list  requirement in the 
> documentation for --keychain?

>From the man page:
"""
--keychain filename
...
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.
"""

I think you misunderstand this sentence. codesign will search in this
keychain for the certificate itself, but the keychain will not be used
to find other certificates in the certificate chain (all intermediates
up to a root CA). With a self-signed certificate, there is no additional
certificate in the chain.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[René J . V . Bertin]

On Friday September 09 2016 12:10:05 Rainer Müller wrote:


> > different than your case either.  Either way, the debugger and all
> > its dependencies need to be signed by a valid certificate.
> 
> That does not seem to be the case. In my testing on OS X 10.10 Yosemite,
> it is enough to sign /opt/local/bin/ggdb with a trusted certificate to
> get it working.

And lldb requires only the debugserver executable to be signed.

> Did this change with El Capitan or Sierra?

I'm guessing that would somehow be evident from the lldb-3.9 CMake files and 
build instructions...

> At least on OS X 10.10 Yosemite, I can use any path to a keychain with
> `codesign --keychain`. This keychain does not have to be listed in
> `security list-keychains`.

Does `man codesign` still mention the search list  requirement in the 
documentation for --keychain?

On Friday September 09 2016 02:26:19 Jeremy Huddleston Sequoia wrote:

> > > I'd hate that because I've set things up with macports_user=myself and
> > > everything under workpath owned by myself, to avoid constant need for
> > > UID changing. I kind of doubt I'm the only one maintaining lots of
> > > ports who does that.> > 
> > I don't understand.  Can you elaborate?  Doesn't post_destroot{} run as
> > root in order to setup desired permissions in the destroot?  That's a
> > good place to handle the resigning.

I do a lot of development on projects for which I also maintain ports; in fact, 
development that's tightly coupled to the fact the code is available via a 
port. Doing all that work "as myself" only to transfer it to the port 
afterwards is a hassle and waste of time as far as I'm concerned. It's not so 
much that I want to avoid having to put sudo in front of each and every port 
command (I'd write a `sport` wrapper/alias). I don't want to grow the habit of 
putting sudo in front of everything I'm doing around those ports' build 
directories and that I'd also be doing in development that's got nothing to do 
with MacPorts. I also want to be able to open a port's source tree in an IDE, 
run incremental builds in subdirs for ${build.dir}, etc. So I've set my 
macportsuser to my own username, and most of the time I run everything up to 
and including `port destroot` as myself (and set up symlinks to `port work` for 
easy access). Typically, for -devel ports that use fetch.git I also replace 
${worksrcdir} with a symlink to the working copy under my own home directory 
(that way I also won't lose local changes if I ever forget to use -o or -k).
Many of the contributions I've made to KDE over the past few years were 
developed with this approach. I've used the standard approach (macportsuser = 
macports) on a VM Bradley gave me access to, and it's definitely a lot less 
productive.
Evidently this is not the kind of advanced use we need to consider for regular 
users, but port developers/maintainers are users too, and I think we *could* 
consider their needs too.

As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is 
owned by a ${macports_operator} who's got admin rights (= myself) and reserve 
use of actual root privilege to those few ports that require setting up 
SETUID/GETUID executables or that need to create users or groups. MacPorts 
installs into a parallel prefix, and there are only few ports that require 
access to system directories. 

> > That's because you're using sudo, which doesn't change the bootstrap
> > session.  You likely want to do something like:
> > sudo launchctl asuser `id -u joebob` sudo -u joebob codesign ...
> > which requires launchd2 (OS X 10.10+)

>From what I can tell the Security framework (and the security and codesign 
>execs) work from a remote (SSH) connection too. Indeed, sudo doesn't by 
>default change HOME (there's the -H option for that) ... but that's basically 
>what I'm arguing.

> > > Isn't that a bit of a special case, with you certainly having Apple's
> > > benediction to work on that particular product?> > 
> > XQuartz isn't any more blessed in that respect than MacPorts.

And the fact you're an Apple's payroll doesn't have anything to do with it 
either? Currently Apple doesn't have a say in the admission and upgrade of each 
and every port in MacPorts, do they? In a way I'd even hope they cannot force 
the exclusion of a port (other than ones clearly doing unlawful things); 
signing everything with an official key seems like a way to give them (more) 
leverage to control over the ports tree.

> > > So even you don't know what the ad hoc identity can and won't allow?
> > 
> > I'm not sure I understand your question.

Sorry, I understood that you hadn't realised that signing with the ad hoc 
identity prevents the persistent firewall popup for internet-enabled 
applications.

> > > because everything from before that magic moment will have been signed
> > > with a different key that *might* break unpredictable things?> > 
> > Can you elaborate here?  What do you mean by "a different key"?  Adhoc
>

Re: lldb ...

[Rainer Müller]

On 2016-09-09 10:17, René J.V. Bertin wrote:
> On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote:
> 
>> That's not really necessary.  All that is relevant is that the macports user 
>> has read access to the file.
> 
> The fact that codesign only accepts keychain file arguments that are also in 
> the user's keychain search list may have something to do with that.

At least on OS X 10.10 Yosemite, I can use any path to a keychain with
`codesign --keychain`. This keychain does not have to be listed in
`security list-keychains`.

>>> Technically it doesn't really matter if it's implemented in "base" or in a 
>>> PortGroup, right?
>>
>> In order for *every* port to benefit, it needs to be in base.
> 
> I don't see this argument. Are you considering codesigning each and every 
> binary automatically, without any need for requesting that from the Portfile? 
> What's the point in that?
> OTOH, if portfile devs have to indicate which binary is to be signed they can 
> just as well add a PortGroup to be able to access that functionality. 

I also have the impression we are talking about different things here. I
only want to add code-signing to the binaries that require it to work,
such as gdb and lldb.

I see no reason to and no benefits in adding a (ad-hoc) signature to
every binary MacPorts creates.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Rainer Müller]

On 2016-09-09 11:26, Jeremy Huddleston Sequoia wrote:
> Yes.  The fact that we aren't doing that for the binary packages that
> we ship is quite embarrassing.  We should solve this problem more
> generally such that we can ship properly signed binaries for every
> port.  Users installing the binary packages that we ship right now
> are running unsigned code, and that is quite frightening.  There's
> nothing guaranteeing that the package hasn't been MITMd.  There's no
> way for us to revoke a certificate if it turns out that our build
> servers had been compromised, etc.

This is just not true. All of our binary archives are in fact signed
with a detached .rmd160 signature that is verified before installation
when downloading from a mirror.

This signature is for all files in the tarball and not just for the
binaries. This is already more than codesigning would provide.

If your machine is compromised in a way that the binaries can be
replaced, this is out of the scope of MacPorts and a signature on the
binary will not help in any way.

The key can be revoked by releasing a new MacPorts version, or you can
just remove it from /opt/local/etc/macports/pubkeys.conf.

>> OTOH, if portfile devs have to indicate which binary is to be
>> signed they can just as well add a PortGroup to be able to access
>> that functionality.
> 
> Yeah, it would be much better if we just signed every Mach-O in the
> destroot of every port.

What do we gain from that? Everything else would still be unsigned.

>> So in your approach users who want to install a debugger port will
>> become power users, change their configuration and then what?
>> Rebuild everything if they've been building from source,
> 
> No, they just need everything that the debugger executable links
> against to be signed with a trusted certificate.  That is no
> different than your case either.  Either way, the debugger and all
> its dependencies need to be signed by a valid certificate.

That does not seem to be the case. In my testing on OS X 10.10 Yosemite,
it is enough to sign /opt/local/bin/ggdb with a trusted certificate to
get it working.

Did this change with El Capitan or Sierra?

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Rainer Müller]

On 2016-09-09 03:38, Jeremy Sequoia wrote:
> You are describing a system to automatically create and automatically
> trust a code signing certificate that contains a private key in a file
> on disk that is not encrypted with a passphrase and only depends on file
> system ACLs to protect it.
> 
> That is trivially insecure and attack-prone.

Adding trust for an additional certificate also only relies on the
filesystem permissions. If I get root write access to System.keychain, I
can add my own certificate.

If we add a trusted certificate to System.keychain and the corresponding
private key is only accessible by root, that would still be the same
level of security in my opinion.

>> Consider that any software can already use your developer certificate
>> from your user keychain to sign whatever it wants. 
> 
> No, it cannot.  It requires my explicit authorization to do so.  I must
> unlock the keychain for it to gain access.
> 
>> You will not even be
>> asked when that happens.
> 
> You should be if you set it up to do so.  If you put your private keys
> in your login keychain, then the act of logging in with your password is
> what unlocks them.  I don't consider that secure enough for my needs, so
> I place mine in another keychain which requires me to explicitly unlock
> it before use.

Fair enough. However, I guess most users only have a login.keychain.

>> I propose we add an additional keychain, readable by root only that is
>> used to sign MacPorts binaries. As root is required to access it, your
>> security would be defeated anyway if anyone gets to it.
> 
> It's great that only root can read it, but it should not be created
> automatically, added to any trusted store automatically, or stored
> unencrypted automatically.  We should instead give good instructions for
> setting it up with either a self-signed or ADC-Provided code signing
> certificate.

Requiring manual setup defeats my goal of just making it work by
installing the port. The status quo is already that everything needs to
be done manually.

> The user should just specify the path in macports.conf.  If it is
> locked, we should prompt for the passphrase to unlock it before use.

Would need both the path to the .keychain and the CN of the certificate,
right?

As a compromise, I would propose we generate an identity in a separate
keychain and sign the binary with it. However, adding the certificate to
the trust store in System.keychain needs to be done manually by the
user. Would you be comfortable with that?

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[René J . V . Bertin]

One more thought: if indeed we're going to try to codesign everything at some 
point, in the post-destroot, we'll probably want to ignore errors during that 
particular step, i.e. catch the codesign return code and simply raise a warning 
instead of bailing out. Ports that *require* signing (and only those) could set 
a flag to make that warning an actual error.

I guess `codesign ${destroot.dir}` won't work, right?

BTW, what about the reproducible build principle and the idea of code-signing 
everything on the buildbots using an official Apple key? Those seem to be 
clearly incompatible...

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 9, 2016, at 01:17, René J.V. Bertin  wrote:
> 
> On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote:
> 
>> That's not really necessary.  All that is relevant is that the macports user 
>> has read access to the file.
> 
> If memory serves me well I had to set read access on ~macports, 
> ~macports/Library and ~macports/LibraryKeychains too in order to be able to 
> read the test keychain in there as myself.

> The fact that codesign only accepts keychain file arguments that are also in 
> the user's keychain search list may have something to do with that. Anyway, 
> yes, a user specification may not be really necessary, but giving 
> ${macports_user} read access to your own keychain directory (for instance) 
> doesn't sound like such a good idea.

You would have needed to set executable access on those directories, not read 
access.  And yes, the file would need to be in the user's keychain search list.

Also, yes, giving ${macports_user} read access to your user's login keychain is 
not a good idea.  It should be locked down to just the users that need it and 
still guarded by a passphrase.

>>> Technically it doesn't really matter if it's implemented in "base" or in a 
>>> PortGroup, right?
>> 
>> In order for *every* port to benefit, it needs to be in base.
> I don't see this argument. Are you considering codesigning each and every 
> binary automatically, without any need for requesting that from the Portfile? 
> What's the point in that?

Yes.  The fact that we aren't doing that for the binary packages that we ship 
is quite embarrassing.  We should solve this problem more generally such that 
we can ship properly signed binaries for every port.  Users installing the 
binary packages that we ship right now are running unsigned code, and that is 
quite frightening.  There's nothing guaranteeing that the package hasn't been 
MITMd.  There's no way for us to revoke a certificate if it turns out that our 
build servers had been compromised, etc.

> OTOH, if portfile devs have to indicate which binary is to be signed they can 
> just as well add a PortGroup to be able to access that functionality. 

Yeah, it would be much better if we just signed every Mach-O in the destroot of 
every port.

>> If it's in a PortGroup, it is opt-in and doesn't solve the "let's sign 
>> everything" case.
> 
> Ah, the problem with inline replying :) I don't think anyone of us has even 
> thought of a "let's sign everything case". There's clearly never been a need 
> for that, and even if at some point it's going to be a necessity there will 
> 1) be enough time to have integrated the then mature feature into "base" and 
> 2) it will become a forced necessicity. 
> 
> As a side-thought: it shouldn't be particularly difficult to implement a 
> "base" feature which defines a set of PortGroups to be included by default by 
> every port, if such a thing doesn't already exist. I know there's been talk 
> about making at least parts of "base" updateable as a port; this could be an 
> easy alternative.

Yeah, I could see this being a PortGroup that is opt-in now and then becomes 
always-on or opt-out in a future version of base.

>> post_destroot{} would resign it as specified in the macports.conf
> 
> I'd hate that because I've set things up with macports_user=myself and 
> everything under workpath owned by myself, to avoid constant need for UID 
> changing. I kind of doubt I'm the only one maintaining lots of ports who does 
> that.

I don't understand.  Can you elaborate?  Doesn't post_destroot{} run as root in 
order to setup desired permissions in the destroot?  That's a good place to 
handle the resigning.

>>> There are 2 details to work out:
>>> - HOME is set to ${prefix}/var/macports/home (~macports)
>> 
>> HOME is irrelevant.
> 
> No, it isn't. It's what the Security framework uses to find keychains. Try it 
> out for yourself and then correct me if I'm wrong ;)
> I was very surprised to discover that, but then I realised that this is why 
> `sudo codesign ...` still uses the calling user's keychains.  Of course I 
> don't know if there have been changes in this aspect in 10.10 or later, but 
> it's true for 10.9 .

That's because you're using sudo, which doesn't change the bootstrap session.  
You likely want to do something like:

sudo launchctl asuser `id -u joebob` sudo -u joebob codesign ...

which requires launchd2 (OS X 10.10+)

>> No, the user doing the signing in post_destroot{} would be root.
> 
> Codesign will still need to find the keychain, be able to read it, and the 
> file will need to be in the searchlist of the user in who's homedir the file 
> lives.

Oh, right... because it needs to find the user's keychain search list to 
validate that the given keychain is in it.  crap.  yeah.

>>> (except for things like kexts in ports like the one I once proposed for 
>>> ZFS) and is that something that Apple would accept
>> 
>> I don't see why not.  I have such a key for XQuartz.
> 
> 

Re: lldb ...

[René J . V . Bertin]

On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote:

>That's not really necessary.  All that is relevant is that the macports user 
>has read access to the file.

If memory serves me well I had to set read access on ~macports, 
~macports/Library and ~macports/LibraryKeychains too in order to be able to 
read the test keychain in there as myself. The fact that codesign only accepts 
keychain file arguments that are also in the user's keychain search list may 
have something to do with that. Anyway, yes, a user specification may not be 
really necessary, but giving ${macports_user} read access to your own keychain 
directory (for instance) doesn't sound like such a good idea.

>> Technically it doesn't really matter if it's implemented in "base" or in a 
>> PortGroup, right?
>
>In order for *every* port to benefit, it needs to be in base.

I don't see this argument. Are you considering codesigning each and every 
binary automatically, without any need for requesting that from the Portfile? 
What's the point in that?
OTOH, if portfile devs have to indicate which binary is to be signed they can 
just as well add a PortGroup to be able to access that functionality. 

>
>If it's in a PortGroup, it is opt-in and doesn't solve the "let's sign 
>everything" case.

Ah, the problem with inline replying :) I don't think anyone of us has even 
thought of a "let's sign everything case". There's clearly never been a need 
for that, and even if at some point it's going to be a necessity there will 1) 
be enough time to have integrated the then mature feature into "base" and 2) it 
will become a forced necessicity. 

As a side-thought: it shouldn't be particularly difficult to implement a "base" 
feature which defines a set of PortGroups to be included by default by every 
port, if such a thing doesn't already exist. I know there's been talk about 
making at least parts of "base" updateable as a port; this could be an easy 
alternative.

>post_destroot{} would resign it as specified in the macports.conf

I'd hate that because I've set things up with macports_user=myself and 
everything under workpath owned by myself, to avoid constant need for UID 
changing. I kind of doubt I'm the only one maintaining lots of ports who does 
that.


>> There are 2 details to work out:
>> - HOME is set to ${prefix}/var/macports/home (~macports)
>
>HOME is irrelevant.

No, it isn't. It's what the Security framework uses to find keychains. Try it 
out for yourself and then correct me if I'm wrong ;)
 I was very surprised to discover that, but then I realised that this is why 
`sudo codesign ...` still uses the calling user's keychains.  Of course I don't 
know if there have been changes in this aspect in 10.10 or later, but it's true 
for 10.9 .
>

>No, the user doing the signing in post_destroot{} would be root.

Codesign will still need to find the keychain, be able to read it, and the file 
will need to be in the searchlist of the user in who's homedir the file lives. 

>> (except for things like kexts in ports like the one I once proposed for ZFS) 
>> and is that something that Apple would accept
>
>I don't see why not.  I have such a key for XQuartz.

Isn't that a bit of a special case, with you certainly having Apple's 
benediction to work on that particular product?

>That should be controlled at the base layer.  We shouldn't have a mixmatch of 
>signing identities for different files as that will break library validation 
>for any ports that might need LV.

Are you telling us that there's work in progress that will make it near 
impossible to do traditional Unix development on OS X without jumping through 
hoops to sign everything?

>> All the others I can think of are apps like kmail and family (port:kdepim) 
>> which *benefit* from signing to stop the nagging about "do you want this 
>> application to accept internet connections". And that can be handled just 
>> fine with the ad-hoc identify.
>
>If that's the case, then my proposal seems perfect.  It results in everything 
>being adhoc signed by default and lets power users (and the buildbots) 
>configure their system to resign executables with a configurable key.

So even you don't know what the ad hoc identity can and won't allow?
The ad hoc key is *not* useable for signing a debugger to make it functional. 
So in your approach users who want to install a debugger port will become power 
users, change their configuration and then what? Rebuild everything if they've 
been building from source, because everything from before that magic moment 
will have been signed with a different key that *might* break unpredictable 
things?

In my book that would be a clear argument *against* signing everything, and for 
signing only those things that really have to be signed.

>If the user can't be bothered to create a codesigning keychain and edit 
>macports.conf, they probably aren't going to be trying to setup their own 
>custom lldb installation in the first place and a